Date: Sun, 8 Aug 1999 14:02:19 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "S. M. Halloran" <mitch AT duzen DOT com DOT tr>
cc: djgpp AT delorie DOT com
Subject: Re: OBJ files with DJGPP
In-Reply-To: <199908061124.OAA29550@ankara.Foo.COM>
Message-ID: <Pine.SUN.3.91.990808140159.23423L-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Fri, 6 Aug 1999, S. M. Halloran wrote:

> 3. Since the AT&T-->Intel converter mentioned above has apparently been 
> optimized to work with the Netwide Assembler (NASM), which is the
> assembler I was going to recommend and will produce object files in
> apparently many formats (COFF, OBJ, etc), you then just produce your
> object with NASM, and cross your fingers.

Crossing your fingers won't help, because this still isn't going to
work, but for reasons that have nothing to do with the format of the
object files.

The problem is that when you compile C/C++ source, the compiled code
includes references to hidden variables, functions and data structures
that are private to the libraries used by the compiler.  These private
things come from the header files and from code fragments built into
the compiler itself.  They will cause link-time errors that are very
hard, if not impossible to solve.