Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fail to build wich cxxstd=20 on Clang #224

Open
sdebionne opened this issue Mar 9, 2024 · 6 comments
Open

Fail to build wich cxxstd=20 on Clang #224

sdebionne opened this issue Mar 9, 2024 · 6 comments

Comments

@sdebionne
Copy link

We are having trouble building Boost.Locale for Conda forge (see conda-forge/boost-feedstock#194) with cxxstd=20 which is required for the Cobalt library, on osx (clang 16).

I am not familiar with Locale, is there any macro that we should set to prevent the following issue:

Undefined symbols for architecture x86_64:
  "typeinfo for char8_t", referenced from:
      std::__1::basic_string<char8_t, std::__1::char_traits<char8_t>, std::__1::allocator<char8_t> > boost::locale::ios_info::string_set::get<char8_t>() const in formatter.o
ld: symbol(s) not found for architecture x86_64
clang-16: error: linker command failed with exit code 1 (use -v to see invocation)
@Flamefire
Copy link
Collaborator

That is a known issue with Clang. Which version of clang and Boost are you using? In Boost 1.84 a workaround is implemented:

// No std::basic_string<char8_t> or bug in Clang: https://github.com/llvm/llvm-project/issues/55560

In Clang 15 this should be fixed.

@sdebionne
Copy link
Author

Thanks for the quick answer. We build Boost1.84 with Clang 16 on MacOs 10.9. I am not sure if the clang version on MacOs matches the LLVM's once though.

@Flamefire
Copy link
Collaborator

They should match the LLVM 15.x version for a while already. So I'm not sure how to fix this from Boosts side. I'd say it should be fine to define BOOST_LOCALE_NO_CXX20_STRING8 on your side for this. If you have any information when/where this issue is fixed on MacOS and how to improve the condition to detect that I'd be grateful. Otherwise I'll just disable u8string support for MacOS completely.

@h-vetinari
Copy link

We're on clang 16 in conda-forge (though we could use clang 17 and soon 18 if we want; however libcxx is stuck at 16 pending some infrastructure work). The macOS deployment target in the PR mentioned by @sdebionne was already bumped to 10.13, and if there's a hard requirement to go higher, we can do that.

W.r.t.

// No std::basic_string<char8_t> or bug in Clang: https://github.com/llvm/llvm-project/issues/55560

I don't see how that issue is still relevant; it was fixed as of LLVM 15, and we're past that.

@h-vetinari
Copy link

I am not sure if the clang version on MacOs matches the LLVM's once though.

There's only the clang we provide ourselves, we never use the system(==image) compilers in conda-forge.

@Flamefire
Copy link
Collaborator

I don't see how that issue is still relevant; it was fixed as of LLVM 15, and we're past that.

Looks I misinterpreted the error message which also started with "Undefined symbols" and seemingly related to std::basic_string<char8_t> and I missed the important part in all those templates: "typeinfo for char8_t" is what is missing.

And indeed I've seen that before popping up with libc++ on FreeBSD. I fixed that for the upcoming release. You can use that or apply c5e8f02 as a patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants