Guillem Jover wrote: > Hi, > > [ I don't have a real opinion yet on the initial patch and this > changes proposed, will try to get to this on Sunday. ]
OK, thanks, Guillem. I'd like to get this resolved asap. > On Sat, 2007-12-08 at 19:01:14 +0000, Neil Williams wrote: >> Raphael Hertzog wrote: >>> On Wed, 05 Dec 2007, Neil Williams wrote: >>>> My first patch did exactly that - and failed on building a cross >>>> compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the >>>> preparation of libgcc1-$arch-cross and other libraries used in the >>>> complete toolchain. It needs (and sets) DEB_TARGET_GNU_TYPE != >>>> DEB_BUILD_GNU_TYPE at other stages of the build. >>> If that's the case, I'd like to know if this is deliberate and really >>> required... can't the gcc package be consistent and always have both >>> DEB_TARGET_GNU_TYPE and DEB_BUILD_GNU_TYPE properly set ? > >> Even if gcc changes that behaviour in 4.2 (or 4.3), lots of people still >> need to be able to build cross compilers from older versions of gcc, >> especially 4.1 and some even need 3.3 or 3.4. > > Why can't 4.1 and 3.4 be "fixed" (if that's really needed) as well? > 3.3 might be a problem, but even then you have to build them locally > to support cross-compiling, why can't they be patched locally as well? Local patches are *hell* to maintain - that is why I need to remove the dpkg-cross diversions in the first place. We had local patches for years, we've got passed that stage (thankfully) and desperately need usable cross building support *within* Debian and stop this crazy "patch upon patch upon diversion" approach. Emdebian cannot build, patch or test every permutation of toolchain that people need so this isn't about "us" patching locally, it is about lowering the barrier to cross building on Debian by not forcing every user to patch locally. This is why we are at the current impasse - too many permutations. Why propose changing every version of gcc (a process that could take extreme amounts of time to test, implement and get into testing) and then make it impossible to build cross compilers in Etch? Are we looking at backports as well?? Who is going to do all that work? (Not me, before anyone asks.) This is a problem within dpkg, not actually within gcc. It makes far more sense to change one line in one script than to change every version of gcc. dpkg-shlibdeps is (and has always been) broken with regard to building cross compilers or cross built packages. Various solutions have been created due to this long, long breakage and things are working nicely, all the way back to gcc-3.3 and Etch (possibly earlier). Now that we finally have a chance to fix dpkg-shlibdeps, why must all the previous work be undone? For the sake of one environment variable? This bug is about *removing* the dpkg-cross diversions, not *rewriting* them - changing every gcc package is simply not workable IMHO and the only real alternative to dpkg-shlibdeps supporting $ARCH is for me to write a new diversion of dpkg-shlibdeps that *does* check the value of $ARCH and forces the value of LD_LIBRARY_PATH when building a cross compiler. That would just be a hack so please, can we just check $ARCH in dpkg-shlibdeps? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
