egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...

egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...

[Kaveh R. Ghazi]

Hi Jim,

	I'd like to get your opinion on a problem I'm having on Irix6
when building egcs.  (This is cc'ed to the egcs list so everyone is
welcome to comment.)  I've summarized the main issues below. 

	The central problem arises when attempting to use libiberty.a
to link binaries.  Libiberty.a is built with the stage1 compiler.  The
problem I have occurs when I use cc for stage1.  By default, Irix6 cc
uses a different ABI than gcc so I can't link (o32 ABI) libiberty.a
with stuff built in stage2/3 (n32 ABI).

	Right now, I've made sure egcs never needs anything from
libiberty.a so none of the links with it pull in any of its modules. 
But if I make egcs use libiberty.a by nuking xmalloc from toplev.c, I
get the following error:

 > ld: FATAL 112: cannot link old 32-bit object with -n32 link:
 > 	../libiberty/libiberty.a(xmalloc.o).
 > collect2: ld returned 4 exit status

	Now if I use "cc -n32" for stage1, I can get it to work.  But
there are some problems with this.  I looked in egcs/config/mh-irix6
and found this:

 > # Specify the ABI, to ensure that all Irix 6 systems will behave the same.
 > # Also, using -32 avoids bugs that exist in the n32/n64 support in some
 > # versions of the SGI compiler.
 > CC = cc -32

	So it seems to be saying that there are bugs in n32 so we
can't use it?  Note the file already sets cc to use the -32 flag
(o32).  However egcs ignores this setting!  (Confused yet?)  It just
goes ahead and sets CC to either "cc" or "gcc" depending on what is
available.  I think this is a side effect of when we decided to let
autoconf choose CC.

	So we have the following issues:

1.  If Irix6 cc is used for stage1, should we add -n32 so when it
builds libiberty.a it is link compatible with stage2 binaries?

2.  Is "cc -n32" support truly buggy, or can we use it?

3.  If cc is used for stage1, libiberty.a is not optimized, it only
gets -g passed to it.  Do we care?  (This is a generic problem, not
an irix6 specific one.)

4.  Assuming we go with -n32, why is egcs ignoring the CC setting in
config/mh-irix6 and how do we fix it?  (This doesn't seem to be Irix6
specific either.)

5.  Maybe another way to go is to build libiberty.a for each stage.
We could build a symlink tree in egcs/gcc/libiberty and move it into
stageN so it is rebuilt every stage.  This would solve the linking
problem because libiberty.a would use the same ABI as the binaries it
is linked with.  It would also get us optimized versions of the
functions in there even when cc is used for stage1.

	Any insight you could provide would be appreciated.

		Thanks,
		--Kaveh

PS: Jeff already recommended against item 5 above and instead wants to
do something like passing a flag to make libiberty.a link compatible. 
However I am cautious because of the n32 bugginess comment above and
also because this means libiberty.a won't be optimized.  (I don't know
if that is significant though.) So I am seeking more information.  Thanks.
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.

libiberty

[Alex Buell]

Following up on someone's posting about libiberty, this question has been
bugging me for a while. Why does so many software (i.e egcs, gcc,
binutils, gdb) comes with their own libiberty sources?

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Grow some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!

Linux tahallah 2.1.130 #64 SMP Thu Nov 26 22:58:37 EST 1998
Two Intel Pentium Pro 166MHz processors, 331.78 total bogomips, 48M RAM
System library 2.0.104

Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...

[Jim Wilson]

	1.  If Irix6 cc is used for stage1, should we add -n32 so when it
	builds libiberty.a it is link compatible with stage2 binaries?

I don't care which choice is used, as long as I can still build gcc.

If we add -n32, people that have old versions of the SGI C compiler won't
be able to build egcs anymore.  However, I suspect that few people have
these old and buggy SGI C compilers anymore.

	2.  Is "cc -n32" support truly buggy, or can we use it?

Every SGI compiler I tried up through 7.0beta had a bug that caused gcc to
be miscompiled.  7.0beta had only a single bug, which caused an optimization
to be disabled, but did not cause bad code.  Hence if using 7.0beta, a
stage2/stage3 comparison would fail, but a stage3/stage4 comparison would
succeed.  The one bug I reported against 7.0beta was fixed in 7.1.  All
versions prior to 7.0beta have serious bugs that can not be worked around
easily.

I never tested any compiler after 7.0beta, by then I had gotten in the habit
of always using cc -32 when using the SGI compiler.  My suspicion though
is that bootstrapping with -n32 would work with 7.1 and later compilers.
The 7.1 compilers have probably been out for 2 years or so by now.

	3.  If cc is used for stage1, libiberty.a is not optimized, it only
	gets -g passed to it.  Do we care?  (This is a generic problem, not
	an irix6 specific one.)

No, we don't care.

	4.  Assuming we go with -n32, why is egcs ignoring the CC setting in
	config/mh-irix6 and how do we fix it?  (This doesn't seem to be Irix6
	specific either.)

The config/mh-irix6 stuff was inherited from Cygnus when we adopted the
Cygnus top level configuration directory.  This stuff stopped working for
Cygnus when Ian Taylor fixed a toplevel configure bug.  That was sometime in
1997 I believe.  I don't think anyone has seriously looked at this issue, but
my feeling is that we can't make CC definitions in config/m*-* files work
anymore, because this is inconsistent with other features of configure.
And for the same reasons, setting CFLAGS there won't work either.  It is
probably a bit of work to fix this.  I think we would need to create a new
toplevel host dependent compiler option variable, which can be set in a
config/m*-* file, and then modify configure and/or Makefile to pass it along
with CFLAGS to the host CC.

My recollection of the exact problem with the toplevel configure file is
hazy, but it has something to do with the fact that CC and CFLAGS are allowed
to be specified by the user.  Hence we get them from the user if the user
specified them, otherwise we use gcc if it exists, otherwise we default to cc.
There is a complication here when reconfiguring after an update, e.g.
	./config.status --recheck
which needs to get CC from the Makefile, because there might be a user
specified value there from the original configure command.  The changes to
make this work right are what caused the config/m*-* file to stop working.

Hmm, maybe we can make configure default to DEFAULT_CC instead of cc, and
then let a config/m*-* file override DEFAULT_CC?  This probably requires fixing
the code that re-extracts CC from the Makefile though.

You didn't mention it, but there is also a gcc/config/mips/x-irix6 file which
specifies `cc -32'.  This part is from gcc2, and this part broke when gcc2
adopted autoconf.  Similarly, I don't think we can make this work anymore
without using a different makefile variable.  We have X_CFLAGS, but I don't
know whether that works anymore either.  I suspect it does work, however,
this doesn't help with libiberty, it only helps with gcc.

	5.  Maybe another way to go is to build libiberty.a for each stage.
	We could build a symlink tree in egcs/gcc/libiberty and move it into
	stageN so it is rebuilt every stage.  This would solve the linking
	problem because libiberty.a would use the same ABI as the binaries it
	is linked with.  It would also get us optimized versions of the
	functions in there even when cc is used for stage1.

We already have an N32 libiberty in $target/libiberty.  This is needed because
libstdc++/libio use libiberty, and they will be N32 code.  This does not get
built until after gcc has bootstrapped currently.  It might be possible to
build it after the stage1 gcc build, and then link the stage2/stage3 compilers
with it.  This would require rewriting the bootstrap rule in the toplevel
Makefile.

Jim

PS I have version 7.1 of the SGI C compiler on my machine.  I am trying a
cc -n32 bootstrap just to see what happens.

Re: libiberty

[Jeffrey A Law]

  In message < Pine.LNX.4.05.9812021936100.5310-100000@tahallah.demon.co.uk >you 
write:
  > Following up on someone's posting about libiberty, this question has been
  > bugging me for a while. Why does so many software (i.e egcs, gcc,
  > binutils, gdb) comes with their own libiberty sources?
Because each package has its own release schedule.


jeff

Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...

[Jeffrey A Law]

  In message < 199812022104.NAA03634@rtl.cygnus.com >you write:
  > 	1.  If Irix6 cc is used for stage1, should we add -n32 so when it
  > 	builds libiberty.a it is link compatible with stage2 binaries?
  > 
  > I don't care which choice is used, as long as I can still build gcc.
That is the ultimate goal :-)


  > If we add -n32, people that have old versions of the SGI C compiler won't
  > be able to build egcs anymore.  However, I suspect that few people have
  > these old and buggy SGI C compilers anymore.
We can always have autoconf test for -n32 when building with the native
compiler and fall back to something else.

  > 	2.  Is "cc -n32" support truly buggy, or can we use it?
  > 
  > Every SGI compiler I tried up through 7.0beta had a bug that caused gcc to
  > be miscompiled.  7.0beta had only a single bug, which caused an
  > optimization to be disabled, but did not cause bad code.  Hence if using
  > 7.0beta, a stage2/stage3 comparison would fail, but a stage3/stage4
  > comparison would succeed.  The one bug I reported against 7.0beta was
  > fixed in 7.1.  All versions prior to 7.0beta have serious bugs that can
  > not be worked around easily.
Is there a way to test for specific versions of the SGI compiler?  Do we
even want to worry about beta versions of the SGI compiler?

  > 	3.  If cc is used for stage1, libiberty.a is not optimized, it only
  > 	gets -g passed to it.  Do we care?  (This is a generic problem, not
  > 	an irix6 specific one.)
  > 
  > No, we don't care.
Agreed.  It's in the noise.

  > 	4.  Assuming we go with -n32, why is egcs ignoring the CC setting in
  > 	config/mh-irix6 and how do we fix it?  (This doesn't seem to be Irix6
  > 	specific either.)
As Jim mentioned, the config/mh-* stuff is pretty hokey and needs a rethink.

  > You didn't mention it, but there is also a gcc/config/mips/x-irix6 file
  > which specifies `cc -32'.  This part is from gcc2, and this part broke when gcc2
  > adopted autoconf.  Similarly, I don't think we can make this work anymore
  > without using a different makefile variable.
Right.  And the general though was most of that stuff needs to disappear too.

  > 
  > 	5.  Maybe another way to go is to build libiberty.a for each stage.
  > 	We could build a symlink tree in egcs/gcc/libiberty and move it into
  > 	stageN so it is rebuilt every stage.  This would solve the linking
  > 	problem because libiberty.a would use the same ABI as the binaries it
  > 	is linked with.  It would also get us optimized versions of the
  > 	functions in there even when cc is used for stage1.
  > 
  > We already have an N32 libiberty in $target/libiberty.  This is needed
  > because libstdc++/libio use libiberty, and they will be N32 code.  This
  > does not get built until after gcc has bootstrapped currently.  It might
  > be possible to build it after the stage1 gcc build, and then link the
  > stage2/stage3 compilers with it.  This would require rewriting the
  > bootstrap rule in the toplevel Makefile.
Jim's actually got a good point.  Doing this would require a fair amount of
surgery on the build process, but if other options don't pan out, I guess
it's what we'll have to do.

Still I think it is best if we can force the stage1 compiler to be link
compatible with the stage2/stage3 compilers.

jeff

Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...

[Jim Wilson]

	Is there a way to test for specific versions of the SGI compiler?

ada<43>/usr/sbin/versions -b c_dev
I = Installed, R = Removed

   Name                 Date      Description
I  c_dev                10/13/97  C, 7.1
ada<44>

"/usr/sbin/showprods -1 c_dev" will give the same output.

I don't know of a more convenient way to get the version number, but this
shouldn't be too hard to deal with in a script.

	Do we even want to worry about beta versions of the SGI compiler?

No.  I mentioned 7.0beta because it was the only 7.0 version I had tried.
It is reasonable to assume that 7.0 behaves the same way as 7.0beta did.

Jim

Re: Libiberty

[Bill Cunningham]

----- Original Message ----- 
From: "DJ Delorie" <dj@redhat.com>
To: <billcu1@verizon.net>
Sent: Thursday, June 01, 2006 10:31 PM
Subject: Re: Libiberty


> 
> Please don't reply to me personally, use the mailing list.

Sorry I just pressed reply. You personal address must have been there.

Bill

Re: Libiberty

[DJ Delorie]

>     I haven't found anything in the docs that I see that explains
> the libiberty library.

You didn't find the libiberty documentation?  It's separate from the
gcc documentation, but available on the gcc docs web page.

> Can this be compiled without having to compile a whole new compiler?

Er, yes, since that's what we do each time we build it for the build
and host machines.  Only the target libiberty is built with the
just-built compiler.

> I am running 3.4.6 and what to cross compile for a pdp-11. I just
> want to compile the extra support and that's all.

Extra support for what purpose?  Are you trying to use libiberty with
your own application?

Libiberty

[Bill Cunningham]

    I haven't found anything in the docs that I see that explains the
libiberty library. Can this be compiled without having to compile a whole
new compiler? I am running 3.4.6 and what to cross compile for a pdp-11. I
just want to compile the extra support and that's all.

Bill

Re: libiberty

[Mike Stump]

On May 2, 2006, at 6:08 AM, Bill Cunningham wrote:
>     Everytime I compile gcc I see that libiberty is being compiled.  
> Is this
> a needed library and if not how can I switch it off? I'm using  
> glibc-2.1 and
> I'd like to figure out compiling 2.3 and I've done it before so I  
> just have
> to remember how. I want to cut down on all that compile time.

cd gcc && make doesn't rebuild libiberty.  I use that to avoid  
recompiles.

RE: libiberty

[Dave Korn]

On 02 May 2006 14:09, Bill Cunningham wrote:

>     Everytime I compile gcc I see that libiberty is being compiled. Is this
> a needed library 

  Yes.  Gcc uses the support functions it provides.  It's compiled and
statically linked in to the new gcc.

>  I'm using glibc-2.1 and
> I'd like to figure out compiling 2.3 and I've done it before so I just have
> to remember how. 

  You've lost me there.  I thought you said you were compiling gcc?  Or do you
mean you're doing it as part of a combined-tree-build?

  In any case, libiberty is vital.  And small and quick to build.  'fraid I
don't have much useful advice on how to cut down your build times except maybe
to use a --disable-checking compiler.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

libiberty

[Bill Cunningham]

    Everytime I compile gcc I see that libiberty is being compiled. Is this
a needed library and if not how can I switch it off? I'm using glibc-2.1 and
I'd like to figure out compiling 2.3 and I've done it before so I just have
to remember how. I want to cut down on all that compile time.

Bill