From:	ian AT cygnus DOT com (Ian Lance Taylor)
Subject:	Re: ld bug? calling one assembly routine from another...
3 May 1998 21:05:16 -0700 :
Message-ID:	<199805032055.QAA12702.cygnus.gnu-win32@subrogation.cygnus.com>
To:	gnu-win32 AT cygnus DOT 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
 -=- 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 AT localhost

   ----- The following addresses had permanent fatal errors -----
gnuw-in32

   ----- Transcript of session follows -----
.... while talking to mailhost.cygnus.com.:
>>> RCPT To:<gnuw-in32 AT cygnus DOT com>
<<< 550 <gnuw-in32 AT cygnus DOT 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 AT cygnus DOT com
Action: failed
Status: 5.1.1
Remote-MTA: DNS; mailhost.cygnus.com
Diagnostic-Code: SMTP; 550 <gnuw-in32 AT cygnus DOT 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 AT 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 DOT QAA21384 AT tweedledumb DOT cygnus DOT com>
To: dph-man AT iName DOT com
CC: gnuw-in32
Subject: Re: ld bug? calling one assembly routine from another...
References: <354BE77D DOT 3E445DB1 DOT cygnus DOT gnu-win32 AT iname DOT 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 AT cygnus DOT com" with one line of text: "help".

- Raw text -