[std-proposals] P0275R4: add_decorations and version numbers

[Thiago Macieira]

Ref: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0275r4.html

Hello Antony

Thank you for your proposal. This is an important library addition for
something low-level that has been awfully OS-specific for a long time. I don't
have a comment on questions on whether discussing shared libraries without
specifying TLS, globals, exceptions, ODR violations, etc. is acceptable.
Hopefully you'll get feedback from others on that.

I just wanted to raise the point of having the ability to insert version
numbers in library names, especially when shared_library::add_decorations and/
or shared_library::search_system_directories are in effect. In short, it is
the ability to specify both the library's base name and the expected version
decoration and let the implementation figure out how to properly load them.
QLibrary has this API:

QLibrary libc("c", 6);
QLibrary libssl("ssl", SHLIB_VERSION_NUMBER);

Let me give you a concrete example: loading OpenSSL at runtime (which is the
second line above). Given its licensing and export restrictions that some
countries place on cryptographic code, a common solution is to compile against
OpenSSL headers but not link to it. Instead of calling its functions,
applications and libraries instead load the library at runtime and resolve the
functions they need to call.

But in the presence of multiple ABI-incompatible libraries, one needs to know
which library to load. OpenSSL helpfully provides us with that in the
SHLIB_VERSION_NUMBER macro:

$ grep -r SHLIB_VERSION_NUMBER /usr/include/openssl
/usr/include/openssl/opensslv.h:# define SHLIB_VERSION_NUMBER "1.1"

And that matches the file we need to load:

$ eu-readelf -d /usr/lib64/libssl.so | grep SONAME
SONAME Library soname: [libssl.so.1.1]

Given this need, the ask for shared_library class is to be able to specify
both pieces of information separately and let the implementation reconstruct
the actual file name according to OS details. Like in my QLibrary example, I
want to specify "ssl" plus the "1.1" string only.

I don't want to specify the ".so" part in the name, since this can be
different in different OSes. Notably, it IS different on macOS, which use
"dylib" instead of "so". Not only that, the version number is often placed as
an infix instead of a suffix:

$ ls -l /usr/lib/libssl*
-rwxr-xr-x 1 root wheel 392912 Jan 18 2018 /usr/lib/libssl.0.9.7.dylib
-rwxr-xr-x 1 root wheel 630144 Mai 29 16:36 /usr/lib/libssl.0.9.8.dylib
-rw-r--r-- 1 root wheel 947104 Mai 29 16:36 /usr/lib/libssl.35.dylib
-rw-r--r-- 1 root wheel 890800 Mai 29 16:36 /usr/lib/libssl.43.dylib
lrwxr-xr-x 1 root wheel 15 Mar 15 2018 /usr/lib/libssl.dylib -> libssl.
35.dylib

I also don't want to depend on the unversioned link. As seen in the ls output
above, it can be pointing to the wrong library. Moreover, on Linux systems,
the .so file is often not present unless the optional development headers are
too.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Myriachan]

Post by Thiago Macieira
Ref: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0275r4.html
Hello Antony
Thank you for your proposal. This is an important library addition for
something low-level that has been awfully OS-specific for a long time. I don't
have a comment on questions on whether discussing shared libraries without
specifying TLS, globals, exceptions, ODR violations, etc. is acceptable.
Hopefully you'll get feedback from others on that.

I do have some feedback about that =^-^=

* The feature ought to be usable without a lot of platform-dependent
work. If there is a lot of platform-dependent work to do just to get a
basic library loading, what's the point of standardizing?

* This means that some of the basic functionality needs to be specified:
global constructors of a DLL executing on DLL load, for example, and
conversely destructors on unload. Supporting exceptions is painful, but
it's part of the language. dynamic_cast is a similar can of worms. (In
practice, current implementations will resort to strcmp() to implement type
comparison across module boundaries in the worst case. Identically-named
classes are considered to be the same, and if not, undefined behavior.)

* Not all platforms support dynamic loading, so the feature needs to be
optional.

* Not all platforms have the ability to unload after loading. Mac dylib
files used to be this way.

* The Standardese needs to state that pointers and references to objects
of static storage duration within an unloaded DLL are invalidated.

* Regarding the RTLD_* thing: On many non-POSIX platforms (notably
Windows, but others too), there is no global symbol table at all. Each
module (primary program or dynamic library) has its own exported symbol
list that is entirely separate from the others. Conversely, on POSIX,
unless certain measures are taken, modules cannot have identically-named
symbols or things can break badly. Overriding operator new comes to mind.

* I feel that this proposal ought to dive into the details of how this
would work on various popular operating systems. The Standardese part
shouldn't, but the proposal can show that this can actually be implemented
meaningfully by covering these.

* A way to export a function would be nice. [[shared_library_export]]
would be nice as an equivalent of
__attribute__((__visibility__("default"))) / __declspec(dllexport), as a
possible example.

* I like the wording about extern "C"; either use it, or you're on your
own.

[Matthew Woehlke]

Post by Myriachan
* A way to export a function would be nice. [[shared_library_export]]
would be nice as an equivalent of
__attribute__((__visibility__("default"))) / __declspec(dllexport), as a
possible example.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1283r0.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0276r0.html

...?