On Sun, Sep 30, 2007 at 06:12:13PM +0100, Neil Williams wrote: > On Sun, 30 Sep 2007 17:53:29 +0100 > Mark Brown <[EMAIL PROTECTED]> wrote:
> > You really need to do this via the configure script or similarly. > 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? 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. A build log might be useful... > debian/rules (or otherwise in the environment but debian/rules is the > most sensible way of doing that). Not if it doesn't ensure that the library produced is configured for the target system. 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. > > > cross-building environment. The current build does ignore that error but > > > I've wrapped the call to 'make test' in the attached patch for clarity. > > Please submit separate patches for separate issues. > ? make test failing is the same issue - it relates only to cross-builds ? It's possible for there to be more than one change related to cross building... > One issue, one patch. Your patch does at least two things: it ensures that the correct toolchain gets used and it also avoids running the testsuite if it is cross compiling. They're separate changes achieving separate things, only the first of which is required to actually cross build. I'd probably not apply the second since I would rather get the testsuite run if at all possible (some cross configurations will let that happen) > > 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 and fixing the upstream build system is a more generally useful solution anyway. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
signature.asc
Description: Digital signature
