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

__cxa_init_primary_exception return type differs from libsupc++ #121300

Open
danakj opened this issue Dec 29, 2024 · 2 comments
Open

__cxa_init_primary_exception return type differs from libsupc++ #121300

danakj opened this issue Dec 29, 2024 · 2 comments
Labels
libc++abi libc++abi C++ Runtime Library. Not libc++.

Comments

@danakj
Copy link
Contributor

danakj commented Dec 29, 2024

As of LLVM 18, there is a build error due to a conflict in the signature of __cxa_init_primary_exception in libc++abi and in gcc's libsupc++ library. The error is on a function introduced in #65534.

This is the compiler error I get on Ubuntu 24 after installing all the LLVM packages from https://apt.llvm.org/llvm.sh

/usr/lib/llvm-18/include/cxxabi.h:51:1: error: functions that differ only in their return type cannot be overloaded
   50 | extern _LIBCXXABI_FUNC_VIS __cxa_exception*
      |                            ~~~~~~~~~~~~~~~~
   51 | __cxa_init_primary_exception(void* object, std::type_info* tinfo, void(_LIBCXXABI_DTOR_FUNC* dest)(void*)) throw();
      | ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/bits/cxxabi_init_exception.h:70:7: note: previous declaration is here
   69 |       __cxa_refcounted_exception*
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~
   70 |       __cxa_init_primary_exception(void *__object, std::type_info *__tinfo,
      |       ^
1 error generated.

Somehow I seem to be almost the first person to run into this on the internet, but one other case of the error was discussed here: iovisor/bcc#5092

The return type in GCC is __cxxabiv1::__cxa_refcounted_exception*: https://github.com/gcc-mirror/gcc/blob/0b06abe027a78681d29a5e91daa74bf8dba39826/libstdc%2B%2B-v3/libsupc%2B%2B/cxxabi_init_exception.h#L71-L74

The return type in libc++abi is __cxxabiv1:: __cxa_exception*: https://github.com/llvm/llvm-project/pull/65534/files#diff-58be87d6aa8658f15e1c1f3fa40acb71d078896d857cf98033b32f9fa294c320R36

When both headers end up being included, which can happen through googletest, they conflict and produce the error above.

@danakj danakj added the libc++abi libc++abi C++ Runtime Library. Not libc++. label Dec 29, 2024
@danakj
Copy link
Contributor Author

danakj commented Dec 29, 2024

@itrofimow What do you think? Should the return type's name match? Is this somehow a pathological build situation that is invalid?

danakj added a commit to danakj/subspace that referenced this issue Dec 29, 2024
…tently

The system headers end up included regardless. But if the libc++abi
headers are there too, they conflict as they have a different signature
for the __cxa_init_primary_exception function.

See also: llvm/llvm-project#121300
danakj added a commit to danakj/subspace that referenced this issue Dec 29, 2024
…tently

The system headers end up included regardless. But if the libc++abi
headers are there too, they conflict as they have a different signature
for the __cxa_init_primary_exception function.

See also: llvm/llvm-project#121300
@philnik777
Copy link
Contributor

Since libc++abi and libsupc++ can't be used at the same time this seems like a configuration issue on your end. You should use the headers of the ABI library that you're actually using. I don't know which one that is though.

danakj added a commit to chromium/subspace that referenced this issue Dec 29, 2024
…tently

The system headers end up included regardless. But if the libc++abi
headers are there too, they conflict as they have a different signature
for the __cxa_init_primary_exception function.

See also: llvm/llvm-project#121300
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libc++abi libc++abi C++ Runtime Library. Not libc++.
Projects
None yet
Development

No branches or pull requests

3 participants