Slibtool only supports -export-symbols and -export-symbols-regex as no-ops, but these are very important features to make sure the library has:
-export-symbols
-export-symbols-regex
On GNU/Linux using GNU libtool with gcc or clang -export-symbols takes a single arbitrarily named version script file as documented by GNU and passes it to the linker with -Wl,-version-script,foo.ver. Note that modern clang versions will fail if it encounters any undefined symbols inside of the version script file.
-Wl,-version-script,foo.ver
https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html
For example:
LIBFOO_1.0 { global: libfoo_init; libfoo_doit; libfoo_done; local: *; };
{ global: foo_*; local: *; };
LIBFOO_0.1.2 { global: extern "C++" { "foo::name[abi:cxx11](foo::type)"; foo::function*; foo::bar::*; }; local: *; };
With C++ it expects unmanagled symbols, but wild cards work to avoid that.
With -export-symbols-regex it takes the input regex and creates the file for the user.
On Darwin it instead uses -exported_symbols_list, but I am not sure GNU libtool supports it there?
-exported_symbols_list
Additionally Darwin uses a different syntax, for example:
# File: export_list _name _set_name _foo_*
https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html
With C++ I think it requires the mangled symbols, but I am not sure?
For test cases libressl depends on -export-symbols and pkgconf depends on -export-symbols-regex.
There may be other behaviors on other systems or older gcc and clang versions, take the cmake_export_symbol.cmake file from the libressl cmake build for example.
cmake_export_symbol.cmake
https://github.com/libressl/portable/blob/4e25dc4f063ac93ccbdf575c3ea82d52281755aa/cmake_export_symbol.cmake
@RJVB could you upload an example .exp file that would be the the input of darwin's -exported_symbols_list switch? Thanks!
.exp
On GNU/Linux using GNU libtool with gcc or clang -export-symbols takes a single arbitrarily named version script file as documented by GNU and passes it to the linker with -Wl,-version-script,foo.ver. Note that modern clang versions will fail if it encounters any undefined symbols inside of the version script file. https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html
^ to complete the picture: the version script as specified above is what slibtool is expected to generate. The argument to slibtool's -export-symbols should be a plain list of symbols, one per line, as indicated below:
https://www.gnu.org/software/libtool/manual/libtool.html#Link-mode
This is an interesting issue that might fail because of -export-symbols-regex not yet being supported.
https://bugs.gentoo.org/924407
Some tests segfault when liboil is built with slibtool, but not when they are built with GNU libtool. However if the library is built with GNU libtool and the test is built with slibtool the segfault is gone.
The most obvious difference between GNU libtool and slibtool is that liboil uses -export-symbols-regex.
And another example that very likely fails because -export-symbols-regex is not yet supported.
https://bugs.gentoo.org/924404
It has a test that explicitly checks that the correct symbols are exported which is obviously not yet true with slibtool.
Both -export-symbols and -export-symbols-regex now work including with libressl, pkgconf, liboil and jansson. However the liboil failure is actually because of an unrelated issue.
Metadata Update from @orbea: - Issue status updated to: Closed (was: Open)
I made a new issue for liboil.
https://dev.midipix.org/cross/slibtool/issue/62
Login to comment on this ticket.