qt4-mac: libc++ under Lion

[ctreleaven (Craig Treleaven)]

I have need to use libc++ on Lion as described in:

​https://trac.macports.org/wiki/LibcxxOnOlderSystems

I tried to build qt4-mac in this environment but it failed with

:info:build ld: warning: directory not found for option '-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/Library/Frameworks'
:info:build ld: warning: directory not found for option '-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/Library/Frameworks'
:info:build Undefined symbols for architecture x86_64:
:info:build   "std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > std::__1::__pad_and_output<char, std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, char const*, char const*, char const*, std::__1::ios_base&, char)", referenced from:
:info:build       std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<< <std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*) in main.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make[2]: *** [../../bin/qmlplugindump] Error 1

I see that the linker args include '-stdlib=libc++'. Main log attached.

Is there a way to successfully build qt4-mac in this environment?

[michaelld (Michael Dickens)]

(1) It's not my fault!

(2) Compress the log file.

(3) 2 thoughts:

(a) The error looks like an issue with libc++ itself, since the unfound symbol was referenced from within libc++. No idea what the issue might be, but it might be worth pinging the maintainer of the libcxx port (jeremyhu).

(b) maybe try +cxx11? I think it still works with qt4-mac.

[ctreleaven (Craig Treleaven)]

1) Is too! ;)

2) sorry

3(a) Will do. (b) the variant description say "does not work with libc++". The commit adding that comment was in 2014 with the 4.8.6 update. Says "fixed in the Qt5 series, but is not simple to backport". I guess I should just try it but I'm away for a few days.

[michaelld (Michael Dickens)]

1) Is not!

2) NP; just don't let me catch you doing it again lol

3.b) Yeah: you'll need to tweak the Portfile to allow you to try that build. I seem to remember it failed for me on 10.9+ using Xcode 7.something. I'll try again locally & see what happens. Probably won't work, but it's worth a try. I'll post on this ticket what I find out.

[ctreleaven (Craig Treleaven)]

I commented out the pre-fetch test in the cxx11 variant but the build immediately failed. Log attached--less than .5 MB, this time--in case you see a quick fix.

Rather than dive headlong down another rabbit hole, I'm going to try having custom prefixes for libc++ and libstdc++. I think that is going to be simpler than fighting with the Qt-4 build system.

PS - I'm pretty much clueless about C++. If I make one prefix '/opt/cxx11' for the libc++ environment, would '/opt/cxx03' or '/opt/cxx98' be appropriate for the libstdc++ environment?

[michaelld (Michael Dickens)]

Mine failed pretty quickly too, but for different reasons. I'm still playing with it, slowly. Here's the issue with yours, putting the various threads together into a single chain:

/opt/local/var/macports/build/_Users_ctreleaven_MacPortsTemp_qt4-mac/qt4-mac/work/qt-everywhere-opensource-src-4.8.7/src/tools/bootstrap
:info:build /usr/bin/clang++ -c -pipe -O2 -std=c++11 -arch x86_64 -Xarch_x86_64 -mmacosx-version-min=10.7 -arch x86_64 -Xarch_x86_64 -mmacosx-version-min=10.7 -Wall -W -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -DQT_BOOTSTRAPPED -DQT_LITE_UNICODE -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_CODECS -DQT_NO_DATASTREAM -DQT_NO_GEOM_VARIANT -DQT_NO_LIBRARY -DQT_NO_QOBJECT -DQT_NO_STL -DQT_NO_SYSTEMLOCALE -DQT_NO_TEXTSTREAM -DQT_NO_THREAD -DQT_NO_UNICODETABLES -DQT_NO_USING_NAMESPACE -DQT_NO_DEPRECATED -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../../mkspecs/macx-g++ -I. -I../../../include -I../../../include/QtCore -I../../../include/QtXml -o .obj/release-shared/qlocale_mac.o ../../corelib/tools/qlocale_mac.mm
:info:build In file included from ../../corelib/tools/qlocale_mac.mm:42:
:info:build In file included from ../../corelib/tools/qlocale_p.h:60:
:info:build In file included from ../../corelib/tools/qlocale.h:45:
:info:build In file included from ../../../include/QtCore/qvariant.h:1:
:info:build In file included from ../../../include/QtCore/../../src/corelib/kernel/qvariant.h:47:
:info:build In file included from ../../../include/QtCore/qlist.h:1:
:info:build ../../../include/QtCore/../../src/corelib/tools/qlist.h:55:10: fatal error: 'initializer_list' file not found
:info:build #include <initializer_list>
:info:build          ^

So, the issue here is that the OBJCXXFLAGS does not contain "-stdlib=libc++". I think this is a bug in qmake. It looks like the Portfile is "doing the right thing", but qmake isn't. Hmmm ...

If you want a quick way around this error, just copy the compile command by hand & add in the missing argument; you'll need to "cd" into the correct directory first, of course.

[ctreleaven (Craig Treleaven)]

Sorry, I'm afraid that looks like a game of 'whack-a-mole'! I think I'm going to go ahead with the idea of different prefixes.

I apologize for raising the issue and then punting on you. I'm trying to get an OS X buildbot working for MythTV. They've just cut a beta and time is of the essence.

[michaelld (Michael Dickens)]

NP; really. Might be whack-a-mole; sometimes that works :) Fixing this might solve my problem too, it just hadn't occurred to me until reviewing yours that it could apply to mine.

Anyway, you asked about naming. If you -always- plan on using cxx11, then I'd name them "/opt/libcxx" and "/opt/libstdcxx". If you want to be broad in scope, then name them "/opt/libcxx_cxx11" and "/opt/libcxx" (for whatever is not c++11); ditto for libstdcxx. In the latter, one can still do "-std=c++11" or not, so you'd want 2 directories for those, if you go that route.

Good luck! Let's keep this ticket around just in case. I'm working on getting a box running 10.4 & 10.5 PPC (32 bit only), and another running 10.5 / 6 / 7 / 8 Intel (for testing libcxx and libstdcxx, per your different install directories & then some specific settings). And then my primary laptop running 10.9 / 10 / 11 (for Intel 32 / 64, libcxx). I'm right now making good progress on 10.5 PPC; got Python up and running with an overnight build. It's a slow beast, but it does work (single core 1.6 GHz PPC G5 iMac). I've got a 10.4 install disk that works, so once I get far enough along with the 10.5 stuff I'll create a new partition & have some fun going way back. i don't see a need to go to 10.3, but I think this mac supports it if I really wanted to. The main issue is that any Xcode prior to about 3.1 does not provide GCC 4.2, and getting it compiled will not be fun. 10.5 supports Xcode 3.1.4 which provides gcc 4.2 by default (yay!).

[kenneth.f.cunningham@…]

You could consider looking here <​https://trac.macports.org/ticket/51844> for a similar issue that was fixed with some minor portfile mods. It may apply to your situation as well. - K

[kencu (Ken)]

qt4-mac installs on Lion upgraded to LibcxxOnOlderSystems if

1. this block is altered to include 10.7 (as well as 10.8 and 10.9). I haven't tried it, but I don't see how this change could hurt the standard Lion installation.

   # (21) Under 10.8 and 10.9: Patch to fix corelib linking
   
   platform darwin {
       #changed from >=8 to >=7
       if {${MINOR} >= 7} {
           patchfiles-append patch-src_corelib_corelib.pro.diff
       }
   }
   
   

2. a newer compiler is used. I used clang-3.7, and that worked as would anything newer, no doubt. Something a little older might work (but why bother)? The Lion default did not work (whatever that is). I have not learned how to translate between Apple clang versions and the office llvm/clang release numbers yet.

[kencu (Ken)]

This install of 10.7 I have here has Xcode 4.6.3, which according to XcodeVersionInfo corresponds to an early clang-3.2, or in apple-speak, Clang 425.0.28.

It looks like clang-3.7 (which works) would be equivalent to any version > 700.

