[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora and Cross Compiling

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

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

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 redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]