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@xxxxxxxxxx -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
