Linking with .LIB files / ld bugs

[wiljan]

David W Palmer wrote:
>      and link using:
>      
>      link simple.o libc.a libcygwin.a libkernel32.a libuser32.a glu32.lib 
>      opengl32.lib libgdi32.a /subsystem:windows /machine:i386 
>      /entry:mainCRTStartup

At this moment this is definitely not going to work.
You are trying to use LINK of MS to link object generated by as of cygnus.
At this moment the BFD code of cygnus probably contains a bug that does
not allow you to do this.

In the past I have tried to do the same thing.
This made me finally write the following bug report to ACT:

I am still trying to build DLLs.
I am now perfectly able to do this using ld and dlltool BUT these
tools do not allow an exe to refer to data into another dll.
If one does this one will always get an indirect jump in between
which will definitely will make your program fail.

For this reason I now tried switching to the MS linker. This seems to
have no trouble with doing above thing.
I now run into a problem with as.exe as distributed in GNAT 3.09
When linking the objects together with the MS linker it creates wrong
data references inside the executable itself (This has nothing to do with
dll linking, but is simply linking of an NT executable).

Since Labtek has always had the possibility to use either LD or LINK
I am sure that their assembler was oke. Therfore I tried as.exe from
GNAT304a. I found that when using that assembler everything seems to
be oke.
I used objdump to find out the difference in object generated.

dump from object generated by as from 304a:

crt0.o:     file format pe-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000094  00000000  00000000  0000008c  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  1 .data         00000118  00000000  00000000  00000120  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000000  2**2
                  ALLOC

dump from object generated by as from 309 = cygnus 17.1:

crt0.o:     file format pe-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000094  00000000  00000000  0000008c  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  1 .data         00000118  00000094  00000094  00000120  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  000001ac  00000000  00000000  2**2
                  ALLOC

As you can see objdump reports different numbers for the .data section.
I have no idea what this means, but I am sure that this is what
makes the MS linker fail. This is because the 94 hex is the offset error
of the data references that the MS linker generates.
I tried dumping some .o files using objdump --headers and always found
similar things: The size of the .text section pops up in the VMA and LMA
places of the .data and .bss section.

For some reason ld.exe does not seem to bother about these errors
in the generated object data, since it generates working
executables (At least most of the times as I pointed out before).


Wiljan

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