Fedora and Cross Compiling

Brendan Conoboy blc at redhat.com
Wed Jun 13 21:59:47 UTC 2007


David Woodhouse wrote:
  > Do we _actually_ need to build parts of glibc? Could we not get away
> with a fake DSO which just provides the few symbols libgcc uses?

You can do that, but it's a bad idea.  Since glibc is a moving target, 
libgcc's configurey might not turn on something that is valid because it 
can't detect the support for it.  That's why we have the two stage 
process to begin with.

> Or do we even need to build the dynamic libgcc _with_ the compiler at
> all?

Need?  Depends on what you're willing to put into it...

> Actually it happens for me every time I build a cross-compiler.
> But perhaps it doesn't _need_ to; you're right.

What if you're not building from scratch- instead building iteratively? 
  What if it's in Fedora so you aren't building one in the first place?

> That's a very good place to start. Especially if you realise that it
> doesn't _really_ restrict us to 'existing architectures' -- it restricts
> us to those architectures for which we can cobble together 'native'
> packages for gcc, etc. Which is actually not much of a restriction at
> all.

Yep, seems like an excellent starting point.  Especially while gcc is 
being disentangled.

> That would be an interesting answer, yes. It only solves the _build_
> part of the problem though. The packaging side remains -- you'll want to
> end up a cross-compiler package for the host arch, but libgcc etc. for
> the target.
> 
> RPM doesn't currently let you spit out even .noarch.rpm and $ARCH.rpm
> simultaneously -- to build both i686-linux-gnu-gcc-$V-$R.ppc.rpm and
> libgcc-$V-$R.i386.rpm you'll almost certainly need a separate rpmbuild
> run _anyway_. So how will we handle that?

Cross compile the native compiler.  You need one anyway.  All the 
resulting packages are target arch.  Your cross compiler can then depend 
on the native compiler's libgcc rpm for the next iteration.

> I think we need to accelerate [splitting gcc libs] rather than waiting for it.

The wait might be so long.  Libgcc is a subdiectory of gcc in upstream 
development (to be 4.3).

-- 
Brendan Conoboy / Red Hat, Inc. / blc at redhat.com




More information about the fedora-devel-list mailing list