Open apowers313 opened 6 years ago
I have the same problem, after running following commands I'm able to successfully run tests for libtool.
ar cru libz.a adler32.o crc32.o deflate.o infback.o inffast.o inflate.o inftrees.o trees.o zutil.o compress.o uncompr.o gzclose.o gzlib.o gzread.o gzwrite.o
ranlib libz.a
It looks like you can set the CHOST
environment variable to your target triple to get the right behaviour: https://github.com/madler/zlib/blob/master/configure#L33
Similarly, if you're cross-compiling to macOS, the configure script tries libtool
from your path, instead of ${CROSS_PREFIX}libtool
, resulting in a hardcoded /usr/bin/libtool
.
Similarly, if you're cross-compiling to macOS, the configure script tries
libtool
from your path, instead of${CROSS_PREFIX}libtool
, resulting in a hardcoded/usr/bin/libtool
.
Where is CROSS_PREFIX defined?
Dear all,
Can you test the current devel branch?
What are your results?
Thanks in advance.
Cross compiling on the latest code in the develop branch still breaks things.
/.../Library/Android/sdk/ndk/25.2.9519653//toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang -fbuild-session-timestamp=1234567890 -fdebug-compilation-dir . -no-canonical-prefixes -Os -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o gzwrite.o gzwrite.c
libtool -o libz.a adler32.o crc32.o deflate.o infback.o inffast.o inflate.o inftrees.o trees.o zutil.o compress.o uncompr.o gzclose.o gzlib.o gzread.o gzwrite.o
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: adler32.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: crc32.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: deflate.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: infback.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: inffast.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: inflate.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: inftrees.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: trees.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: zutil.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: compress.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: uncompr.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: gzclose.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: gzlib.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: gzread.o is not an object file (not allowed in a library)
error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: gzwrite.o is not an object file (not allowed in a library)
make[1]: *** [libz.a] Error 1
make: *** [zlib-build-stamp] Error 2
I'm cross compiling with a mac targeting an android/linux system (in this case ABI arm64-v8a...)
As you can see zlib's code is compiled with the current Android NDK but then is linked with my mac's libtool
which fails.
Similarly, if you're cross-compiling to macOS, the configure script tries libtool from your path, instead of ${CROSS_PREFIX}libtool, resulting in a hardcoded /usr/bin/libtool.
The problem is the exactly as @terinjokes stated 3.5 years ago.
I tore up the makefile by hand and successfully got my zlib.a file by hardcoding in the llvm-ar
that's distro'd as part of the android NDK
I'm attempting to cross-compile for an Android (Linux) ARM target from an OSX host. Around line 238 of the
configure
script, there seems to be a bad assumption about only usinglibtool
if you're on OSX / Darwin:Since OSX's libtool doesn't understand ELF executables, the build eventually fails with: