Subject: Re: ld bug? calling one assembly routine from another...
From: [email-masked] (Ian Lance Taylor)

3 May 1998 21:05:16 -0700
Message-ID: <[email-masked]>
To: [email-masked]

>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:<[email-masked]>
<<< 550 <[email-masked]>... 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; [email-masked]
Action: failed
Status: 5.1.1
Remote-MTA: DNS; mailhost.cygnus.com
Diagnostic-Code: SMTP; 550 <[email-masked]>... User unknown
Last-Attempt-Date: Sun, 3 May 1998 16:52:46 -0400 (EDT)

--QAA21389.894228766/tweedledumb.cygnus.com
Content-Type: message/rfc822

Date: Sun, 3 May 1998 16:52:35 -0400 (EDT)
From: ian
To: [email-masked]
CC: gnuw-in32
Subject: Re: ld bug? calling one assembly routine from another...

>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
"[email-masked]" with one line of text: "help".