Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recent MacOS compile problems with Objective C sources #431

Open
agraef opened this issue Jun 17, 2024 · 11 comments
Open

Recent MacOS compile problems with Objective C sources #431

agraef opened this issue Jun 17, 2024 · 11 comments
Assignees

Comments

@agraef
Copy link

agraef commented Jun 17, 2024

Detail

I'm now getting these compile errors on a MacBook Air M1, running macOS 13.6.7 (22G720) with the latest Xcode (Version 15.2 (15C500b)) and Homebrew. This all used to compile fine up to some months ago. Latest Gem source from the master branch now gives me this:

Making all in imageIO
/bin/sh ../../libtool    --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src/Gem  -I../../src    -fobjc-arc -DPD -I/Applications/Pd-0.53-1.app/Contents/Resources/src    -g -O2 -MT gem_imageIO_la-imageIO.lo -MD -MP -MF .deps/gem_imageIO_la-imageIO.Tpo -c -o gem_imageIO_la-imageIO.lo `test -f 'imageIO.mm' || echo './'`imageIO.mm
libtool: compile: unable to infer tagged configuration
libtool:   error: specify a tag with '--tag'
make[2]: *** [gem_imageIO_la-imageIO.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Looks like libtool suddenly doesn't know how to compile Objective C++ code any more. The rest of the compile up to this point goes fine. Gem was configured and built with:

./autogen.sh
./configure --with-pd=/Applications/Pd-0.53-1.app/Contents/Resources/src
make

Any help much appreciated, thanks!

Gem Version

1659d62

Pd Version

0.53-1

Operating System

macOS

OS Version

Ventura 13.6.7 (22G720)

Which CPU are you using?

arm64 ("64bit ARM"; e.g. Apple Silicon,...)

@umlaeute
Copy link
Owner

unable to reproduce on our CI-builders (using Monterey).
which glibtool version is this?

@agraef
Copy link
Author

agraef commented Jun 18, 2024

% glibtool --version
glibtool (GNU libtool) 2.4.7
Written by Gordon Matzigkeit, 1996

Copyright (C) 2014 Free Software Foundation, Inc.

Which should be the same version as on Monterey, AFAICT.

@agraef
Copy link
Author

agraef commented Jun 18, 2024

Maybe it's the compiler? I'm using clang (from Xcode) here:

% gcc --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: arm64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Maybe I should install gcc from Homebrew and try again?

@agraef
Copy link
Author

agraef commented Jun 18, 2024

I tried with gcc-14 from Homebrew, but that gives me compile errors early on. I also tried setting just OBJCXX in the environment, but that doesn't help either, it gives the same error as before.

@agraef
Copy link
Author

agraef commented Jun 18, 2024

It looks like the issue might be with automake (1.16.5 in Homebrew), as the required --tag options seem to be missing everywhere in OBJCXX compilation in both the generated Makefile.in and Makefile files. Not sure how to fix this, though. :(

@agraef
Copy link
Author

agraef commented Jun 18, 2024

OK, it seems that running make with LIBTOOLFLAGS=--tag=CXX to make sure that the option is set everywhere fixes the issue. So at least I have a work-around now. :)

I'm still wondering what the root cause of the issue is. Looks like some glitch in homebrew's automake 1.16.5 to me. In fact, it seems that the automake bottle was updated some 9 months ago, but I haven't compiled Gem manually for quite some time, so I'm not sure when this stuff started breaking for me.

It's also curious that you don't see this issue on your CI. Do you run the same automake version from homebrew there?

@umlaeute
Copy link
Owner

thanks for checking. i will investigate my CI (but most likely it is something along the lines of: "the VMs have some tools (like automake) pre-installed, and we try to avoid updating unnecessarily to save time")

umlaeute added a commit that referenced this issue Jun 19, 2024
@umlaeute
Copy link
Owner

umlaeute commented Jun 19, 2024

so here's what is actually used on our CI:

tool path version
macOS - 12.5.1 (21G83)
autoreconf /opt/homebrew/bin/autoreconf 2.71
aclocal /opt/homebrew/bin/aclocal 1.16.5
glibtoolize /opt/homebrew/bin/glibtoolize 2.4.7
autoconf /opt/homebrew/bin/autoconf 2.71
autoheader /opt/homebrew/bin/autoheader 2.71
automake /opt/homebrew/bin/automake 1.16.5
compiler /usr/bin/g++ 14.0.0 (clang-1400.0.29.102) arm64-apple-darwin21.6.0
Xcode /Applications/Xcode_14.0.0.app 14.0.0

apparently we are using automake-1.16.5 (like you), but without any problems so far.
the compiler is older (but i somewhat doubt that this is the problem).

Here's how imageIO is built:

Making check in imageIO
/bin/sh ../../libtool    --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src/Gem  -I../../src    -fobjc-arc -DPD -I/Applications/Pd-0.54-1.app/Contents/Resources/src -arch x86_64 -arch arm64   -g -O2 -c -o gem_imageIO_la-imageIO.lo `test -f 'imageIO.mm' || echo './'`imageIO.mm
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src/Gem -I../../src -fobjc-arc -DPD -I/Applications/Pd-0.54-1.app/Contents/Resources/src -arch x86_64 -arch arm64 -g -O2 -c imageIO.mm  -fno-common -DPIC -o .libs/gem_imageIO_la-imageIO.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src/Gem -I../../src -fobjc-arc -DPD -I/Applications/Pd-0.54-1.app/Contents/Resources/src -arch x86_64 -arch arm64 -g -O2 -c imageIO.mm -o gem_imageIO_la-imageIO.o >/dev/null 2>&1
/bin/sh ../../libtool    --mode=link g++  -fobjc-arc -DPD -I/Applications/Pd-0.54-1.app/Contents/Resources/src -arch x86_64 -arch arm64   -g -O2 -module -avoid-version -shared -arch x86_64 -arch arm64 -L/Applications/Pd-0.54-1.app/Contents/Resources/bin -arch x86_64 -arch arm64  -o gem_imageIO.la -rpath /usr/local/lib/pd/extra/Gem gem_imageIO_la-imageIO.lo -L../.. -framework ImageIO -ldl -lz -lm 
libtool: link: g++ -Wl,-undefined -Wl,dynamic_lookup -o .libs/gem_imageIO.so -bundle  .libs/gem_imageIO_la-imageIO.o   -lstdc++ -L/Applications/Pd-0.54-1.app/Contents/Resources/bin -L../.. -framework ImageIO -ldl -lz -lm  -arch x86_64 -arch arm64 -g -O2 -arch x86_64 -arch arm64 -arch x86_64 -arch arm64   -framework ImageIO
libtool: link: ( cd ".libs" && rm -f "gem_imageIO.la" && ln -s "../gem_imageIO.la" "gem_imageIO.la" )
gem_imageIO.so: creating convenience link from /Users/admin/builds/pd/Gem/plugins/imageIO/.libs to ../..

Could you post the output (and input) of your configure invocation (preferably without recursive calls to sub-configures; that is, using --no-recursion)?

@umlaeute
Copy link
Owner

umlaeute commented Jun 19, 2024

another test, this time on my Sonoma VM:

tool path version
macOS - 14.5 (23F79)
autoreconf /opt/homebrew/bin/autoreconf 2.72
aclocal /opt/homebrew/bin/aclocal 1.16.5
glibtoolize /opt/homebrew/bin/glibtoolize 2.4.7
autoconf /opt/homebrew/bin/autoconf 2.72
autoheader /opt/homebrew/bin/autoheader 2.72
automake /opt/homebrew/bin/automake 1.16.5
compiler /usr/bin/g++ 15.0.0 (clang-1500.3.9.4) arm64-apple-darwin23.5.0
Xcode /Applications/Xcode_15.4.app 15.4

again, the build succeeds:

Making check in imageIO
/bin/sh ../../libtool    --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src/Gem  -I../../src    -fobjc-arc -DPD -I/Applications/Pd-0.54-1.app/Contents/Resources/src -arch x86_64 -arch arm64   -g -O2 -c -o gem_imageIO_la-imageIO.lo `test -f 'imageIO.mm' || echo './'`imageIO.mm
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src/Gem -I../../src -fobjc-arc -DPD -I/Applications/Pd-0.54-1.app/Contents/Resources/src -arch x86_64 -arch arm64 -g -O2 -c imageIO.mm  -fno-common -DPIC -o .libs/gem_imageIO_la-imageIO.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src/Gem -I../../src -fobjc-arc -DPD -I/Applications/Pd-0.54-1.app/Contents/Resources/src -arch x86_64 -arch arm64 -g -O2 -c imageIO.mm -o gem_imageIO_la-imageIO.o >/dev/null 2>&1
/bin/sh ../../libtool    --mode=link g++  -fobjc-arc -DPD -I/Applications/Pd-0.54-1.app/Contents/Resources/src -arch x86_64 -arch arm64   -g -O2 -module -avoid-version -shared -arch x86_64 -arch arm64 -L/Applications/Pd-0.54-1.app/Contents/Resources/bin -arch x86_64 -arch arm64  -o gem_imageIO.la -rpath /usr/local/lib/pd/extra/Gem gem_imageIO_la-imageIO.lo -L../.. -framework ImageIO -ldl -lz -lm 
libtool: link: g++ -Wl,-undefined -Wl,dynamic_lookup -o .libs/gem_imageIO.so -bundle  .libs/gem_imageIO_la-imageIO.o   -lstdc++ -L/Applications/Pd-0.54-1.app/Contents/Resources/bin -L../.. -framework ImageIO -ldl -lz -lm  -arch x86_64 -arch arm64 -g -O2 -arch x86_64 -arch arm64 -arch x86_64 -arch arm64   -framework ImageIO
ld: warning: ignoring duplicate libraries: '-lc++'
ld: warning: ignoring duplicate libraries: '-lc++'
libtool: link: ( cd ".libs" && rm -f "gem_imageIO.la" && ln -s "../gem_imageIO.la" "gem_imageIO.la" )
gem_imageIO.so: creating convenience link from /Users/admin/builds/pd/Gem/plugins/imageIO/.libs to ../..

@agraef
Copy link
Author

agraef commented Jun 19, 2024

Ok, over here I have autoreconf/autoconf/autoheader 2.72 and clang version 15.0.0 from Xcode 15.2, so there are some discrepancies to your setups. Attached is the output from ./configure --no-recursion --with-pd=/Applications/Pd-0.53-1.app/Contents/Resources/src. (This is after a fresh checkout and running autogen.sh.)
configure.log

@agraef
Copy link
Author

agraef commented Jun 19, 2024

I don't see anything suspicious in there. The config.log also looks fine -- g++ a.k.a. clang is properly recognized as capable of compiling Objective C++ source. And, as your logs indicate, the --tag option shouldn't be needed there.

Maybe I just have an unlucky Xcode/autotools combination? But I'm also building Gem as a submodule of Purr Data on GH using the macos-12 runner, and it fails with exactly the same error.

Ok, I should maybe try to update my MB to Sonoma and see whether that helps. If you have any idea what's going on there, that would be much appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants