boost @1.47.0_0: shouldn't be compiled by clang++ 3.0

[takanori@…]

Seems that The Boost library which is compiled by clang++ 3.0 doesn't work properly.

It causes "Undefined symbols for architecture x86_64" when it was linked from other programs.

I confirmed this problem on Xcode 4.2 GM/Lion.

[takanori@…]

A quick fix.

[takanori@…]

r85206

[titus@…]

Cc Me!

[titus@…]

Is this reported or known upstream?

[adfernandes (Andrew Fernandes)]

I've interacted with the boost ticket system before - I know I sound like a grumpus, but... they won't care. :-(

[titus@…]

Just as a first hint, maybe it's helpful:

(Trying with boost-1.48) I see that using clang the step "Performing configuration checks" is saying

• has_icu builds : no
• icu : no

with gcc it's 2x yes, I'm still unable to figure why that's the case, although I compare the two bin.v2/config.logs.

[adfernandes (Andrew Fernandes)]

Yes, I'm trying 1.48 too. The boost team has fixed some issues, but added new ones. My favorite is "if you want boost-python, use bjam, otherwise phoey on you". Gee, thanks.

The difficulty, I believe, is that clang does not use CPATH etc that GCC uses.

[adfernandes (Andrew Fernandes)]

The latest boost-1.48.0 (which I am committing shortly) should compile fine with clang - it is officially supported.

As usual, the build system is broken for ICU - you need to enable it twice with the an -sICU_PATH argument to the build command. Sigh.

[takanori@…]

This problem flared up again if Boost was upgraded to @1.48.0_1. ;-(

How to reproduce:

$ cd ~/Downloads
$ curl -O http://trac.macports.org/raw-attachment/ticket/31525/sample.cpp
$ clang++ -Wno-parentheses -O3 sample.cpp -o icu_test `pkg-config --libs --cflags icu-i18n` -lboost_regex-mt -lboost_system-mt
Undefined symbols for architecture x86_64:
  "boost::icu_regex_traits::isctype(int, unsigned long long) const", referenced from:
      boost::re_detail::perl_matcher<boost::u8_to_u32_iterator<char const*, int>, std::allocator<boost::sub_match<boost::u8_to_u32_iterator<char const*, int> > >, boost::icu_regex_traits>::find_restart_word() in cc-4xcagz.o
      boost::u8_to_u32_iterator<char const*, int> boost::re_detail::re_is_set_member<boost::u8_to_u32_iterator<char const*, int>, int, boost::icu_regex_traits, unsigned long long>(boost::u8_to_u32_iterator<char const*, int>, boost::u8_to_u32_iterator<char const*, int>, boost::re_detail::re_set_long<unsigned long long> const*, boost::re_detail::regex_data<int, boost::icu_regex_traits> const&, bool) in cc-4xcagz.o
      boost::re_detail::perl_matcher<boost::u8_to_u32_iterator<char const*, int>, std::allocator<boost::sub_match<boost::u8_to_u32_iterator<char const*, int> > >, boost::icu_regex_traits>::match_word_boundary() in cc-4xcagz.o
      boost::re_detail::perl_matcher<boost::u8_to_u32_iterator<char const*, int>, std::allocator<boost::sub_match<boost::u8_to_u32_iterator<char const*, int> > >, boost::icu_regex_traits>::match_within_word() in cc-4xcagz.o
      boost::re_detail::perl_matcher<boost::u8_to_u32_iterator<char const*, int>, std::allocator<boost::sub_match<boost::u8_to_u32_iterator<char const*, int> > >, boost::icu_regex_traits>::match_word_start() in cc-4xcagz.o
      boost::re_detail::perl_matcher<boost::u8_to_u32_iterator<char const*, int>, std::allocator<boost::sub_match<boost::u8_to_u32_iterator<char const*, int> > >, boost::icu_regex_traits>::match_word_end() in cc-4xcagz.o
  "boost::re_detail::icu_regex_traits_implementation::do_transform(int const*, int const*, icu_48::Collator const*) const", referenced from:
      boost::u8_to_u32_iterator<char const*, int> boost::re_detail::re_is_set_member<boost::u8_to_u32_iterator<char const*, int>, int, boost::icu_regex_traits, unsigned long long>(boost::u8_to_u32_iterator<char const*, int>, boost::u8_to_u32_iterator<char const*, int>, boost::re_detail::re_set_long<unsigned long long> const*, boost::re_detail::regex_data<int, boost::icu_regex_traits> const&, bool) in cc-4xcagz.o
  "boost::basic_regex<int, boost::icu_regex_traits>::do_assign(int const*, int const*, unsigned int)", referenced from:
      boost::basic_regex<int, boost::icu_regex_traits>::basic_regex<boost::u8_to_u32_iterator<char const*, int> >(boost::u8_to_u32_iterator<char const*, int>, boost::u8_to_u32_iterator<char const*, int>, unsigned int) in cc-4xcagz.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[adfernandes (Andrew Fernandes)]

Ghaaa - sorry. I was sure that I had tested using your sample.cpp test (thanks for that, BTW!)

Turns out that boost builds just fine with clang.

The problem is in the install stage where boost.build decides to re-build many targets prior to install, but uses slightly different settings. My test had used the built library, not the installed library.

(I think I say this in every trac ticket about boost - boost.build has got to die!)

Anyway - reverted and tested-post-install in r87839.

[Veence (Vincent)]

I just have compiled boost 1.5 with clang and it seems to work fine (it passes the above test). Maybe it is time to try again and, if successful, alter the Portfile accordingly?

[adfernandes (Andrew Fernandes)]

Huh... I just spent $8.75 in electricity recompiling boost, and failed the test with the exact same error reported in the ticket.

Apple's clang 3.1, Mac OS 10.7.4, latest release Xcode.

[Veence (Vincent)]

Uh. Sorry for the bill. Move over here, our electricity is cheap. I’m going to dig into that issue tomorrow. Thanks anyways for trying by yourself. V.

[adfernandes (Andrew Fernandes)]

No, thanks to you for trying. I find it interesting that our two builds produced different results. I also find it interesting that clang-2.8 is a "supported compiler" on linux for boost-1.50.0!

Thanks for looking into this. I did preliminary digging when this ticket was re-opened last time, but didn't figure it out.

Cheers, -Andrew.

[adfernandes (Andrew Fernandes)]

(Out of band email) Vince compiled with clang 4.0 (Xcode 4.5DP2) on 10.8DP4.

Okay - so the problem appears to be specific to Apple's clang pre-4.0.

So... the trick is to rewrite the port to check for clang versions, and use gcc-llvm for pre-clang-4.0...

We'll see for when xcode 4.5 comes out. This sounds messy! :-)

[cooljeanius (Eric Gallager)]

Cc Me!