This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: SH Linux and multilib


M. R. Brown writes:
 > * Andrew Haley <aph@cambridge.redhat.com> on Mon, Jul 30, 2001:
 > 
 > > Sure, I agree.  It's important that the user can build whatever they
 > > need -- the disagreement here is about what the default should do.  As
 > > you say, the default is at present unusable.
 > 
 > Huh?  From going over the thread, it seems like the disagreement is about
 > the ability to *pick* a default, rather than being forced to use SH3,
 > little-endian.

I'm not saying that anyone should be forced to use anything.
We need to add more configure options.

What I am saying is that the default sh-unknown-linux-gnu
configuration is wrong because it doesn't build on any SH Linux
system.

 > NIIBE's patches (although IMHO the wrong approach) allow you to do
 > that - and it's very convenient if you only target one particular
 > board.  The sh-unknown-linux-gnu still supports multilib,

Yes, but such a configuration doesn't build.  Well, it *might* build
if beforehand you built a bunch of glibc versions and figured out
where to put them, but that is not anything like the usual thing to
do.

I would have no objection whatsoever to this scheme if it did build,
by the way.  Having the -m[34] options is harmless and may well be
useful.  But the big endian multilib causes libstdc++ to fail to build
because it needs a compatible glibc.

 > so you have the option of using the -m[lb] and -m[34] options to
 > your whim to pull in the correct multilibs (for libgcc, libstdc++,
 > whatever).

 > It's irrelevant once you get to building glibc, since you can only
 > pick one target, but I don't think that's the issue at hand - for
 > whatever board you need glibc to run on, you just pass the -m*
 > options anyway.
 > 
 > My other point of contention w/ the sh[34] notation is that it
 > looks totally contrived when building sh-elf/sh-coff targets, as
 > there's no conformity with specifying targets.  But I still believe
 > a mechanism needs to be in place to pick a default other than
 > sh3el, preferably from the configure line, so the -m* options
 > become invisible.

Yes, I agree.  Totally!

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]