-
-
Notifications
You must be signed in to change notification settings - Fork 161
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
Shared lib not being installed? #201
Comments
Ah, so it looks like we have two separate things for me to address here: 1. gnu_symbol_visibility: 'hidden'I did not realize meson applies that even if you choose to build as a static lib. That's... not particularly useful? I suppose there are scenarios where you are building one shared lib from separate compilations of a bunch of static libs, and having those static libs be part of the final library API, though that seems niche, heh. I can make that setting conditional 2. install: not is_subprojectThe rationale here was that if you bring toml++ in as a subproject you may not want your project to clobber an existing system install of it against the local user's wishes, if they had a different or customized version of it as their system-wide build. I can change that, though it just means that you should probably check for a local install of toml++ in your project's aside:
|
lib_args = cpp.get_supported_arguments('-DTOML_HEADER_ONLY=0') |
Ok, after reading this thread, it seems my intuition was correct; I'll leave the 'not is_subproject' as-is, but fix the |
That sounds reasonable to me. Given that symbol visibility should be consistent across the project and subprojects, it sounds sensible that the project should decide what the visibility should be which they can control via, e.g. Also, thanks for making this great library! |
Only for static libs, though. I believe I can safely leave this enabled when the library is built in shared mode, and have no impact on any parent project or subproject. For static libs there's almost no reason you'd set the symbol visibility to hidden anyways, so yeah I think the path of least resistance is to be more explicit about applying this to shared-only and expose some sort of configurable if it becomes an issue for someone in static mode (though you're the first to report that the symbols were hidden in static mode so I suspect it won't 😅)
🙇🏼 glad you like it :) |
@vlad0x00 I've pushed a fix for the [wrap-git]
url = https://github.com/marzer/tomlplusplus.git
revision = 882d9d1c34077d733559ec55d31c67799002239f
depth = 1
clone-recursive = false
[provide]
tomlplusplus = tomlplusplus_dep |
Woo! Thanks |
Environment
toml++ version and/or commit hash: dbc4bce
Compiler: N/A
C++ standard mode: N/A
Target arch: N/A
Library configuration overrides:
DTOML_HEADER_ONLY=0
Relevant compilation flags: N/A
Describe the bug
I've included
tomlplusplus
as ameson
subproject using WrapDB as described in README:meson wrap install tomlplusplus
. By default, it builds as a shared library but the built shared library is not installed and so I can't link with it during run time. The issue seems to be intomlplusplus/src/meson.build
:Installation is disabled if
tomlplusplus
is a subproject:install: not is_subproject
This is not an issue if I build
tomlplusplus
as a static library, but this linegnu_symbol_visibility: 'hidden'
is forcing my main project to also build with hidden symbols, otherwise the compiler complains. Perhaps building my project with hidden symbols is not a bad idea, but I'm not sure if forcing that on the user is ideal.Steps to reproduce (or a small repro code sample)
Additional information
The text was updated successfully, but these errors were encountered: