On Wed, 2007-06-13 at 15:59 -0600, Brendan Conoboy wrote: > 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. You're speaking of the things which libgcc requires from glibc. That really is a _minimal_ set of functions. Is there _anything_ it actually tries to automatically detect -- _anything_ which might be turned off in libgcc because autocrap thinks glibc won't support it? > > 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... Que? > > 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? Heh, the latter would be nice :) > 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. That works, if we can get the build system issues sorted out. RPM doesn't currently even handle arch-specific dependencies, let alone "I need foo.i386 and I need it in a /usr/i386-linux-gnu chroot" :) And since you're using the native packages in the sysroot, your cross-compiler package doesn't even need to bother building the shared libraries. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
