Hello Chris,
Chris Faylor <[EMAIL PROTECTED]> wrote:
CF> On Mon, Sep 04, 2000 at 09:34:12PM +0300, Paul Sokolovsky wrote:
>>Mandatory data imports marking: I *hate* this feature and develop
>>libtool re-implementation which frees programmer from it. But when I
>>mentioned it on cygwin maillist, DJ Delorie was rather sceptical about
>>it, saying they will support MS way.
CF> Do you have a URL for this skepticism? I hate marking data imports
CF> also. It would be interesting to see what DJ's reasons are. I've
CF> never known him to be resistant to good ideas.
Well, he wasn't resistant, he was somewhat sceptic. He already
explained why - it hardly can be easily and seamlessly working from
the first time. But neither I pledge for it. I do it because I need
it, and hope to release it because someone may find it useful. That
someone hardly will be green newbie but probably programmer who
perfectly knows how to build dlls and looking for way to automate it
and make more seamless. He probably improve it be more easy to use,
etc., etc. and that way one day even greener will be able to use (or
maybe it will be used by default? ;-) )
http://www.delorie.com/archives/browse.cgi?p=cygwin/2000/05/03/10:32:40
Btw, that whole thread was started about enumerating bugs in
then-current binutils, 19990818. But from DJ's letter I'm afraid they
are all there, and even those I thought dead forever are re-born. I
currently don't have access to box where I have cygwin, and have
resources to re-download it, so if someone have interest, please
re-check them.
CF> Anyway, it would be interesting to see how you work around this. I
CF> can't think of any way to handle this without changing the compiler and
CF> the linker.
Nor I claim that it might be. But since I'm not gcc hacker, and ld
hacking is too expensive for mere experimenting, I prefer detached
techniques. Sketching my idea (I did it in thread above, IIRC), there
are several steps which source undergoes before became executable:
1. First, there's source
2. Then, it is preprocessed
3. Then, it is compiled into assembler
4. Then, it is assembled into object
5. Then, objects linked into executable
Standard MS way is to have imported symbols marked so on stage 1, and
to do that manually. So, first idea was to automate it. Result is my
a2dll (http://www.is.lg.ua/ftp/gnuwin32/altbinutils/a2dll-1.0.zip)
script which works following way:
1. You build static library
2. Then, you run a2dll upon static lib
3. If you're lucky, you get dll and implib (as drop-in replacement for
static lib) and quest is over
4. If you're not lucky, you get dll, implib, and list of data symbols, exported
by that dll
5. You run grep -F <that_list> *.h to get an idea where those data are
declared (well, in next version I will run it automatically).
6. Paste appropriate macro in front of each declaration.
Not so bad, I think. Of course, I thought about automating point 6
above too. As I told, hacking gcc would be hard for me, so one evening
I took some make-prototypes type utility with aim to make it output
something like:
<line>:<col> <symbol> <prefix-coded type>
Unfortunately, I chose wrong one - that even wasn't able to parse full
C declaration. When, at 2a.m., I finally got it working I figured out
that it fails with very it's own header because it outputs location as
of preprocessed file... So, I just removed it all and went to sleep.
Now I think it could be possible to carry on, but on level 2 as of
picture above.
Well, anyway, I imagined all those 5-stage procedure clearly and
questioned very requirement to do it on source level. It's obvious
that imported symbols can be inferred autmatically, and precisely on
the level 4. But of course, it won't be easy to act upon such
information in machine code. So I've choose assembly level, and since
info on imports not immediately available, it's all about deferred
compilation and linking. The rest is purely implementation technique.
CF> cgf
--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135
