From: W DOT Derks AT nl DOT cis DOT philips DOT com ("wiljan") Subject: Re: Linking with .LIB files / ld bugs 29 Mar 1997 05:24:33 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199703290720.IAA01499.cygnus.gnu-win32@nl.cis.philips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Original-To: X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Original-Sender: owner-gnu-win32 AT cygnus DOT com 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 AT cygnus DOT com" with one line of text: "help".