public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
@ 1998-12-01 21:58 Kaveh R. Ghazi
  1998-12-02 16:57 ` libiberty Alex Buell
  1998-12-02 18:34 ` egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries Jim Wilson
  0 siblings, 2 replies; 14+ messages in thread
From: Kaveh R. Ghazi @ 1998-12-01 21:58 UTC (permalink / raw)
  To: law, wilson; +Cc: egcs

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
@ 1998-12-02  6:05 N8TM
  1998-12-02 12:12 ` Jim Wilson
  0 siblings, 1 reply; 14+ messages in thread
From: N8TM @ 1998-12-02  6:05 UTC (permalink / raw)
  To: ghazi, law, wilson; +Cc: egcs

In a message dated 12/2/98 3:08:24 AM Pacific Standard Time,
ghazi@caip.rutgers.edu writes:

<< > # 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.
   >>
That's asking a bit too much.  The SGI compilers issued in the last year have
been perfectly capable of bootstrapping gcc and egcs from 'cc -n32'.  The last
bad version was MipsPro 7.1, and that was a real turkey.  How is some scheme
which worked for someone with gcc at one time supposed to solve the problem of
bootstrapping egcs with every buggy and not-so-buggy compiler version SGI has
ever issued?

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
@ 1998-12-03  6:09 N8TM
  1998-12-03 13:22 ` Jim Wilson
  0 siblings, 1 reply; 14+ messages in thread
From: N8TM @ 1998-12-03  6:09 UTC (permalink / raw)
  To: wilson, ghazi; +Cc: law, egcs

In a message dated 12/3/98 3:00:21 AM Pacific Standard Time, wilson@cygnus.com
writes:

<<  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. >>
I had trouble bootstrapping egcs with 7.1 (-o32 didn't work either), but 7.2
has been out for more than a year, and it has not given any problem with -n32.

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
@ 1998-12-07 13:20 Kaveh R. Ghazi
  1998-12-07 22:34 ` Jeffrey A Law
  0 siblings, 1 reply; 14+ messages in thread
From: Kaveh R. Ghazi @ 1998-12-07 13:20 UTC (permalink / raw)
  To: wilson; +Cc: egcs, law

 > From: Jim Wilson <wilson@cygnus.com>
 > 
 > If we add -n32, people that have old versions of the SGI C compiler won't
 > be able to build egcs anymore.

	Right.


 > However, I suspect that few people have
 > these old and buggy SGI C compilers anymore.


	I think historically we've tried to support as many cc setups as
we could.  (Note how old K&R compilers are, yet we still support them.)
I'm not enthusiastic about hosing users of older (pre-7.1) SGI compilers.



 > 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.


	Eww, gross. :-)  But thanks for the info.



 > 
 > 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.


	Yes I suppose.  I think something similar is done in the emacs
sources by setting NON_GNU_CC and NON_GNU_CFLAGS.



 > 
 > 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.

	Right, we have to solve it for both or it does not good
('cause we have to ensure libiberty.a is link compatible 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

	I'm not thrilled with a cc -n32 solution, since it screws some
pre-7.1 SGI users.  I also think it would be a lot of work to get the
cc -n32 via config/mh-* working given the description you wrote above. 
I am not cygnus-configure literate, so it would be a real pain to
implement. 

	IMHO, the right way to go is to rebuild libiberty at each stage
in the gcc directory.  Ignore all the $target/libiberty stuff.  Instead,
in the build process of gcc, we can run symlink-tree on ../libiberty and
build it similar to how we build the language subdirs (except we do it
before anything else in the stage.) Then link everyone with that copy of
libiberty.a.  In between stages, we move the symlink-tree libiberty
directory into stageN so it gets rebuilt.  (Also we can add it to the
make compare rule for added consistency checking.)

	This is something we'll have to do anyway to get canadian
crosses working since we have to build a separate libiberty.a with
$CC_FOR_BUILD as well as one with $CC.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
@ 1998-12-07 14:06 Kaveh R. Ghazi
  1998-12-07 22:31 ` Jeffrey A Law
  0 siblings, 1 reply; 14+ messages in thread
From: Kaveh R. Ghazi @ 1998-12-07 14:06 UTC (permalink / raw)
  To: law, wilson; +Cc: egcs

 > From: Jeffrey A Law <law@hurl.cygnus.com>
 > 
 >   > 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.

	But what exactly do you fall back on if -n32 doesn't work?  I.e. 
assuming I have a pre-7.1 compiler, I am now unable to build egcs when we
try to link with libiberty.a (assuming the redundant libiberty functions
had been out of the gcc sources.)


 > 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?

	Let's say we can test for compiler versions.  AFAICT, we have
nothing to offer when we detect the pre-7.1 compilers.  (Unless I'm
missing something....)


 > As Jim mentioned, the config/mh-* stuff is pretty hokey and needs a rethink.

	Agreed.



 >   > 	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.

	I'm not sure its so hard.  See my previous email.  I think we
can ignore the $target stuff.  We can simply run symlink-tree on
../libiberty and build that directory at each stage. 


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

	Yes, I would agree if (and only if) we could make cc -n32 work
for all users.  Otherwise we cut adrift a small group who previously
could have used egcs. 

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.

^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~1998-12-07 22:34 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-12-01 21:58 egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries Kaveh R. Ghazi
1998-12-02 16:57 ` libiberty Alex Buell
1998-12-03 21:18   ` libiberty Jeffrey A Law
1998-12-02 18:34 ` egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries Jim Wilson
1998-12-04  6:00   ` Jeffrey A Law
1998-12-04 12:55     ` Jim Wilson
1998-12-02  6:05 N8TM
1998-12-02 12:12 ` Jim Wilson
1998-12-03  6:09 N8TM
1998-12-03 13:22 ` Jim Wilson
1998-12-07 13:20 Kaveh R. Ghazi
1998-12-07 22:34 ` Jeffrey A Law
1998-12-07 14:06 Kaveh R. Ghazi
1998-12-07 22:31 ` Jeffrey A Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).