This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: ld bug? calling one assembly routine from another...
- To: gnu-win32 at cygnus dot com
- Subject: Re: ld bug? calling one assembly routine from another...
- From: Ian Lance Taylor <ian at cygnus dot com>
- Date: Sun, 3 May 1998 16:55:26 -0400
>I think I've discovered a bug in the linker which comes with the EGCS
>1.0.2 distribution of Mingw32 (not sure whether it applies to cygwin32
>versions), when linking object files created with Nasm v0.97. Nasm can
>be obtained from http://www.cryogen.com/nasm/
>I believe the bug must be related to win32 gnu ld, rather than nasm, as
>the DJGPP linker has no such problem. (admittedly the DJGPP linker
>version is older than my win32 version).
I don't know much about nasm. However, I do know that between the
cygwin32 b18 and b19 releases, the object file format support was
changed to more closely match the Microsoft PE definition. I also see
this in the nasm documentation:
Note that although Microsoft say that Win32 object files follow
the COFF (Common Object File Format) standard, the object files
produced by Microsoft Win32 compilers are not compatible with COFF
linkers such as DJGPP's, and vice versa. This is due to a
difference of opinion over the precise semantics of PC-relative
relocations. To produce COFF files suitable for DJGPP, use NASM's
coff output format; conversely, the coff format does not produce
object files that Win32 linkers can generate correct output from.
You should investigate that first. The cygwin32 linker expects to see
Win32 PE object files, not COFF object files.
Ian
-=- MIME -=-
This is a MIME-encapsulated message
--QAA21389.894228766/tweedledumb.cygnus.com
The original message was received at Sun, 3 May 1998 16:52:35 -0400 (EDT)
from ian@localhost
----- The following addresses had permanent fatal errors -----
gnuw-in32
----- Transcript of session follows -----
... while talking to mailhost.cygnus.com.:
>>> RCPT To:<gnuw-in32@cygnus.com>
<<< 550 <gnuw-in32@cygnus.com>... User unknown
550 gnuw-in32... User unknown
--QAA21389.894228766/tweedledumb.cygnus.com
Content-Type: message/delivery-status
Reporting-MTA: dns; tweedledumb.cygnus.com
Arrival-Date: Sun, 3 May 1998 16:52:35 -0400 (EDT)
Final-Recipient: RFC822; gnuw-in32@cygnus.com
Action: failed
Status: 5.1.1
Remote-MTA: DNS; mailhost.cygnus.com
Diagnostic-Code: SMTP; 550 <gnuw-in32@cygnus.com>... User unknown
Last-Attempt-Date: Sun, 3 May 1998 16:52:46 -0400 (EDT)
--QAA21389.894228766/tweedledumb.cygnus.com
Content-Type: message/rfc822
Return-Path: <ian>
Received: (from ian@localhost)
by tweedledumb.cygnus.com (8.8.5/8.8.5) id QAA21384;
Sun, 3 May 1998 16:52:35 -0400 (EDT)
Date: Sun, 3 May 1998 16:52:35 -0400 (EDT)
From: ian
Message-Id: <199805032052.QAA21384@tweedledumb.cygnus.com>
To: dph-man@iName.com
CC: gnuw-in32
Subject: Re: ld bug? calling one assembly routine from another...
References: <354BE77D.3E445DB1.cygnus.gnu-win32@iname.com>
>I think I've discovered a bug in the linker which comes with the EGCS
>1.0.2 distribution of Mingw32 (not sure whether it applies to cygwin32
>versions), when linking object files created with Nasm v0.97. Nasm can
>be obtained from http://www.cryogen.com/nasm/
>I believe the bug must be related to win32 gnu ld, rather than nasm, as
>the DJGPP linker has no such problem. (admittedly the DJGPP linker
>version is older than my win32 version).
I don't know much about nasm. However, I do know that between the
cygwin32 b18 and b19 releases, the object file format support was
changed to more closely match the Microsoft PE definition. I also see
this in the nasm documentation:
Note that although Microsoft say that Win32 object files follow
the COFF (Common Object File Format) standard, the object files
produced by Microsoft Win32 compilers are not compatible with COFF
linkers such as DJGPP's, and vice versa. This is due to a
difference of opinion over the precise semantics of PC-relative
relocations. To produce COFF files suitable for DJGPP, use NASM's
coff output format; conversely, the coff format does not produce
object files that Win32 linkers can generate correct output from.
You should investigate that first. The cygwin32 linker expects to see
Win32 PE object files, not COFF object files.
Ian
--QAA21389.894228766/tweedledumb.cygnus.com--
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".