Skip to content
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

Better handle LINK_ALL_SYMBOLS option in cmake/generic.cmake #3

Open
acmol opened this issue Nov 15, 2017 · 0 comments
Open

Better handle LINK_ALL_SYMBOLS option in cmake/generic.cmake #3

acmol opened this issue Nov 15, 2017 · 0 comments

Comments

@acmol
Copy link
Collaborator

acmol commented Nov 15, 2017

We implemented two methods(cc_library, cc_binary) that accept LINK_ALL_SYMBOLS (which means export all symbols when linking, by wrapping the libs with gcc options "-Wl,--whole-archive" and "-Wl,--no-whole-archive" around) as argument in cmake/generic.cmake.

  1. A binary or a library can use ALL_SYMBOLS_DEPS to tell the linker that it needs all the symbols in its deps.

  2. A library who have LINK_ALL_SYMBOLS attribute should export all symbols to the ones that depend on it. We expect these symbols can be exported recursively, however only the ones that depend this library directly will link all the symbols currently.

  3. cc_test don't have similar functionality.

So, cmake/generic.cmake's cc_library/cc_binary/cc_test needs improvements to handle LINK_ALL_SYMBOLS.

@acmol acmol changed the title we should implement a better LINK_ALL_SYMBOLS in CMake We should implement a better LINK_ALL_SYMBOLS in CMake Nov 15, 2017
@acmol acmol changed the title We should implement a better LINK_ALL_SYMBOLS in CMake We should implement a better LINK_ALL_SYMBOLS in CMake Nov 15, 2017
@advancedxy advancedxy changed the title We should implement a better LINK_ALL_SYMBOLS in CMake Better handle LINK_ALL_SYMBOLS option in cmake/generic.cmake Nov 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant