[llvm] r198136 - EXPORTED_SYMBOL_FILE support for cmake

[Tom Roeder]

Actually, I guess this qualifies as an 'obvious' fix, so I've submitted the
trivial patch.


On Fri, Jan 10, 2014 at 2:42 PM, Tom Roeder <tmroeder at google.com> wrote:

> This seems to break the cmake/ninja version of LLVMgold.so; the plugin no
> longer links correctly against libLTO.so, so it can't be loaded by ld. We
> need to restore (part of) the last line in tools/gold/CMakeLists.txt, as
> follows:
>
> target_link_libraries(LLVMgold LTO)
>
> at the end of tools/gold/CMakeLists.txt.  I've added that back in locally
> and tested it with cmake/ninja and cmake/make, and it works.
>
> I'll submit a patch to fix this if this looks right.
>
>
>
> On Sat, Dec 28, 2013 at 3:54 PM, Chandler Carruth <chandlerc at google.com>wrote:
>
>>
>> On Sat, Dec 28, 2013 at 6:31 PM, Nico Weber <nicolasweber at gmx.de> wrote:
>>
>>> EXPORTED_SYMBOL_FILE support for cmake
>>>
>>> The cmake build didn't support EXPORTED_SYMBOL_FILE. Instead, it had a
>>> Windows-only implementation in tools/lto/CMakeLists.txt, a linux-only
>>> implementation in tools/gold/CMakeLists.txt, and a darwin-only
>>> implementation
>>> in tools/clang/tools/libclang/CMakeLists.txt.
>>>
>>> This attempts to consolidate these one-offs into a single place. Clients
>>> can now
>>> just set LLVM_EXPORTED_SYMBOL_FILE and things (hopefully) Just Work,
>>> like in
>>> the make build.
>>>
>>
>> Really cool! Did you look at the compiler-rt stuff to use and/or replace
>> some of it?
>>
>>
>>>
>>> Modified:
>>>     llvm/trunk/cmake/modules/AddLLVM.cmake
>>>     llvm/trunk/cmake/modules/HandleLLVMOptions.cmake
>>>     llvm/trunk/tools/gold/CMakeLists.txt
>>>     llvm/trunk/tools/lto/CMakeLists.txt
>>>
>>> Modified: llvm/trunk/cmake/modules/AddLLVM.cmake
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/cmake/modules/AddLLVM.cmake?rev=198136&r1=198135&r2=198136&view=diff
>>>
>>> ==============================================================================
>>> --- llvm/trunk/cmake/modules/AddLLVM.cmake (original)
>>> +++ llvm/trunk/cmake/modules/AddLLVM.cmake Sat Dec 28 17:31:44 2013
>>> @@ -2,6 +2,72 @@ include(LLVMParseArguments)
>>>  include(LLVMProcessSources)
>>>  include(LLVM-Config)
>>>
>>> +function(add_llvm_symbol_exports target_name export_file)
>>> +  if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
>>> +    set(native_export_file "symbol.exports")
>>> +    add_custom_command(OUTPUT symbol.exports
>>> +      COMMAND sed -e "s/^/_/" < ${export_file} > symbol.exports
>>> +      DEPENDS ${export_file}
>>> +      VERBATIM
>>> +      COMMENT "Creating export file for ${target_name}")
>>> +    set_property(TARGET ${target_name} APPEND_STRING PROPERTY
>>> +                 LINK_FLAGS "
>>> -Wl,-exported_symbols_list,${CMAKE_CURRENT_BINARY_DIR}/symbol.exports")
>>> +  elseif(LLVM_HAVE_LINK_VERSION_SCRIPT)
>>> +    # Gold and BFD ld require a version script rather than a plain list.
>>> +    set(native_export_file "symbol.exports")
>>>
>>
>> It looks like you can't have two different export files for two different
>> targets which are built in the same directory? That's unfortunate. While
>> LLVM's makefile build system doesn't support building two targets in a
>> single directory, CMake generally does and it would be nice to preserve
>> this. I think it is even used in the sanitizers.
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140110/64ab8e9b/attachment.html>