Opened 12 years ago

Closed 12 years ago

Last modified 10 years ago

#31525 closed defect (fixed)

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

Reported by: takanori@… Owned by: adfernandes (Andrew Fernandes)
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: Cc: titus@…, cooljeanius (Eric Gallager)
Port: boost

Description

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.

Attachments (4)

sample.cpp (423 bytes) - added by takanori@… 12 years ago.
log_sample.cpp_before.txt (7.4 KB) - added by takanori@… 12 years ago.
boost.diff (615 bytes) - added by takanori@… 12 years ago.
A quick fix.
log_sample.cpp_after.txt (2.8 KB) - added by takanori@… 12 years ago.

Download all attachments as: .zip

Change History (19)

Changed 12 years ago by takanori@…

Attachment: sample.cpp added

Changed 12 years ago by takanori@…

Attachment: log_sample.cpp_before.txt added

Changed 12 years ago by takanori@…

Attachment: boost.diff added

A quick fix.

Changed 12 years ago by takanori@…

Attachment: log_sample.cpp_after.txt added

comment:1 Changed 12 years ago by takanori@…

Resolution: fixed
Status: newclosed

comment:2 Changed 12 years ago by titus@…

Cc: titus@… added

Cc Me!

comment:3 Changed 12 years ago by titus@…

Is this reported or known upstream?

comment:4 Changed 12 years ago by adfernandes (Andrew Fernandes)

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

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

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

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

comment:8 Changed 12 years ago by takanori@…

Resolution: fixed
Status: closedreopened

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)

comment:9 Changed 12 years ago by adfernandes (Andrew Fernandes)

Resolution: fixed
Status: reopenedclosed

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.

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

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

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

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

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

comment:15 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

Note: See TracTickets for help on using tickets.