Opened 8 years ago

Closed 4 years ago

#50481 closed defect (fixed)

qt4-mac: libc++ under Lion

Reported by: ctreleaven (Craig Treleaven) Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: Cc: mojca (Mojca Miklavec)
Port: qt4-mac

Description

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?

Attachments (2)

2016Jan29 qt4-mac libc++ build fail main.log (23.1 MB) - added by ctreleaven (Craig Treleaven) 8 years ago.
2016Feb02 qt4-mac cxx11 build fail main.log (463.7 KB) - added by ctreleaven (Craig Treleaven) 8 years ago.

Change History (21)

Changed 8 years ago by ctreleaven (Craig Treleaven)

comment:1 Changed 8 years ago by 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.

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by 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.

Last edited 8 years ago by michaelld (Michael Dickens) (previous) (diff)

comment:4 Changed 8 years ago by 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?

Changed 8 years ago by ctreleaven (Craig Treleaven)

comment:5 Changed 8 years ago by 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.

comment:6 Changed 8 years ago by 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.

comment:7 Changed 8 years ago by 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!).

comment:8 Changed 8 years ago by 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

comment:9 Changed 7 years ago by 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
        }
    }
    
    
  1. 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.

comment:10 Changed 7 years ago by 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..

comment:11 Changed 7 years ago by 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.

comment:12 Changed 7 years ago by 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.

Last edited 5 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:13 Changed 5 years ago by 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.

comment:14 Changed 5 years ago by mojca (Mojca Miklavec)

Cc: mojca added

comment:15 Changed 5 years ago by 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.

comment:16 Changed 5 years ago by 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.

comment:17 Changed 5 years ago by 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!

comment:18 Changed 5 years ago by kencu (Ken)

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

comment:19 Changed 4 years ago by kencu (Ken)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.