Nobody in the world understands Gnu's 'ld'.

[root at jacob dot remcomp dot fr (root)]

Jim wrote:
> 
>   void (*xxx)() = GetFullPathName;
> 
>   int STDCALL
>   WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)
>   {
>         return 0;
>   }
> 
> I've tracked this down, and have determined that it dies with a SIGSEGV
> which doesn't get printed anywhere because cygwin.dll prints it to
> STD_ERROR_HANDLE, which isn't valid.  Clearly it should do better,
> at the very least writing it to the strace output if that is a file, and
> a
[snip]
> 
> The point at which it dies is the at the very beggining of main()
> from libcmain.cc, when it calls GetModuleHandle.  That call goes to a
> jump instruction that goes
> through an indirect pointer that appears to contain the wrong
> address, since it is the address of some code.  The jump uses the
> content of that code as the "location" to go to, and so it
> dies.  Perhaps to someone who knows about Windows dll's and jump tables,
> the problem here might be obvious, but I know nothing of those things.
> But it sure looks like a serious screwup by ld.

A dll call under windows (NT or 95) is just a jump through a
table of pointers to functions. This table (called 'import table')
is built by the linker. 

The linker builds this table by using an 'import library'. That
library contains several small pieces of code and special
sections that, when combined together with some pieces of
code in the startup (the famous .idata$3 section) will build
that import table in the executable.
This is an extremely complex and error prone process, that costed
me months of horrible work when I wrote the linker for my
system. I was VERY happy when it was over...

Gnu's linker: A NIGHTMARE!
-------------------------

Since several months people here report that Cygnus's linker is flawed.
I think that it is just plain that Cygnus doesn't have the
know-how to repair it, since Steve Chamberlain, the guy that
wrote most of it, hasn't posted anything here since ages and
he was very active before.

Before writing my linker, I studied gnu's linker code with the
naive assumption that I could use it. After spending weeks and weeks
trying to understand it, I gave up and wrote mine.

There is only ONE person in the world that understands that code
and he is called Steve Chamberlain. If Cygnus doesn't have
him any more, users of gnu-win32 will have to live with a flawed linker
for the rest of their lives.

Just to give you an idea, ld is supposed to link an object file
from sun's unix format with some code from windows 95 and with
some code of hp Unix. Of course this is ridiculous and it will never
work, but this is how 'ld' is designed: an incredible complexity
that (to me) seems completely unwarranted. It has a full blown LANGUAGE
(with lex+yacc parser/lexer!) that is supposed to recognize linker
commands. Obviously nobody ever uses it, but to understand
what the linker is doing you have to go through yet another layer
of complexity.

Then you have the 'BFD' format, that is supposed to be an universal
binary format designed by GNU that will abstract the binary format
of all machines in the western world into ONE format. Obviously
it doesn't work, but then you have not only to understand what
binary format you have in windows (what is difficult enough) but
you have to understand BFD too.

And then you have the macro-sickness... You read:
	a = foobar(b->field);

Well, where is foobar? Nowhere. It is a macro that will be expanded
into an index into a table using b. Mmmm. This table is
actually an table of tables. MMMMMMMMMMM. OK let's go on.
In that table of tables you have a field that is a table of
functions. GOD! WHATS THIS!!! But let's go on. That table
of functions is indexed by that b->field to jump into ???
IT DEPENDS OF THE RUNTIME CONDITIONS. Of course! You can at
the linker command line change the output format remember?
You can link your windows object files to give a SUN OS
executable isn't that FUN???

And to crown this beatiful construction there is NO DOCUMENTATION
whatsoever about anything I have told you in this message. I inferred
this from reading THE C CODE!!!

Not surprisingly, Cygnus is stuck with a linker that nobody 
in the world understands... except Steve of course. But I think
*even he* has problems to know what the hell is going on in there...

That is why this linker can't even recognize MSVC object code
format and use the MSVC .LIBs. Because nobody in the world
is able to modify it. Of course we do not need compatibility
with SUN or HP Unix under Windows 95. We would need MSVC
compatibility. But to do that we would have to find somebody
that understands 'ld'...

I think that anybody using 'ld' is living very dangerously...

-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".