Between 425 and 700 has not been tested by me. Building compilers takes many hours, not to mention how long compiling qt4-mac takes, so I'm not sure I'll ever get to that project. According to the port writer's guide, we don't have to -- we could blacklist clang < 700 as we know that works -- unless someone running 10.8 or 10.9 wants to tell us exactly where the cutoff turns out to be..

[michaelld (Michael Dickens)]

Ken: Can you make a patch that I can apply (easily)? That's the best way to get this change (and, really, any change in place) with the least resistance.

[kencu (Ken)]

I think so. I'm just trying to see if I can figure out exactly what's going on to suggest a good fix ...

I suspect the patch in block #21 above probably should be broadened out to apply to all systems, although the lack of it might only be a deal-breaker at specific times. I'm thinking this is probably going to relieve that weird "-lobjc" bit I had to add in the 10.5 and 10.6 libc++ block fix some months back, and it's clearly needed on 10.7 too.

Then it's just a matter of blacklisting older clangs when building against libc++ -- although it seems older clangs can build qt4-mac against libstdc++, newer clangs appear to be needed for building against libc++ if I'm reading the tea leaves correctly here.

[ryandesign (Ryan Carsten Schmidt)]

Now that libc++ is the default on 10.6-10.8, this will affect pretty much all Lion users. I have not tested Snow Leopard or Mountain Lion but ​here is the log of the build failing on the Lion buildbot worker.

Ken suggested a possible solution above.

[mojca (Mojca Miklavec)]

​10.6 fails with

In file included from nis.cpp:45:
/usr/include/rpcsvc/yp_prot.h:94:22: error: redeclaration of C++ built-in type 'bool'
typedef unsigned int bool;
                     ^
1 error generated.
make: *** [nis.o] Error 1

/opt/local/bin/clang++-mp-8.0 -c -pipe -arch x86_64 -O2 -Wall -W  -I../../../mkspecs/macx-g++ -I. -o clock-gettime.o clock-gettime.cpp
clock-gettime.cpp:51:4: error: "Feature _POSIX_TIMERS not available"
#  error "Feature _POSIX_TIMERS not available"
   ^
clock-gettime.cpp:53:5: error: use of undeclared identifier 'force_compiler_error'
    force_compiler_error = true;
    ^
2 errors generated.

/opt/local/bin/clang++-mp-8.0 -c -pipe -arch x86_64 -O2 -Wall -W  -I../../../mkspecs/macx-g++ -I. -o inotifytest.o inotifytest.cpp
inotifytest.cpp:42:10: fatal error: 'sys/inotify.h' file not found
#include <sys/inotify.h>
         ^~~~~~~~~~~~~~~
1 error generated.
make: *** [inotifytest.o] Error 1

/opt/local/bin/clang++-mp-8.0 -c -pipe -arch x86_64 -O2 -Wall -W  -I../../../mkspecs/macx-g++ -I. -o openvg.o openvg.cpp
openvg.cpp:48:10: fatal error: 'VG/openvg.h' file not found
#include <VG/openvg.h>
         ^~~~~~~~~~~~~
1 error generated.
make: *** [openvg.o] Error 1

Related issue from another package manager: ​https://github.com/spack/spack/issues/4959 but it's not clear to me what exactly fixed the build.

[kencu (Ken)]

You will probably never build qt4-mac with clang-8.0.

I started to explore what it would take to build it with a newer compiler here 57751 and totally gave up -- although there were some efforts out there to be cribbed from, and maybe someone is motivated enough to do it.

clang-5.0 and I believe clang-6.0 built it OK. clang-7.0 and up -- not likely.

[kencu (Ken)]

Well I take that back -- Fred, the genius who is never around here enough for my liking, actually did get it built with clang-8.0 -- with a LOT of patches...I wish we could entice him to stay around more. Would make my life much easier!

[kencu (Ken)]

on lion, it builds w clang-5.0 without other changes.

[kencu (Ken)]

closed by [532963a6177616e80b43856db1390107636fff7f/macports-ports]