3.0: libsemanage uses libsepol non-public symbols. #204
Comments
|
Not sure what you mean here or how you are building this, but libsemanage builds fine for me and only uses symbols from libsepol exported by libsepol.map. |
|
Yes uit builds but on linking it uses static libsepol. I've been trying to build libsemanage using only shared libsepol and I found that libsemanage uses libsepol symbols which are not listed in public symbols of that library. |
|
The first error you showed was:
but sepol_bool_* is exported by libsepol.map.in and is visible in the symbol table of libsepol.so.1. |
|
I have installed libsepol generated with LTO and just rebuild libsepol without LTO: As you see in case binary optimised with LTO there are missing 5 sepol_bool_* symbols. And I found just why, Yopu are listing some symbols which are listed in installed API header giles as hidden. If symbol is hidden it is automatically removed by LTO. You shoud decide which one symbols should be public and which one private/hiddenm. |
|
hidden_proto() doesn't hide the exported symbol definition; it creates a hidden internal variant of the symbol with an _internal suffix for internal callers to use to avoid the unnecessary cost and risk of those internal callers being resolved to an external implementation provided by some other shared object. hidden_proto/hidden_def stuff came from Red Hat glibc folks originally IIRC. |
|
Looking back at history, it came from Ulrich Drepper originally to reduce relocations and PLT entries and avoid need for any PLT entries for local symbols |
|
Looks like this macro is affecting LTO generated DSOs. I understand you intention however looks like Urlich prepared this approach when no one have been even thinking about LTO. Here is exact list of symbols libsepol symbols which will be affected by this issue: |
|
Per the earlier discussion in #165, there are other challenges with LTO and the use of symbol versioning unless those have been overcome. |
|
Versioning symbols is now fine. |
|
Ok, if you want to submit patches to the list to drop the hidden_proto/hidden_def stuff from libsepol and libsemanage I won't object. Doing it to libselinux would require at least demonstrating that it is a net win performance wise since that one is widely used. |
|
Will back in few days because first Ill try to test whole SELinux stack with LTO than if all will be OK will try to prepare separated PRs against each component. |
|
By the way, if you want to drop |
|
That kind of things does ac/am/lt based tooling. I think that I've already asked you did you you will accept ac/am/lt based build/release automation and you said IIRC now. |
|
Please do not change the subject of the current issue. If you want to discuss about upgrading the build/release files/scripts to something more maintainable (like autotools, cmake, meson...), please open a different issue or start a thread on the mailing list (selinux@vger.kernel.org). |
Previously discussed here: |
|
Discussion on selinux list about removing hidden_def/hidden_proto and patches to do so: |
With the old hidden_def and hidden_proto DSO infrastructure removed, correctness of the map file becomes paramount, as it is what filters out public API. Because of this, the wild cards should not be used, as it lets some functions through that should not be made public API. Thus remove the wild cards, and sort the list. Additionally, verify that nothing changed in external symbols as well: This was checked by generating an old export map (from master): nm --defined-only -g ./src/libsepol.so | cut -d' ' -f 3-3 | grep -v '^_' > old.map Then creating a new one for this library after this patch is applied: nm --defined-only -g ./src/libsepol.so | cut -d' ' -f 3-3 | grep -v '^_' > new.map And diffing them: diff old.map new.map Fixes: SELinuxProject#165 Fixes: SELinuxProject#204 Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: William Roberts <william.c.roberts@intel.com>
With the old hidden_def and hidden_proto DSO infrastructure removed, correctness of the map file becomes paramount, as it is what filters out public API. Because of this, the wild cards should not be used, as it lets some functions through that should not be made public API. Thus remove the wild cards, and sort the list. Additionally, verify that nothing changed in external symbols as well: This was checked by generating an old export map (from master): nm --defined-only -g ./src/libsepol.so | cut -d' ' -f 3-3 | grep -v '^_' > old.map Then creating a new one for this library after this patch is applied: nm --defined-only -g ./src/libsepol.so | cut -d' ' -f 3-3 | grep -v '^_' > new.map And diffing them: diff old.map new.map Fixes: SELinuxProject#165 Fixes: SELinuxProject#204 Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: William Roberts <william.c.roberts@intel.com>
With the old hidden_def and hidden_proto DSO infrastructure removed, correctness of the map file becomes paramount, as it is what filters out public API. Because of this, the wild cards should not be used, as it lets some functions through that should not be made public API. Thus remove the wild cards, and sort the list. Additionally, verify that nothing changed in external symbols as well: This was checked by generating an old export map (from master): nm --defined-only -g ./src/libsepol.so | cut -d' ' -f 3-3 | grep -v '^_' > old.map Then creating a new one for this library after this patch is applied: nm --defined-only -g ./src/libsepol.so | cut -d' ' -f 3-3 | grep -v '^_' > new.map And diffing them: diff old.map new.map Fixes: SELinuxProject#165 Fixes: SELinuxProject#204 Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: William Roberts <william.c.roberts@intel.com>
With the old hidden_def and hidden_proto DSO infrastructure removed, correctness of the map file becomes paramount, as it is what filters out public API. Because of this, the wild cards should not be used, as it lets some functions through that should not be made public API. Thus remove the wild cards, and sort the list. Additionally, verify that nothing changed in external symbols as well: This was checked by generating an old export map (from master): nm --defined-only -g ./src/libsepol.so | cut -d' ' -f 3-3 | grep -v '^_' > old.map Then creating a new one for this library after this patch is applied: nm --defined-only -g ./src/libsepol.so | cut -d' ' -f 3-3 | grep -v '^_' > new.map And diffing them: diff old.map new.map Fixes: SELinuxProject#165 Fixes: SELinuxProject#204 Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: William Roberts <william.c.roberts@intel.com>
I followed the same patch, but the same "undefined reference to ..." happended. thank you in advance! |
|
@david3chan As explained in #204 (comment) :
For example Do you encounter "undefined reference to ..." outside of tests? |
Looks like libsemanage cannot be linked against shared libsepol because it uses libsepol symbols not listed in libsepol.map.in :/
The text was updated successfully, but these errors were encountered: