* 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; 12+ 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] 12+ messages in thread
* Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
1998-12-07 13:20 egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries Kaveh R. Ghazi
@ 1998-12-07 22:34 ` Jeffrey A Law
0 siblings, 0 replies; 12+ messages in thread
From: Jeffrey A Law @ 1998-12-07 22:34 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: wilson, egcs
In message < 199812072120.QAA26265@caip.rutgers.edu >you write:
> 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.)
>
I'm not thrilled about it either. I can probably live with this though. In
large part because it plays into ....
> 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.
This makes the option more attractive since I suspect canadian cross builds
are probably more common than builds starting with old buggy sgi compilers :-)
jeff
^ permalink raw reply [flat|nested] 12+ 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, 0 replies; 12+ messages in thread
From: Jeffrey A Law @ 1998-12-07 22:31 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: wilson, egcs
In message < 199812072134.QAA26942@caip.rutgers.edu >you write:
> > 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 h
> ave
> > > 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.)
Seems to me you fall back to a cross compiler-like setup. ie, you build
a cross compiler and install it. That compiler can then be used to bootstrap
a native compiler.
Again, that's what we effectively have when the host compiler builds something
that is not compatible with what gcc produces. A cross compiler that happens
to be able to run on the host machine.
I would expect the cases where we need to do this are small. Even with systems
like hpux11 coming online.
jeff
^ permalink raw reply [flat|nested] 12+ 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; 12+ 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] 12+ messages in thread
* Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
1998-12-04 6:00 ` Jeffrey A Law
@ 1998-12-04 12:55 ` Jim Wilson
0 siblings, 0 replies; 12+ messages in thread
From: Jim Wilson @ 1998-12-04 12:55 UTC (permalink / raw)
To: law; +Cc: Kaveh R. Ghazi, egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
1998-12-02 18:34 ` Jim Wilson
@ 1998-12-04 6:00 ` Jeffrey A Law
1998-12-04 12:55 ` Jim Wilson
0 siblings, 1 reply; 12+ messages in thread
From: Jeffrey A Law @ 1998-12-04 6:00 UTC (permalink / raw)
To: Jim Wilson; +Cc: Kaveh R. Ghazi, egcs
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
^ permalink raw reply [flat|nested] 12+ 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, 0 replies; 12+ messages in thread
From: Jim Wilson @ 1998-12-03 13:22 UTC (permalink / raw)
To: N8TM; +Cc: ghazi, law, egcs
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.
I have never seen a problem with cc -32. Perhaps there was something
else wrong, e.g. a bug in some other program besides the compiler.
I did a bootstrap with SGI C 7.1 yesterday, and didn't run into any problems.
Jim
^ permalink raw reply [flat|nested] 12+ 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; 12+ 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] 12+ messages in thread
* Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
1998-12-01 21:58 Kaveh R. Ghazi
@ 1998-12-02 18:34 ` Jim Wilson
1998-12-04 6:00 ` Jeffrey A Law
0 siblings, 1 reply; 12+ messages in thread
From: Jim Wilson @ 1998-12-02 18:34 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: law, egcs
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.
^ permalink raw reply [flat|nested] 12+ 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, 0 replies; 12+ messages in thread
From: Jim Wilson @ 1998-12-02 12:12 UTC (permalink / raw)
To: N8TM; +Cc: ghazi, law, egcs
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?
cc -32 has always compiled gcc correctly for all versions of Irix6 and all
versions of the Irix6 IDO. Since there is no ongoing development work on
the O32 compiler anymore, it is reasonable to expect that it will never break.
That is why it works.
The same is not true for cc -n32. We would have the problem you mention if
we tried to use cc -n32.
Jim
^ permalink raw reply [flat|nested] 12+ 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; 12+ 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] 12+ messages in thread
* egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
@ 1998-12-01 21:58 Kaveh R. Ghazi
1998-12-02 18:34 ` Jim Wilson
0 siblings, 1 reply; 12+ 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] 12+ messages in thread
end of thread, other threads:[~1998-12-07 22:34 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-12-07 13:20 egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries Kaveh R. Ghazi
1998-12-07 22:34 ` Jeffrey A Law
-- strict thread matches above, loose matches on Subject: below --
1998-12-07 14:06 Kaveh R. Ghazi
1998-12-07 22:31 ` Jeffrey A Law
1998-12-03 6:09 N8TM
1998-12-03 13:22 ` Jim Wilson
1998-12-02 6:05 N8TM
1998-12-02 12:12 ` Jim Wilson
1998-12-01 21:58 Kaveh R. Ghazi
1998-12-02 18:34 ` Jim Wilson
1998-12-04 6:00 ` Jeffrey A Law
1998-12-04 12:55 ` Jim Wilson
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).