This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How to prevent multilib builds if OS support missing?
- From: Ulrich Weigand <weigand at immd1 dot informatik dot uni-erlangen dot de>
- To: rth at redhat dot com
- Cc: uweigand at de dot ibm dot com, gcc at gcc dot gnu dot org
- Date: Wed, 27 Nov 2002 00:50:29 +0100 (MET)
- Subject: Re: How to prevent multilib builds if OS support missing?
Richard Henderson wrote:
>--disable-multilib?
Well, yes, but then gcc tries to find the 64-bit system libraries
in /usr/lib, where they aren't ...
What I need to build gcc on, say, SuSE SLES-7 for zSeries is a
setup where the 64-bit system libraries are taken from /usr/lib64
(just like the multi-lib setup with MULTILIB_OSDIRNAMES does),
but no attempt to build the 31-bit libraries is made (because in
/usr/lib there is just enough to support *running* 31-bit binaries,
but not *building* them.)
I had been looking to achieve that by running with --enable-multilib,
but removing the -m31 variant from the list of multilibs. However,
this doesn't work for libgcc_s, it appears.
(Actually, besides the full multilib scenario as in SLES-8 and
the just mentioned /usr/lib64 64-bit only scenario as in SLES-7,
there is a third variant: the 64-bit only scenario with system
libraries in /usr/lib, like in e.g. Red Hat 7.1 for zSeries.
*This* can be handled via --disable-multilib just fine, but the
ideal solution would be to automatically discover that during
configure, so that everything just works on all distributions
currently in use on our platform ;-))
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de