OSX sdk build issues (probably) due to libtool

[bamert]

While the toolchain build went fine, I am running into issues with libtool(Version 2.4.6) when building the SDK on OS X Yosemite, specifically when building libz.

The error message specifically is "(..) is not an object file (not allowed in a library)". Do any of you know how to resolve this?

Console output: https://gist.github.com/endeebee/ff30a6a12dde4b0a482aa06cf02bece0

[adriweb]

Just a random idea since I've come across similar things in the past with other programs: you might want to use GNU libtool and not the default one:

1. brew install libtool
2. brew link --force libtool to force symlink the new one
3. build the things you want
4. brew unlink libtool to restore the default libtool

Then again, I don't remember having this issue building the SDK on OS X... so this might not help :(

[bamert]

Wow that was fast, thanks for the reply! Unfortunately that didn't work and I'm getting the same errors. I'm thinking I might have build issues because I had armgcc as well as some other cross compilers installed before trying to build ndless(?).

EDIT: I think the problem is that libtool shouldn't be used at all, the issue is somewhere in the auto-generated makefile for zlib which uses AR=libtool, instead of the one for the target system. I'll post again if I find a fix!

[Vogtinator]

I might have build issues because I had armgcc as well as some other cross compilers installed before trying to build ndless(?).

If arm-none-eabi-gcc in your $PATH is not the one built by the SDK, it won't work. If it is, however, can you provide the output of file for the *.o files that somehow aren't object files?

[Vogtinator]

I think the problem is that libtool shouldn't be used at all, the issue is somewhere in the auto-generated makefile for zlib which uses AR=libtool, instead of the one for the target system. I'll post again if I find a fix!

Indeed, it should use arm-none-eabi-ar directly instead. Pinging @Legimet as he did the zlib integration into thirdparty/.

[bamert]

I removed #AR="libtool" in the section for Darwin in the configure script for zlib and instead set CC to the correct arm-none-eabi-g++, which made zlib compile fine, however I'm now stuck at a later stage in building; - genzehn is producing some errors because of boost. That is unrelated though and I'll open a separate issue for it if I can't find a fix.

[adriweb]

Regarding the boost issue, have you tried brew install boost?

Compiles fine here (with both -lboost_program_options and -lboost_program_options-mt): g++ -Wall -Wextra -std=c++11 -I elfio-2.2 genzehn.cpp -lboost_program_options -lz -o genzehn

[Legimet]

I will make a PR to fix this some time today.

On Friday, July 22, 2016 04:57:00 AM Fabian Vogt wrote:

I think the problem is that libtool shouldn't be used at all, the issue is somewhere in the auto-generated makefile for zlib which uses AR=libtool, instead of the one for the target system. I'll post again if I find a fix! Indeed, it should use arm-none-eabi-ar directly instead. Pinging @Legimet as he did the zlib integration into thirdparty/.

---

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/ndless-nspire/Ndless/issues/44#issuecomment-234525250

[bamert]

@adriweb I do have boost, the problem was that I didn't like Apple's practises of symlinking g++ to clang, so I changed that in the past. What I had to do to compile now was change the g++ in the Makefile for genzehn to clang++. I can now cross-compile for Nspire. Thanks for the help guys!

I will leave this open so that @Legimet can close it after patching.