On Sun, 30 Sep 2007 21:16:36 +0100 Mark Brown <[EMAIL PROTECTED]> wrote:
> > It doesn't work via configure. The very first thing I tried > > was ./configure --build --host etc. That is always the first thing I > > try - it is the standard way of working with cross-building. > > So then the patch either needs to fix the source to ensure that this > works or do something else to ensure that the configuration chosen is > correct for the target platform. That said... > > > gcc is still run for the top level make file because the Makefile > > doesn't use a variable for setting CC, it sets it directly and will > > Could you provide some more detail where this goes wrong, please? Sure. The difficulty here is that this bug appears from code that is mid-transition. The current code in Debian unstable works but only because the underlying bug in those scripts is still present. The new code relies on a variety of CVS and SVN packages that are close to release but I have built a variety of packages that built successfully with the old versions and zlib is the only one so far to show any problems. I'll try to provide whatever information you need because it isn't easy to replicate the situation until changes in dpkg allow changes in dpkg-cross and the rest of the transition can then follow. I'm hoping that the dpkg changes will be uploaded in a few days and then it'll be easier to replicate the bug. Equally, once the new packages are uploaded, various people are going to want to cross-compile zlib for their own systems and that's not going to work. > Checking the code in the configure script it appears to try to propagate > the CC it was given to the Makefile and in a brief test (I don't have a > second compiler to try here) it certainly appears to pass through the > appropriate compiler. Well, it does in part but not in all - the top level is certainly wrong. Subsequent parts correctly find arm-linux-gnu-gcc but when these binaries try to link against the code compiled with gcc in the top level directory, predictably, it fails. > A build log might be useful... Attached. The previous successful build log is available in Emdebian SVN at http://buildd.emdebian.org/svn/browser/current/target/trunk/z/zlib/trunk/zlib_1%3A1.2.3-13em1_arm.build > The other way to look at it is that fixing the upstream build system > will benefit not only emdebian users but also anyone else cross > compiling zlib. Unless there is a strong reason to do something Debian > local it's preferable to make the fix that benefits the widest possible > audience. Fair enough. > > > I'm not enthusiatic about applying the patch as is due to the bypassing > > > of the configuration script. > > > If the configuration script worked, I wouldn't need the patch. > > :-( > > Like I say, the configuration script is doing things that affect the > generated library Cross-building inevitably means working with the configuration scripts to handle precisely that. Should it be necessary, cache files can be used to pass configure values that replicate the host environment instead of allowing detection of the build environment. Whichever way, cross-building involves persuading the upstream configuration scripts that the build system is something it is not - the host. Sometimes that means completely disabling entire sets of configuration steps - there isn't always a way of resolving that upstream. > and fixing the upstream build system is a more > generally useful solution anyway. True. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
zlib_1:1.2.3.3.dfsg-5em1_arm.build
Description: Binary data
pgpJcmG49BjK7.pgp
Description: PGP signature
