PengZheng commented on issue #442: URL: https://github.com/apache/celix/issues/442#issuecomment-1502720996
> To be honest I am not sure how this needs to be applied to bundle libraries. Bundles are also shared libraries, so we only have to deal with shared objects. As you have noted, bundles are simpler, since they export a fixed set of symbols, i.e. activator symbols. For shared library (and bundle) target, we set `C_VISIBILITY_PRESET` and `CXX_VISIBILITY_PRESET` to be `hidden` and `VISIBILITY_INLINES_HIDDEN` to be `ON`. Then for a given shared library, we add `CELIX_EXPORT` to its public API. For bundles, we can set these target properties in `add_celix_bundle`, and add `CELIX_EXPORT` to `celix_bundle_activator.h`, and then we're done. I think `CELIX_LOCAL` is not really necessary. > Does this means that all C++ - note header only - methods needs to be declared as "CELIX_LOCAL" , with an exception for the C++ exceptions? No, these C++ headers does NOT form public API of any shared object. Users can use it to write static/shared library, executable, or whatever they want. They should take care of the symbol visibility themselves. With the help of CMake (GenerateExportHeader), it should not be burdensome. C++ ABI is notoriously hard to maintain, I'm happy we don't have it (please correct me if I were wrong). But [CppMicroServices](https://github.com/CppMicroServices/CppMicroServices) does have C++ API, and they control their class's visibility using similar approach. > Is an other option to let the add_celix_bundle cmake function default produce a linker script, so that only the bundle activator functions are global? I use version script (-Wl,--version-script=) as a last resort. It works like charm, especially when I can not modify the upstream. For example, when doing footprint optimization of OpenSSL, I use it to only export the used symbols (approximately 300) instead of 3000+. But it leads to less optimized code, see Section 2.2 of Ulrich Drepper's definitive [How To Write Shared Libraries](https://www.akkadia.org/drepper/dsohowto.pdf) . -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org