-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Reconsider forcibly exporting format_error
symbol on GCC
#3626
Comments
We can't use |
Could you elaborate on that a little? From what I understand, the usage of Am I correct in my understanding that if we're using fmt header-only, then |
I don't remember the details of windows issues from the top of my head and it's irrelevant anyway because you need not to export something on windows but avoid changing symbol visibility on POSIX. And this should be achieved by means of changing the definition of |
So I think the correct solution is to define |
The fix in #3627 looks good to me. I'd be interested, just to plug a gap in my own knowledge, if anyone can explain why this special case for |
As commented on the PR we don't need a special case there and should change |
In e0fc0e8 the export attribute macro for the
format_error
exception informat.h
was switched from the conditionalFMT_API
to the unconditionalFMT_VISIBILITY("default")
This causes an ODR violation when fmt is bundled in a (shared) library, intended as a private internal dependency, but consumers of the library are using their own copy of fmt too.
Kinda tricky to show in a Compiler Explorer example. A useful
nm
command-line to check exported symbols in a library:nm --demangle --dynamic --defined-only --extern-only mylibrary.so | grep fmt
After reverting to 9.1.0,
nm
reveals no errant public symbols.The text was updated successfully, but these errors were encountered: