Re: Linker switches [ was: Re: API's that certainly do work. ]

Re: Linker switches [ was: Re: API's that certainly do work. ]

[marcus]

Colin Peters wrote:
] To summarize the summary: Don't link with -lkernel32 on your command
] line.

DRS <drs@inxpress.net> asks:
> I guess my question is, why would you want to do this anyway? I have
> been using -mwindows, which I thought was the recommended linker 
> switch for compiling a GUI app. I don't claim to know anything 
> about ld, except that it works for all the examples I have tried.
> 
> I have been unable to find any documentation about the
> linker switch in question (-lkernel32) except that it appears 
> to be mentioned in earlier versions of the distribution. 
> If someone wants to explain the in's and outs of these 
> various (win32 specific) switches and how they are supposed 
> to work, I'm all ears. Do doubt this information would be 
> of general interest.

The -lkernel32 is not a switch itself, but a library to be included.  The
-l<library> option tells the linker to look for lib<library>.a in the library
directories, so -lkernel32 tells it to search the libkernel32.a library.

One is tempted to do this if they reference some routines from the kernel32
library, especially if you don't remember that -mwindows already does that
for you.  With a normal archive library, this is not a problem, but with
a DLL library it is.

The problem is that including the DLL library has to build an import descriptor
table which is a fairly complex structure.  The contents depend on the library
routines actually referenced.  Each routine referenced by the program is
resolved by a stub file in the library which places a jump in the .text
segment, one pointer into each of .idata$4 and .idata$5, and the function
name in .idata$6.  Additionally, the stub file references a symbol that will
be resolved by another file from the library.  This file supplies the head
of the structure in .idata$2 and leaves more undefined symbols to bring in
a file that terminates the .idata$4 and .idata$5 lists (for this DLL only)
and a terminator for the entire descriptor list in .idata$3.  The cygwin32
strategy is slightly different, and they forgot the .idata$3 terminator, but
it is similar.

So, what happens when the kernel32 library is included twice is that the
undefined references from the program get resolved by the first -lkernel32
and the import table is built for that, then by the time that the libraries
get processed for the -mwindows, there are more references to routines from
the kernel32 library from other library routines (processing the library
twice would be OK if there were not any new references to the library).  These
routines cause the jump instruction to be put into the .text section, pointers
in the .idata$4 and .idata$5 sections, and the function name in .idata$6,
but the reference that is supposed to bring in an import library header
into .idata$2 is resolved to the already present header from the first
include.  However, since that import structure has already been built, the
new functions do not get incorporated into the structure, so when the program
is eventually loaded, these functions do not get their pointers updated to
point into the DLL since they are not really in the import table.  Then,
when the function is called, the jump heads into the function name, not the
function itself, and things crash.

That's the problem with processing a DLL library twice.  I'm pretty sure that
it would occur with Microsoft LINK as well, but I haven't verified it.  It's
an intricate dance of the various segments to build the DLL import table, so
some things like this are difficult to handle.  I suppose it could be dealt
with my using more .idata segments, something like .idata$4_kernel32 or some
such, but this would definately be non-standard.

marucs hall
Lucent Technologies

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Linker switches [ was: Re: API's that certainly do work. ]

[Geoffrey Noer]

marcus@bighorn.dr.lucent.com wrote:
[...]
> a file that terminates the .idata$4 and .idata$5 lists (for this DLL only)
> and a terminator for the entire descriptor list in .idata$3.  The cygwin32
> strategy is slightly different, and they forgot the .idata$3 terminator, but
> it is similar.
[...]

The .idata3 terminator isn't automatically produced by any of the tools,
because it was hard to integrate this functionality into ld/dlltool
and/or because nobody has spent the time to do so.

Producing dlls is currently much more clumsy than I think it needs to be.
(I'd like to do away with dlltool entirely and have the functionality
included in ld but I don't know how practical this would be).  Regardless,
the dll building process is something I think is important to improve.

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Linker switches [ was: Re: API's that certainly do work. ]

[Ian Lance Taylor]

In gnu-win32 marcus@bighorn.dr.lucent.com writes:

>I'd have to agree with this.  It would also be very nice for ld to procude
>the .reloc section directly instead of having to make a pre-pass and working
>with dlltool to produce it.  Conceptually it isn't difficult, but there may
>be some design issues with ld that make it difficult (the size of all segments
>[including .reloc] must be known before output is started, but the .reloc
>data is generated as a byproduct of the output processing, I think)  I
>don't think that it is necessary to eliminate dlltool, but if the process
>for creating a dll is made reliable and more intuitive, I'm all for it.

All shared library schemes must generate some sort of relocation
section after reading the input files but before writing the output
file.  The GNU linker, which fully supports shared libraries on SunOS,
AIX, and several ELF based systems, solves this by using a
size_dynamic_sections routine which is called by the emulation code.
See, for example, ld/emultempl/elf32.em, and the functions which it
calls in bfd/elflink.h.

Ian
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Linker switches [ was: Re: API's that certainly do work. ]

[marcus]

Geoffrey Noer wrote:

> The .idata3 terminator isn't automatically produced by any of the tools,
> because it was hard to integrate this functionality into ld/dlltool
> and/or because nobody has spent the time to do so.

Actually, it's pretty trivial, so I suppose it is because nobody had spent
the time.  I am currently working on getting dlltool and ld to interwork
with MSVC LINK & friends.  Currently, I have made a couple of small changes
to ld that get it to understand .lib files produced by MSVC.  There do seem
to be some problems with the communal data settings produced by MSVC (or
at least in the .lib files shipped with it).  The flags are interpreted by
ld in such a way that it sees duplicated segments when I don't think it
should be.  I'm still looking into this.

I have also modified dlltool to remove the need to generate a .s file
and assemble it, but to instead generate the .o files directly from the
appropriate BFD calls.  Along the way, I produce a file that resolves the
__NULL_IMPORT_DESCRIPTOR symbol and produces an import descriptor terminator
in .idata$3.  It seems that for dlltool to produce a .lib file that is
usable with MS LINK, the various entries in the archive must have the
same name.  This is annoyingly difficult to achieve with BFD, unless there's
a trick somewhere.  I can change the filename member of the archive name,
but the file descriptor caching needs the old filename to re-open the file
when writing out the archive...

> Producing dlls is currently much more clumsy than I think it needs to be.
> (I'd like to do away with dlltool entirely and have the functionality
> included in ld but I don't know how practical this would be).  Regardless,
> the dll building process is something I think is important to improve.

I'd have to agree with this.  It would also be very nice for ld to procude
the .reloc section directly instead of having to make a pre-pass and working
with dlltool to produce it.  Conceptually it isn't difficult, but there may
be some design issues with ld that make it difficult (the size of all segments
[including .reloc] must be known before output is started, but the .reloc
data is generated as a byproduct of the output processing, I think)  I
don't think that it is necessary to eliminate dlltool, but if the process
for creating a dll is made reliable and more intuitive, I'm all for it.

Now, questions for the list:

Is there anybody else working to the same goal (interworking with the MSVC
files/tools)?  Does anybody have a good handle on the meanings of the
communal data flags in MS .lib files?  There is code in ld that tries to
translate them into BFD's internal flags, but ld just compares segment
names although I believe that MS may be thinking file(segment) names
should be compared for duplicates..

marcus hall
Lucent Technologies
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Linker switches [ was: Re: API's that certainly do work. ]

[Mumit Khan]

Regarding adding -lkernel32 specifically to the link line, 
DRS <drs@inxpress.net> writes:
> 
> I guess my question is, why would you want to do this anyway? 

Probably mostly due to other software package telling you to do it.
Pdcurses, eg., is one (but surprisingly works just fine when I do
add -lkernel32!). The other one is octave, and the reason is due to 
the way octave configure script works (and octave does crashe 
mysteriously when -lkernel32 is added to link line).

> I have been unable to find any documentation about the
> linker switch in question (-lkernel32) except that it appears 
> to be mentioned in earlier versions of the distribution. 
> If someone wants to explain the in's and outs of these 
> various (win32 specific) switches and how they are supposed 
> to work, I'm all ears. Do doubt this information would be 
> of general interest.

Seconded.

Regards,
Mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/

ps: Wonder why the sometime 24-48 hour delay in the mailing list
messages? Or am I only one seeing the messages after so long?
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Linker switches [ was: Re: API's that certainly do work. ]

[DRS]

Colin Peters wrote:

> To summarize the summary: Don't link with -lkernel32 on your command
> line.

I guess my question is, why would you want to do this anyway? I have
been using -mwindows, which I thought was the recommended linker 
switch for compiling a GUI app. I don't claim to know anything 
about ld, except that it works for all the examples I have tried.

I have been unable to find any documentation about the
linker switch in question (-lkernel32) except that it appears 
to be mentioned in earlier versions of the distribution. 
If someone wants to explain the in's and outs of these 
various (win32 specific) switches and how they are supposed 
to work, I'm all ears. Do doubt this information would be 
of general interest.

Regards,
DRS
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".