[Clfs-dev] Embedded clfs problems and workarounds

Joe Ciccone jciccone at gmail.com
Thu Feb 10 17:38:38 PST 2011


On Tue, 2011-02-08 at 07:28 -0500, Andrew Bradford wrote: 
> On Mon, Feb 7, 2011 at 4:54 AM, Adrian Grigo <agrigo2001 at yahoo.com.au> wrote:
> > Well, after testing it again it seems I will have to eat my words. It appears that support for large files is the default setting in uclibc configuration for x86_64.
> >
> > I still need --disable-multilib to allow the final gcc stage to compile.
> >
> 
> If building GCC with --disable-multilib, would the -m32 or -m64 stored
> in the ${BUILD} variable still be needed in order to build packages?
> Or does GCC outputting 32 or 64 bit code not count as a library?
> 
> Do you know what the other implications of --disable-multilib are on
> x86?  (I don't)
> 
> Thanks,
> -Andrew
> _______________________________________________
> Clfs-dev mailing list
> Clfs-dev at lists.cross-lfs.org
> http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org

All of the gcc builds in embedded should have --disable-multilib if they
do not already.

If the target is i?86-*-*-* with or without --disable-multilib should
produce a compiler for 32bit only. If the target is x86_64-*-*-* with
--disable-multilib will produce a compiler for 64bit only. This is the
desired behavior in the embedded builds.

AFAIK GCC automatically will build a multilib compiler if the target
triplet is for a 64bit architecture that has a 32bit subset.

We really should have --disable-multilib everywhere in the embedded
builds. Since there is no multilib, there should be no reason to have to
specify -m32/-m64 via BUILD. The compiler should be built to produce the
appropriate output rather then being told on the command line at every
instance. Easily accomplished in non-multilib builds.

--
Joe Ciccone




More information about the Clfs-dev mailing list