egcs-1.1b on sco-3.2v5.0.4 gcc/pic/libgcc.a with mixed COFF and ELF files?

[Joao Cardoso]

> Re: egcs-1.1b on sco-3.2v5.0.4 gcc/pic/libgcc.a with mixed COFF and ELF files?
> 
> Robert Lipe (robertl@dgii.com)
> > I think that the following is incorrect.
> 
> It may be incorrect.   I'm unsure of the rules of this game.
> 
> > The system is sco-3.2v5.0.4, egcs-1.1b, and "/etc/default/cc" (the
> > default
> > cc options) is empty, generating COFF by default.
> >
> >
> > bash-2.02# pwd
> > /src/egcs-1.1b-objdir/gcc/pic
> > bash-2.02# ar x libgcc.a
> > bash-2.02# file *.o| fgrep iAPX
> 
> [ Things from libgcc1.a are COFF. ]

I have not tried, but what happens if the system has "/etc/default/cc"
set to build ELF by default? As CCLIBFLAGS is empty, I think that ELF
will be build and we will see only ELF files on gcc/pic and mixed ELF
and COFF on gcc/coff!

> The Makefiles go to a considerable amount of effort to be sure that
> libgcc1 components are _not_ built by the compiler being built.  In the
> OpenServer case with native cc, t his means libgcc1 is COFF.  This sure
> looks intentional to me.

What happens in other multilib systems? As the above files are generated
only during stage 1 of the build, with the native cc (that is gcc in
Linux), one has to decide as to build COFF or ELF for libgcc1.a? How can
this be in a multilib system?
 
> The OSR5 linker does DTRT when mixing simple COFF and ELF functions like
> this.

I remember seeing somewhere an advice as to not completely  trust on
this behaviour. And what happen on another multilib systems that have
not this capability?

> Is this actually causing you a problem, or is this just an observed oddity?

No problem, just a lack of regularity. It is just a call of attention of
what can be a potencial problem, I believe.

> RJL

Thanks,
Joao
-- 
Joao Cardoso                |   e-mail: jcardoso@inescn.pt
INESC, R. Jose Falcao 110   |   tel:	+ 351 2 2094322
4050 Porto, Portugal        |   fax:	+ 351 2 2008487