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

clang 15 changed symbol mangling and might produce backwards incompatible binaries #213

Open
isuruf opened this issue Apr 27, 2023 · 7 comments

Comments

@isuruf
Copy link
Member

isuruf commented Apr 27, 2023

See https://releases.llvm.org/15.0.0/tools/clang/docs/ReleaseNotes.html#id5

Fixed mangling of nested dependent names such as T::a::b, where T is a template parameter, to conform to the Itanium C++ ABI and be compatible with GCC. This breaks binary compatibility with code compiled with earlier versions of clang; use the -fclang-abi-compat=14 option to get the old mangling.

Mangled symbol changed from

__ZN6FFPACK8CharPolyIN6Givaro8Poly1DomINS1_7ModularIddvEENS1_5DenseEEEEERNT_7ElementERKS7_S9_mNS7_8Domain_t11Element_ptrEmRNS7_8Domain_t8RandIterENS_19FFPACK_CHARPOLY_TAGEm

to

__ZN6FFPACK8CharPolyIN6Givaro8Poly1DomINS1_7ModularIddvEENS1_5DenseEEEEERNT_7ElementERKS7_S9_mNS7_8Domain_t11Element_ptrEmRNSC_8RandIterENS_19FFPACK_CHARPOLY_TAGEm
@h-vetinari
Copy link
Member

How big is the blast radius here? Do you want to use the compat ABI? Do we need a full-blown compiler migration just to get everything onto the new mangling?

@isuruf
Copy link
Member Author

isuruf commented May 2, 2023

It's only one feedstock for now. Not sure how widespread it will be.

@h-vetinari
Copy link
Member

Given that this issues doesn't seem to have a wide blast radius, shouldn't we simply recompile givaro and its dependents with LLVM 15?

@isuruf
Copy link
Member Author

isuruf commented Jul 11, 2023

That will break old downstream packages depending on older ABI.

@h-vetinari
Copy link
Member

That's what I meant with rebuilding its dependent packages (like a migration). Or do you mean consumers outside of conda-forge?

I don't think we should just keep blocking things like conda-forge/compilers-feedstock#57 (or the next clang upgrade) indefinitely. The options I can imagine are:

  • we "migrate" givaro to the new ABI
  • do a full rebuild (with corresponding metadata) of conda-forge for the new ABI
  • do nothing, but keep givaro on clang-abi-compat=14 (until that option ceases to work)

Maybe I'm overlooking something?

@isuruf
Copy link
Member Author

isuruf commented Jul 11, 2023

I sent PRs to keep givaro and its dependencies (through pkg-config file) with clang-abi-compat=14 after I opened this issue.

@h-vetinari
Copy link
Member

h-vetinari commented Jul 12, 2023

Yes, I saw, which is why I said "keep givaro on...". Is this your preferred long-term solution? Does it remove your hold on conda-forge/compilers-feedstock#57?

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

2 participants