Module linkage fixes for shared build #4169
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following on from #4153:
constexpr
, this was indeed a Clang bug, and anything already markedconstexpr
should be a non-issue; the problem has been fixed on Clang trunk with potential for it to be backported to the 19.x release.#include
withimport
were also being caused by a related Clang bug, also now fixed on trunk.fmt
module via a shared library build, due to the last bullet point in the linked issue.This PR addresses those remaining issues by adding
FMT_INLINE
/FMT_CONSTEXPR
to some member functions defined within the class definition. However, due to the nature of linker issues, problematic cases are only being picked up where a symbol is actually being used from an external dll/exe. Currently, the coverage for that is limited -fmt
's own CI is not yet running modules builds I think (or anyway not withFMT_SHARED
); thebuild2
fmt
package CI also cannot stress test this as the very latest Clang is not available. Furthermore, I've so far only enabled a subset of the tests in thebuild2
package.Fundamentally, I think this addition of
inline
orconstexpr
is essentially needed on every single in-class defined member function which is intended for public use (or alternativelyFMT_API
on the member/class), which is probably a lot more than what I've addressed in these commits and would be quite intrusive. So of course feel free to merge if you like, but it's possible some more thought is warranted in regards toexport
ed from the module, but forexport
, doing things in bulk is possible and less intrusive in terms of code changes)inline
vsFMT_API