boost @1.51.0_1+no_single+no_static+universal filesystem tut3.cpp compile fail

[danielmlord@…]

System: OS X 10.7.5 Version 4.5.1 (4G1004)

Error message:

Ld "/Users/daniello/Library/Developer/Xcode/DerivedData/Boost_Filesystem_TEST-brflaiistunrfdfxrfsupcorguru/Build/Products/Debug/Boost Filesystem TEST" normal x86_64
    cd "/Volumes/SDDEXT/Dev-New/Boost/Filesystem/Boost Filesystem TEST"
    setenv MACOSX_DEPLOYMENT_TARGET 10.7
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -L/Users/daniello/Library/Developer/Xcode/DerivedData/Boost_Filesystem_TEST-brflaiistunrfdfxrfsupcorguru/Build/Products/Debug -L/opt/local/lib -F/Users/daniello/Library/Developer/Xcode/DerivedData/Boost_Filesystem_TEST-brflaiistunrfdfxrfsupcorguru/Build/Products/Debug -filelist "/Users/daniello/Library/Developer/Xcode/DerivedData/Boost_Filesystem_TEST-brflaiistunrfdfxrfsupcorguru/Build/Intermediates/Boost Filesystem TEST.build/Debug/Boost Filesystem TEST.build/Objects-normal/x86_64/Boost Filesystem TEST.LinkFileList" -mmacosx-version-min=10.7 -lboost_chrono-mt -lboost_math_c99l-mt -lboost_signals-mt -lboost_context-mt -lboost_math_tr1-mt -lboost_system-mt -lboost_date_time-mt -lboost_math_tr1f-mt -lboost_test_exec_monitor-mt -lboost_exception-mt -lboost_thread-mt -lboost_filesystem-mt -lboost_math_tr1l-mt -lboost_timer-mt -lboost_graph-mt -lboost_prg_exec_monitor-mt -lboost_unit_test_framework-mt -lboost_iostreams-mt -lboost_program_options-mt -lboost_wave-mt -lboost_locale-mt -lboost_random-mt -lboost_wserialization-mt -lboost_math_c99-mt -lboost_regex-mt -lboost_math_c99f-mt -lboost_serialization-mt -stdlib=libc++ -o "/Users/daniello/Library/Developer/Xcode/DerivedData/Boost_Filesystem_TEST-brflaiistunrfdfxrfsupcorguru/Build/Products/Debug/Boost Filesystem TEST"

Undefined symbols for architecture x86_64:
  "boost::filesystem::path_traits::dispatch(boost::filesystem::directory_entry const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, std::__1::codecvt<wchar_t, char, __mbstate_t> const&)", referenced from:
      boost::filesystem::path::path<boost::filesystem::directory_entry>(boost::filesystem::directory_entry const&, boost::enable_if<boost::filesystem::path_traits::is_pathable<boost::decay<boost::filesystem::directory_entry>::type>, void>::type*) in main.o
ld: symbol(s) not found for architecture x86_64

[ryandesign (Ryan Carsten Schmidt)]

Please attach the main.log file.

Remember to use WikiFormatting when writing in Trac in the future.

[adfernandes (Andrew Fernandes)]

Can you please use otool to verify that the boost libs really are universal?

If they are, it is likely an upstream boost error, and there isn't much we can do about that.

Thanks!

[danielmlord@…]

Replying to adfernandes@…:

Can you please use otool to verify that the boost libs really are universal?

If they are, it is likely an upstream boost error, and there isn't much we can do about that.

Thanks!

I was hoping this was a simple fix but I guess not. I guess it's a Boost problem. I've seen Boost have issues with Apple compilers before (and lots of other gcc sources—their priority is not gcc cross platform compatibility. I'll compile natively and see what I can do. If I find anything I'll let the maintainer of the port know. Thanks. Here is the output from the 'file' tool (it wasn't clear how to get this from 'otool' easily from the man page).

libboost_filesystem-mt.a: Mach-O universal binary with 2 architectures libboost_filesystem-mt.a (for architecture i386): current ar archive random library libboost_filesystem-mt.a (for architecture x86_64): current ar archive random library

libboost_filesystem-mt.dylib: Mach-O universal binary with 2 architectures libboost_filesystem-mt.dylib (for architecture i386): Mach-O dynamically linked shared library i386 libboost_filesystem-mt.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

[adfernandes (Andrew Fernandes)]

Hmm... this rings a bell, but I can't seem to find it online.

I remember that boost had some sort of problem building 32-bit executables on 64-bit platforms; I think this might even be an old macports bug report.

I do know that you absolutely, positively cannot mix gcc and clang builds of boost. Completely different compiler options get set. (Basically using different compilers causes different defines to be used, and different linker flags.)

I also do know that only one or two boost releases ago there were problems with building for iOS with clang, especially with regard to visibility. Yes, boost sets visibility of symbols differently depending on the compiler.

When people complain, they just say "use jam to build your project".

In fact, with a private boost build I've been using, I seem to recall that ${SRC}/tools/build/v2/tools/darwin.jam makes -arch compiler flag assumptions (usually incorrectly).

I hope this helps. :-(

[danielmlord@…]

"I hope this helps. :-("

It does—it confirms my suspicions that Apple's compilers and build options are complex. non-standard, and arcane and, to use a pedestrian term, "suck". I am dedicated to the Apple platform for want of a better UNIX (unless M$ ever gives us a better platform without the costs that is more open—i doubt that will ever happen or Google succeeds in their platform which is in doubt so far) so this is my cross to bear for now. But Boost is simply becoming more trouble that it is worth for the few portions I rely on. I think I'll just fork those parts I need, re-factor them, and leave the distro behind. Sad. They are sealing their bid for anonymity but that's their choice. I am still a fan of Macports. Kudos to the team. It's Boost that sucks.

[adfernandes (Andrew Fernandes)]

Actually, Apple's compliers, IMHO, are rather good. The problem is that developers constantly assume that MacOS is Linux and that c++ is g++. Neither are true. They're close, but they aren't the same. Don't forget: there is no such thing as a "standard" build environment. Try building on FreeBSD with source that assumes Linux! And FreeBSD 10 will be built with clang as the default compiler.

I also agree that using boost can be a serious troublemaker for many projects. I now keep a custom build of boost with my sources that need it just to ensure that the same compiler options get used on all objects.

Really, boost should never have headers that disagree with the runtime libraries, or at least throw link-time assertions if the compiled options don't match the header definitions. Saying things like "build systems other than bjam are not supported" is singularly unhelpful.

Oh well.

[danielmlord@…]

Good points for me to consider, though Apple's LLVM see to have had some serious math issues for a while (check out the Chipmunk Physics forum) but that is all I can legitimately be concerned over that might be fixed by now. I tried using c++ from the command line with the same includes and libs (like as in a Makefile) and the tutorial compiles perfectly. THe examples compile fine with bjam though I shun bjam as an arcane one-off tool in general. However, I worry if I change the compiler in Xcode then I'll have Obj-C issues (sometimes you just cannot win). But your argument that it is Boost more than Apple holds merit. I think I'll make a fork of Boost and maintain on my own too. The GPM lib had the similar problems for a long while largely doe to egos on the key developers. Plus ça change, plus c'est la même chose. Thanks for your help and good luck to you with Boost.