llvm-project/llvm/tools/llvm-shlib/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

185 lines
7.0 KiB
CMake
Raw Normal View History

# This tool creates a shared library from the LLVM libraries. Generating this
# library is enabled by setting LLVM_BUILD_LLVM_DYLIB=yes on the CMake
# commandline. By default the shared library only exports the LLVM C API.
set(SOURCES
libllvm.cpp
)
if(LLVM_LINK_LLVM_DYLIB AND LLVM_DYLIB_EXPORTED_SYMBOL_FILE)
message(WARNING "Using LLVM_LINK_LLVM_DYLIB with LLVM_DYLIB_EXPORTED_SYMBOL_FILE may not work. Use at your own risk.")
Enable linking tools, shared libraries against libLLVM Summary: Three closely related changes, to have a mode in which we link all executables and shared libraries against libLLVM. 1. Add a new LLVM_LINK_LLVM_DYLIB cmake option, which, when ON, will link executables and shared libraries against libLLVM. For this to work, it is necessary to also set LLVM_BUILD_LLVM_DYLIB and LLVM_DYLIB_EXPORT_ALL. It is not strictly necessary to set LLVM_DISABLE_LLVM_DYLIB_ATEXIT, but we also default to OFF in this mode, or tools tend to misbehave (e.g. stdout may not flush on exit when output is buffered.) llvm-config and Tablegen do not use libLLVM, as they are dependencies of libLLVM. 2. Modify llvm-go to take a new flag, "linkmode=component-libs|dylib". Depending on which one is passed (default is component-libs), we link with the individual libraries or libLLVM respectively. We pass in dylib when LLVM_LINK_LLVM_DYLIB is ON. 3. Fix LLVM_DYLIB_EXPORT_ALL on Linux, and expand the symbols exported to actually export all. Don't strip leading underscore from symbols on Linux, and make sure we get all exported symbols and weak-with-default symbols ("W" in nm output). Without these changes, passes won't load because the "Annotate..." symbols defined in lib/Support/Valigrind.cpp are not found. Testing: - Ran default build ("ninja") with LLVM, clang, compiler-rt, llgo, lldb. - Ran "check", "check-clang", "check-tsan", "check-libgo" targets. I've never had much success with LLDB tests, and llgoi is currently broken so check-llgo fails for an unrelated reason. - Ran "lldb" to ensure it loads. Reviewers: chandlerc, beanz, pcc, rnk Subscribers: rnk, chapuni, sylvestre.ledru, llvm-commits Differential Revision: http://reviews.llvm.org/D12488 llvm-svn: 246527
2015-09-01 11:14:31 +08:00
endif()
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
if(LLVM_BUILD_LLVM_DYLIB)
if(MSVC)
message(FATAL_ERROR "Generating libLLVM is not supported on MSVC")
endif()
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
llvm_map_components_to_libnames(LIB_NAMES ${LLVM_DYLIB_COMPONENTS})
[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries" Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
2019-11-14 13:39:58 +08:00
# Exclude libLLVMTableGen for the following reasons:
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
# - it is only used by internal *-tblgen utilities;
# - it pollutes the global options space.
[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries" Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
2019-11-14 13:39:58 +08:00
list(REMOVE_ITEM LIB_NAMES "LLVMTableGen")
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
if(LLVM_DYLIB_EXPORTED_SYMBOL_FILE)
set(LLVM_EXPORTED_SYMBOL_FILE ${LLVM_DYLIB_EXPORTED_SYMBOL_FILE})
add_custom_target(libLLVMExports DEPENDS ${LLVM_EXPORTED_SYMBOL_FILE})
endif()
if (LLVM_LINK_LLVM_DYLIB)
set(INSTALL_WITH_TOOLCHAIN INSTALL_WITH_TOOLCHAIN)
endif()
add_llvm_library(LLVM SHARED DISABLE_LLVM_LINK_LLVM_DYLIB SONAME ${INSTALL_WITH_TOOLCHAIN} ${SOURCES})
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
list(REMOVE_DUPLICATES LIB_NAMES)
if(("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux") OR (MINGW) OR (HAIKU)
OR ("${CMAKE_SYSTEM_NAME}" STREQUAL "FreeBSD")
OR ("${CMAKE_SYSTEM_NAME}" STREQUAL "GNU")
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
OR ("${CMAKE_SYSTEM_NAME}" STREQUAL "OpenBSD")
OR ("${CMAKE_SYSTEM_NAME}" STREQUAL "Fuchsia")
OR ("${CMAKE_SYSTEM_NAME}" STREQUAL "DragonFly")
OR ("${CMAKE_SYSTEM_NAME}" STREQUAL "SunOS")) # FIXME: It should be "GNU ld for elf"
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/simple_version_script.map.in
${LLVM_LIBRARY_DIR}/tools/llvm-shlib/simple_version_script.map)
# GNU ld doesn't resolve symbols in the version script.
set(LIB_NAMES -Wl,--whole-archive ${LIB_NAMES} -Wl,--no-whole-archive)
if (NOT LLVM_LINKER_IS_SOLARISLD AND NOT MINGW)
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
# Solaris ld does not accept global: *; so there is no way to version *all* global symbols
set(LIB_NAMES -Wl,--version-script,${LLVM_LIBRARY_DIR}/tools/llvm-shlib/simple_version_script.map ${LIB_NAMES})
endif()
elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
set(LIB_NAMES -Wl,-all_load ${LIB_NAMES})
endif()
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
target_link_libraries(LLVM PRIVATE ${LIB_NAMES})
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
if (APPLE)
set_property(TARGET LLVM APPEND_STRING PROPERTY
LINK_FLAGS
" -compatibility_version 1 -current_version ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}")
endif()
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
if(TARGET libLLVMExports)
add_dependencies(LLVM libLLVMExports)
endif()
endif()
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
if(LLVM_BUILD_LLVM_C_DYLIB AND NOT MSVC)
if(NOT APPLE)
message(FATAL_ERROR "Generating libLLVM-c is only supported on Darwin")
endif()
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
if(NOT LLVM_BUILD_LLVM_DYLIB)
message(FATAL_ERROR "Generating libLLVM-c requires LLVM_BUILD_LLVM_C_DYLIB on Darwin")
endif()
# To get the export list for a single llvm library:
# nm ${LIB_PATH} | awk "/T _LLVM/ { print $3 }" | sort -u | sed -e "s/^_//g" > ${LIB_PATH}.exports
set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_BINARY_DIR}/libllvm-c.exports)
set(LIB_DIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
set(LIB_NAME ${LIB_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}LLVM)
set(LIB_PATH ${LIB_NAME}${CMAKE_SHARED_LIBRARY_SUFFIX})
set(LIB_EXPORTS_PATH ${LIB_NAME}.exports)
list(APPEND LLVM_DYLIB_REQUIRED_EXPORTS ${LIB_EXPORTS_PATH})
add_custom_command(OUTPUT ${LLVM_EXPORTED_SYMBOL_FILE}
COMMAND nm ${LIB_PATH} | awk "/T _LLVM/ || /T LLVM/ { print $3 }" | sort -u | sed -e "s/^_//g" > ${LLVM_EXPORTED_SYMBOL_FILE}
WORKING_DIRECTORY ${LIB_DIR}
DEPENDS LLVM
COMMENT "Generating Export list for LLVM..."
VERBATIM )
add_custom_target(libLLVMCExports DEPENDS ${LLVM_EXPORTED_SYMBOL_FILE})
add_llvm_library(LLVM-C SHARED ${SOURCES} INSTALL_WITH_TOOLCHAIN)
2020-05-22 20:33:16 +08:00
target_link_libraries(LLVM-C PUBLIC LLVM)
add_dependencies(LLVM-C libLLVMCExports)
2020-05-22 20:33:16 +08:00
set_property(TARGET LLVM-C APPEND_STRING PROPERTY
LINK_FLAGS
" -compatibility_version 1 -current_version ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH} -Wl,-reexport_library ${LIB_PATH}")
endif()
if(LLVM_BUILD_LLVM_C_DYLIB AND MSVC)
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
# Build the LLVM-C.dll library that exports the C API.
set(LLVM_LINK_COMPONENTS
${LLVM_DYLIB_COMPONENTS}
)
llvm_map_components_to_libnames(LIB_NAMES ${LLVM_DYLIB_COMPONENTS})
list(REMOVE_DUPLICATES LIB_NAMES)
# The python script needs to know whether symbols are prefixed with underscores or not.
if(LLVM_HOST_TRIPLE STREQUAL "i686-pc-win32")
set(GEN_UNDERSCORE "--underscore")
else()
set(GEN_UNDERSCORE "")
endif()
# Set this name here, not used in multi conf loop,
# but add script will pick the right one.
set(LIBSFILE ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/libllvm-c.args)
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
# Get the full name to the libs so the python script understands them.
foreach(lib ${LIB_NAMES})
list(APPEND FULL_LIB_NAMES ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib/${lib}.lib)
endforeach()
2020-05-22 20:33:16 +08:00
# Need to separate lib names with newlines.
string(REPLACE ";" "\n" FILE_CONTENT "${FULL_LIB_NAMES}")
if(NOT "${CMAKE_CFG_INTDIR}" STREQUAL ".")
foreach(BUILD_MODE ${CMAKE_CONFIGURATION_TYPES})
# Replace the special string with a per config directory.
string(REPLACE ${CMAKE_CFG_INTDIR} ${BUILD_MODE} PER_CONF_CONTENT "${FILE_CONTENT}")
# Write out the full lib names into file to be read by the python script.
# One libsfile per build, the add_custom_command should expand
# ${CMAKE_CFG_INTDIR} correctly and select the right one.
file(WRITE ${CMAKE_BINARY_DIR}/${BUILD_MODE}/libllvm-c.args "${PER_CONF_CONTENT}")
endforeach()
else()
# Write out the full lib names into file to be read by the python script.
file(WRITE ${LIBSFILE} "${FILE_CONTENT}")
endif()
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
# Generate the exports file dynamically.
set(GEN_SCRIPT ${CMAKE_CURRENT_SOURCE_DIR}/gen-msvc-exports.py)
set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/libllvm-c.exports)
if(NOT LLVM_NM)
if(CMAKE_CROSSCOMPILING)
build_native_tool(llvm-nm llvm_nm)
set(llvm_nm_target "${llvm_nm}")
else()
set(llvm_nm $<TARGET_FILE:llvm-nm>)
set(llvm_nm_target llvm-nm)
endif()
else()
set(llvm_nm ${LLVM_NM})
set(llvm_nm_target "")
endif()
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
add_custom_command(OUTPUT ${LLVM_EXPORTED_SYMBOL_FILE}
COMMAND "${Python3_EXECUTABLE}" ${GEN_SCRIPT} --libsfile ${LIBSFILE} ${GEN_UNDERSCORE} --nm "${llvm_nm}" -o ${LLVM_EXPORTED_SYMBOL_FILE}
DEPENDS ${LIB_NAMES} ${llvm_nm_target}
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
COMMENT "Generating export list for LLVM-C"
VERBATIM )
# Finally link the target.
add_llvm_library(LLVM-C SHARED INSTALL_WITH_TOOLCHAIN ${SOURCES} DEPENDS intrinsics_gen)
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
[Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc} This patch optionally replaces the CRT allocator (i.e., malloc and free) with rpmalloc (mixed public domain licence/MIT licence) or snmalloc (MIT licence) or mimalloc (MIT licence). Please note that the source code for these allocators must be available outside of LLVM's tree. To enable, use `cmake ... -DLLVM_INTEGRATED_CRT_ALLOC=D:/git/rpmalloc -DLLVM_USE_CRT_RELEASE=MT` where `D:/git/rpmalloc` has already been git clone'd from `https://github.com/mjansson/rpmalloc`. The same applies to snmalloc and mimalloc. When enabled, the allocator will be embeded (statically linked) into the LLVM tools & libraries. This currently only works with the static CRT (/MT), although using the dynamic CRT (/MD) could potentially work as well in the future. When enabled, this changes the memory stack from: new/delete -> MS VC++ CRT malloc/free -> HeapAlloc -> VirtualAlloc to: new/delete -> {rpmalloc|snmalloc|mimalloc} -> VirtualAlloc The goal of this patch is to bypass the application's global heap - which is thread-safe thus inducing locking - and instead take advantage of a modern lock-free, thread cache, allocator. On a 6-core Xeon Skylake we observe a 2.5x decrease in execution time when linking a large scale application with LLD and ThinLTO (12 min 20 sec -> 5 min 34 sec), when all hardware threads are being used (using LLD's flag /opt:lldltojobs=all). On a dual 36-core Xeon Skylake with all hardware threads used, we observe a 24x decrease in execution time (1 h 2 min -> 2 min 38 sec) when linking a large application with LLD and ThinLTO. Clang build times also see a decrease in the range 5-10% depending on the configuration. Differential Revision: https://reviews.llvm.org/D71786
2020-08-27 23:09:20 +08:00
if (LLVM_INTEGRATED_CRT_ALLOC AND MSVC)
# Make sure we search LLVMSupport first, before the CRT libs
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -INCLUDE:malloc")
endif()
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 23:54:50 +08:00
endif()