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



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/11611238.EZ8KjN7Ls5%40tjmaciei-mobl1.

.

------=_Part_3332_81712548.1539916465525
Content-Type: multipart/alternative;
 boundary="----=_Part_3333_1341742598.1539916465525"

------=_Part_3333_1341742598.1539916465525
Content-Type: text/plain; charset="UTF-8"

On Wednesday, October 17, 2018 at 11:05:46 AM UTC-7, Thiago Macieira wrote:
>
> 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.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/97604811-ad36-4556-a469-9670f55e0cb3%40isocpp.org.

------=_Part_3333_1341742598.1539916465525
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, October 17, 2018 at 11:05:46 AM UTC-7, Thiag=
o Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Ref: <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0275r4.html" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://ww=
w.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2F=
docs%2Fpapers%2F2018%2Fp0275r4.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NEHV1_ovYEHGuJmRT7e8mlJUqyLQA&#39;;return true;" onclick=3D"this.href=3D&#3=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc2=
2%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0275r4.html\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNEHV1_ovYEHGuJmRT7e8mlJUqyLQA&#39;;return true;">http://www.open=
-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2018/<wbr>p0275r4.html</a>
<br>
<br>Hello Antony
<br>
<br>Thank you for your proposal. This is an important library addition for=
=20
<br>something low-level that has been awfully OS-specific for a long time. =
I don&#39;t=20
<br>have a comment on questions on whether discussing shared libraries with=
out=20
<br>specifying TLS, globals, exceptions, ODR violations, etc. is acceptable=
..=20
<br>Hopefully you&#39;ll get feedback from others on that.
<br>
<br></blockquote><div><br></div><div>I do have some feedback about that =3D=
^-^=3D</div><div><br></div><div>=C2=A0* The feature ought to be usable with=
out a lot of platform-dependent work.=C2=A0 If there is a lot of platform-d=
ependent work to do just to get a basic library loading, what&#39;s the poi=
nt of standardizing?</div><div><br></div><div>=C2=A0* 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 unloa=
d.=C2=A0 Supporting exceptions is painful, but it&#39;s part of the languag=
e.=C2=A0 dynamic_cast is a similar can of worms.=C2=A0 (In practice, curren=
t implementations will resort to strcmp() to implement type comparison acro=
ss module boundaries in the worst case.=C2=A0 Identically-named classes are=
 considered to be the same, and if not, undefined behavior.)<br></div><div>=
<br></div><div>=C2=A0* Not all platforms support dynamic loading, so the fe=
ature needs to be optional.<br></div><div><br></div><div>=C2=A0* Not all pl=
atforms have the ability to unload after loading.=C2=A0 Mac dylib files use=
d to be this way.</div><div><br></div><div>=C2=A0* The Standardese needs to=
 state that pointers and references to objects of static storage duration w=
ithin an unloaded DLL are invalidated.<br></div><div><br></div><div><div>=
=C2=A0* Regarding the RTLD_* thing: On many non-POSIX platforms (notably
 Windows, but others too), there is no global symbol table at all.=C2=A0 Ea=
ch
 module (primary program or dynamic library) has its own exported symbol
 list that is entirely separate from the others.=C2=A0 Conversely, on POSIX=
, unless certain measures are taken, modules cannot have identically-named =
symbols or things can break badly.=C2=A0 Overriding operator new comes to m=
ind.<br></div><div><br></div><div>=C2=A0* I feel that this proposal ought t=
o dive into the details of how this would work on various popular operating=
 systems.=C2=A0 The Standardese part shouldn&#39;t, but the proposal can sh=
ow that this can actually be implemented meaningfully by covering these.<br=
></div><div><br></div><div>=C2=A0* A way to export a function would be nice=
..=C2=A0 [[shared_library_export]] would be nice as an equivalent of __attri=
bute__((__visibility__(&quot;default&quot;))) / __declspec(dllexport), as a=
 possible example.</div><div><br></div><div>=C2=A0* I like the wording abou=
t extern &quot;C&quot;; either use it, or you&#39;re on your own.<br></div>=
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/97604811-ad36-4556-a469-9670f55e0cb3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/97604811-ad36-4556-a469-9670f55e0cb3=
%40isocpp.org</a>.<br />

------=_Part_3333_1341742598.1539916465525--

------=_Part_3332_81712548.1539916465525--

.

On 18/10/2018 22.34, Myriachan wrote:
>  * 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

....?

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/493f4810-0b31-1d09-05a1-6273b60c6318%40gmail.com.

.