-
Notifications
You must be signed in to change notification settings - Fork 12.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
[clang-repl] Fix BUILD_SHARED_LIBS symbols from libclangInterpreter on MinGW #71393
Conversation
…n MinGW A few symbols within libclangInterpreter have got explicit dllexport attributes, in order to make them exported (and thus visible at runtime) in any build, not only when they are part of e.g. a DLL libclang-cpp, but also when they are part of a plain .exe. Due to the explicit dllexports, these symbols would sidestep the regular MinGW logic of exporting all symbols if there are no dllexports. Therefore, for libclang-cpp, a separate fix was made in 592e935, to pass --export-all-symbols to the build of libclang-cpp. If building with BUILD_SHARED_LIBS enabled, then the same issue appears in libclangInterpreter; pass the same flag --export-all-symbols there as well, to make sure all symbols are visible, not only the ones that are explicitly marked as dllexport.
@llvm/pr-subscribers-platform-windows @llvm/pr-subscribers-clang Author: Martin Storsjö (mstorsjo) ChangesA few symbols within libclangInterpreter have got explicit dllexport attributes, in order to make them exported (and thus visible at runtime) in any build, not only when they are part of e.g. a DLL libclang-cpp, but also when they are part of a plain .exe. Due to the explicit dllexports, these symbols would sidestep the regular MinGW logic of exporting all symbols if there are no dllexports. Therefore, for libclang-cpp, a separate fix was made in 592e935, to pass --export-all-symbols to the build of libclang-cpp. If building with BUILD_SHARED_LIBS enabled, then the same issue appears in libclangInterpreter; pass the same flag --export-all-symbols there as well, to make sure all symbols are visible, not only the ones that are explicitly marked as dllexport. Full diff: https://github.com/llvm/llvm-project/pull/71393.diff 1 Files Affected:
diff --git a/clang/lib/Interpreter/CMakeLists.txt b/clang/lib/Interpreter/CMakeLists.txt
index 84f6ca5271d2ab0..9065f998f73c473 100644
--- a/clang/lib/Interpreter/CMakeLists.txt
+++ b/clang/lib/Interpreter/CMakeLists.txt
@@ -38,3 +38,14 @@ add_clang_library(clangInterpreter
clangSema
clangSerialization
)
+
+if ((MINGW OR CYGWIN) AND BUILD_SHARED_LIBS)
+ # The DLLs are supposed to export all symbols (except for ones that are
+ # explicitly hidden). Normally, this is what happens anyway, but if there
+ # are symbols that are marked explicitly as dllexport, we'd only export them
+ # and nothing else. The Interpreter contains a few cases of such dllexports
+ # (for symbols that need to be exported even from standalone exe files);
+ # therefore, add --export-all-symbols to make sure we export all symbols
+ # despite potential dllexports.
+ target_link_options(clangInterpreter PRIVATE LINKER:--export-all-symbols)
+endif()
|
CC @brechtsanders, this is an alternative to #66881. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix! I'm fine with it if this fixes your problem. But yeah, please make sure @vgvassilev is aware of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, @mstorsjo!
…n MinGW (#71393) A few symbols within libclangInterpreter have got explicit dllexport attributes, in order to make them exported (and thus visible at runtime) in any build, not only when they are part of e.g. a DLL libclang-cpp, but also when they are part of a plain .exe. Due to the explicit dllexports, these symbols would sidestep the regular MinGW logic of exporting all symbols if there are no dllexports. Therefore, for libclang-cpp, a separate fix was made in 592e935, to pass --export-all-symbols to the build of libclang-cpp. If building with BUILD_SHARED_LIBS enabled, then the same issue appears in libclangInterpreter; pass the same flag --export-all-symbols there as well, to make sure all symbols are visible, not only the ones that are explicitly marked as dllexport. (cherry picked from commit 0d3eeac)
A few symbols within libclangInterpreter have got explicit dllexport attributes, in order to make them exported (and thus visible at runtime) in any build, not only when they are part of e.g. a DLL libclang-cpp, but also when they are part of a plain .exe.
Due to the explicit dllexports, these symbols would sidestep the regular MinGW logic of exporting all symbols if there are no dllexports. Therefore, for libclang-cpp, a separate fix was made in 592e935, to pass --export-all-symbols to the build of libclang-cpp.
If building with BUILD_SHARED_LIBS enabled, then the same issue appears in libclangInterpreter; pass the same flag --export-all-symbols there as well, to make sure all symbols are visible, not only the ones that are explicitly marked as dllexport.