www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/08/25/07:38:12

Date: Tue, 25 Aug 1998 14:36:50 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: andrewc AT rosemail DOT rose DOT hp DOT com
cc: djgpp-workers AT delorie DOT com, robert DOT hoehne AT gmx DOT net
Subject: Re: GCC incompatibilities
In-Reply-To: <199808241743.AA247760603@typhoon.rose.hp.com>
Message-ID: <Pine.SUN.3.91.980825143624.7520F-100000@is>
MIME-Version: 1.0

On Mon, 24 Aug 1998, Andrew Crabtree wrote:

> > compatibility problems between object files produced by 
> > different versions of GCC.
> In many cases, yes.  Most seem to be related to c++ stuff.

Are there *any* problems whatsoever related to C?  For example, is the
stock libc.a good for GCC 2.8.1/EGCS/PGCC?

> The biggest gotchas here have been exception handling and rtti I
> think.

Is Robert's recommendation to use -fno-exceptions -fno-rtti at all
relevant to C programs which mix objects compiled by different
versions of GCC?

> These are usually easy to find because you will get unresolved externals
> when linking.

Unfortunately, many DJGPP users get utterly confused when they see
unresolved externals.  A large part of the FAQ is devoted to sorting
these problems out, and they still get confused.

> No.  This is another (maybe another 2 issues).  The crt code for 
> djgpp 2.01 doesn't align the stack.  Its not an incompatibility, but
> it can slow things down a lot.  I recommend that people recompile
> all of their libs with pgcc just to get the small speed increase.  It 
> is not actually required ..... unless you want to use any of the -m 
> options that break the abi

Do I understand correctly that the stack alignment issue (corrected in
v2.02, btw) only affects speed *iff* one of those -mXXX switches are
used, but otherwise has no effect?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019