On Sun, Sep 30, 2007 at 10:01:06PM +0100, Neil Williams wrote: > Mark Brown <[EMAIL PROTECTED]> wrote:
> > 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. I'm sorry but with the existing packages this does not seem to correspond to what is happening at all. > > A build log might be useful... > Attached. This build log does not correspond to the errors you are reporting at all. It also seems to be from a version which you have modified. The error seen here is: | arm-linux-gnu-ar libz.a adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o zutil.o inflate.o infback.o inftrees.o inffast.o | arm-linux-gnu-ar: illegal option -- z which is nothing to do with GCC at all. I also can't see anything in the log that suggests that a version of GCC other than the configured cross compiler is being used. Earlier you reported that: > 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 > thereby only accept an override via MAKEFLAGS which needs to be set via but I really can't see how that is happening. Looking at line 19 of Makefile.in there is an explicit variable for the compiler. This is set in the sed at the end of the configure script. This method is used to configure the compiler to use for biarch builds so I'm very confident that the correct compiler is used. > > 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, Yes, I know. Fortunately zlib uses compilation tests only so it can quite happily run on the host. I rather suspect that the problem which you are actually seeing is that since no effort is made to tell the vanilla configure script that we are cross compiling the package builds host binaries - cross compilation has never worked since the configure script was used and it's nothing to do with any dpkg-cross changes. I'm going to upload a fix on that basis. If the new version fails then please supply a build log showing the problem with the unmodified package. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
signature.asc
Description: Digital signature
