qt4-mac link error lc++ not found

[kenneth.f.cunningham@…]

MacOSX 10.6.8, is setup using LibcxxOnOlderSystems>

Installing qt4-mac fails with error -lc++ not found. Log attached.

Trying link manually, with verbose setting:

$ pwd
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt4-mac/qt4-mac/work/qt-everywhere-opensource-src-4.8.7/src/tools/moc
$ /opt/local/bin/clang++-mp-3.7 -v -L/opt/local/lib -Wl,-headerpad_max_install_names -stdlib=libc++ -arch x86_64 -Wl,-syslibroot,/Xcode3/SDKs/MacOSX10.6.sdk -Xarch_x86_64 -mmacosx-version-min=10.6 -Xarch_x86_64 -mmacosx-version-min=10.6 -o ../../../bin/moc release-shared/moc.o release-shared/preprocessor.o release-shared/generator.o release-shared/parser.o release-shared/token.o release-shared/main.o    -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt4-mac/qt4-mac/work/qt-everywhere-opensource-src-4.8.7/src/tools/bootstrap -lbootstrap -framework CoreServices -framework ApplicationServices -lz -lz
clang version 3.7.1 (tags/RELEASE_371/final)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
 "/opt/local/libexec/llvm-3.7/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o ../../../bin/moc -lcrt1.10.6.o -L/opt/local/lib -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt4-mac/qt4-mac/work/qt-everywhere-opensource-src-4.8.7/src/tools/bootstrap -headerpad_max_install_names -syslibroot /Xcode3/SDKs/MacOSX10.6.sdk release-shared/moc.o release-shared/preprocessor.o release-shared/generator.o release-shared/parser.o release-shared/token.o release-shared/main.o -lbootstrap -framework CoreServices -framework ApplicationServices -lz -lz -lc++ -lSystem /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.1/lib/darwin/libclang_rt.osx.a
ld: library not found for -lc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)

libc++ is present in /usr/local, and other ports seem to install OK.

$ pwd
/usr/lib
$ ls -la libc*
-rwxr-xr-x  1 root  admin  1186580 12 Jan  2016 libc++.1.dylib
lrwxr-xr-x  1 root  admin       14 12 Jan  2016 libc++.dylib -> libc++.1.dylib
-rwxr-xr-x  1 root  admin   431040 24 Nov  2015 libc++abi.dylib
lrwxr-xr-x  1 root  wheel       15 25 Feb  2015 libc.dylib -> libSystem.dylib

might be related to this ticket but seems different, as "-stdlib=libc++" seems to be present in the command line above.

My macports.conf relevant part:

# $Id: macports.conf.in 117120 2014-02-17 00:55:33Z jmr@macports.org $

cxx_stdlib         libc++
buildfromsource    always
delete_la_files    yes
default_compilers  macports-clang-3.7 macports-clang-3.4 macports-clang-3.3 gcc-4.2 apple-gcc-4.2 gcc-4.0
build_arch         x86_64

Thanks.

[jeremyhu (Jeremy Huddleston Sequoia)]

You're using an SDK (-syslibroot /Xcode3/SDKs/MacOSX10.6.sdk). The libc++ port installs to the system, not the SDK. That's not something we support very well. I suggest you use the system libraries and headers.

[kenneth.f.cunningham@…]

Thanks Jeremy -- immediate insight as always -- indeed, the qt4-mac port file injects a reference to an SDK into configure that messes up the build on this platform.

This can be overridden with "sudo port install qt4-mac configure.sdkroot="/" which then does get past the lc++ errors.

(another error then crops up with a missing libobjc which is a separate issue).

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, then lets reopen this as an issue with qt4-mac if it's not honoring the correct settings and going off and using the SDK on its own.

[kenneth.f.cunningham@…]

Michael -- I think the issue might come down to some kind of a test to see if a user is running an installation with LibcxxOnOlderSystems. If so, the SDK setting in the portfile's logic for this can be adjusted (unset, basically).

There are several other build issues I had to then overcome with Makefile adjustments besides this issue to get qt4-mac to build. List them here, or separate tickets - or email them to you directly?

[kenneth.f.cunningham@…]

OK - I realize now that the qt4-mac portfile is incredibly complicated. I suspect that the underlying issue could be that the mkspec chosen for this platform doesn't take into account the libc++ modification done to 10.6.8. It chooses macx-g++ as the mkspec, and (deference here to someone who knows better) might better be choosing macx-clang-libc++.

To compile it as it is, I did

