E5ten added a comment.
I am in favour of adding a user-facing option to disable generating this
duplicate library for users that don't need it, like @jvesely says, there
should be an option to disable linking a library that takes a long time to link
and isn't necessary for a lot of users.
E5ten added a comment.
@beanz But if libclang_shared is intended to be a shippable binary and
BUILD_SHARED_LIBS is only intended to be an option used in developer builds,
and libclang_shared while not causing conflicts (thanks for the info on how
that works by the way) would be redundant in a
E5ten added a comment.
@beanz Well I took libclang_shared as effectively an equivalent to the
libLLVM.so that's created with that dylib option, and when BUILD_SHARED_LIBS is
enabled that library is not created, in fact the option to create that library
conflicts with BUILD_SHARED_LIBS. Also
E5ten added a comment.
@beanz Wouldn't fixing this by adding OR BUILD_SHARED_LIBS to if(ARG_SHARED) in
AddClang.cmake and to if (NOT LLVM_ENABLE_PIC) in clang-shlib/CMakeLists.txt to
prevent making libclang_shared when BUILD_SHARED_LIBS is enabled make more
sense?
Repository:
rC Clang
E5ten added a comment.
I might be doing something wrong but this seems to have broken
BUILD_SHARED_LIBS for me in that even with that enabled clang is built as a
bunch of static libraries linked into a shared one like this patch is supposed
to make it do, while I thought that BUILD_SHARED_LIBS
E5ten added inline comments.
Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:563
+ crtend = Args.hasArg(options::OPT_shared) || IsPIE || IsStaticPIE ?
+ "crtend_shared" : "crtend";
+ CmdArgs.push_back(ToolChain.getCompilerRTArgString(
