Opened 23 months ago

Last modified 11 months ago

#50481 new defect

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:
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) 23 months ago.
2016Feb02 qt4-mac cxx11 build fail main.log (463.7 KB) - added by ctreleaven (Craig Treleaven) 23 months ago.

Change History (14)

Changed 23 months ago by ctreleaven (Craig Treleaven)

comment:1 Changed 23 months 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 23 months 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 23 months 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 23 months ago by michaelld (Michael Dickens) (previous) (diff)

comment:4 Changed 23 months 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 23 months ago by ctreleaven (Craig Treleaven)

comment:5 Changed 23 months 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 23 months 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 23 months 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 16 months 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 11 months 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 11 months 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 11 months 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 11 months 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.

Note: See TracTickets for help on using tickets.