"sudo port install qt4-mac configure.sdkroot="/"

to get started, then manually altered a couple of Makefiles to correct errors

in src/corelib/Makefile

add -lobjc to
LFLAGS        = -L/opt/local/lib -lobjc -Wl,-headerpad_max_install_names -stdlib=libc++ -Wl,-syslibroot,/ -arch x86_64 -Wl,-syslibroot,/ -single_module -dynamiclib -compatibility_version	4.8 -current_version	4.8.7 -install_name	/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore -Xarch_x86_64 -mmacosx-version-min=10.6 -Xarch_x86_64 -mmacosx-version-min=10.6

and

in src/plugins/bearer/corewlan/Makefile

add -framework Security 
LIBS          = $(SUBLIBS) -F/System/Library/Frameworks -F/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt4-mac/qt4-mac/work/qt-everywhere-opensource-src-4.8.7/lib  -framework Foundation -framework SystemConfiguration -framework CoreWLAN -F/Library/Frameworks -F/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt4-mac/qt4-mac/work/qt-everywhere-opensource-src-4.8.7/lib -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_qt4-mac/qt4-mac/work/qt-everywhere-opensource-src-4.8.7/lib -framework QtNetwork -framework QtCore -framework Security

I believe that was all that was needed.

[jeremyhu (Jeremy Huddleston Sequoia)]

Is there a particular reason you are trying to install qt4? It was last touched about 5 years ago. Most clients moved on to qt5 years ago.

[kenneth.f.cunningham@…]

It's a requirement of the most recent version of OpenSCAD, which apparently hasn't yet been brought up to QT5.

[kenneth.f.cunningham@…]

Jeremy and Michael -- here's a diff file for the qt4-mac Portfile that successfully builds on snowleopard with libcxx installed. I made it specific for snowleopard - but it's possible that 10.7 and 10.8 with libc++ enabled might need to use it as well.

[kenneth.f.cunningham@…]

Fix to build qt4-mac on snowleopard with libcxx installed

[jeremyhu (Jeremy Huddleston Sequoia)]

This would be an issue on Leopard as well, so don't restrict it to Snow Leopard.

The second hunk is ... odd...

However given the age of this port and its lack of upstream support, I'm ok with just getting this in as is (modulo whitespace and Leopard support).

[ken-cunningham-webuse]

Thanks, Jeremy. Revised patch finished -- just retesting a build on SL to make sure it still works cleanly. I'm sure it will. I don't have a leopard machine set up with LibCxxOnOlderSystems to verify that configuration, however.

For interest, I'll also attach a log from a failed build without adding in the -lobjc link, and then another adding -lobjc but without adding -framework Security, so you can see what happens when you don't add in those libraries, if you're curious. The library selection logic breaks down somewhere in there, and these links fix it, but don't explain where the breakdown is.

[ken-cunningham-webuse]

log from a failed build without adding in the -lobjc link

[jeremyhu (Jeremy Huddleston Sequoia)]

Thanks. Please add a comment once you're attached the revised patch because trac doesn't send email on attachments.

[ken-cunningham-webuse]

New, improved tighter patch uploaded. Two hunks combined into one carefully-positioned block. To my moderate surprise adding -framework Security is not presently necessary to complete the build after all. Build test cycles are long with this one, but all attempted build variations on two LibCxxOnOlderSystems machines succeed without it now -- my previous trouble with corewlan module failing to build are not reproduced. So patch is also simplified in a satisfying way.

[ken-cunningham-webuse]

revised qt4-mac patch

[michaelld (Michael Dickens)]

That patch looks fine to me. If you say it works, then I'll believe you ;)

I wonder if there's a way to test whether the libc++ForOlderSystems is installed?

I'm working on the patch for qt4-mac for 10.12, so I'll integrate this patch at the same time.

[ken-cunningham-webuse]

Thanks. Trying hard not to break anything! This patch works for me on several machines.

the best test for Libc++OnOlderSystems we could come up with on the mailing list was to test the macports.conf setting below in Darwin 9 and 10.

if {${configure.cxx_stdlib} eq "libc++"}

We might have instead done a file test for libc++, but that doesn't mean the user is actually using it...ergo this approach.

On Darwin 11 and 12, the SDKs have libc++ in them, so they would work even with the normal qt4 configure logic. This block won't affect them.

(An alternative approach might have been to copy the libc++ and libc++abi stuff into the 10.5 and 10.6 SDKs, but this goes severely against the rules.)

[michaelld (Michael Dickens)]

committed in r153015.