Re: [boost] Boost.DLL formal review is ongoing

Subject: Re: [boost] Boost.DLL formal review is ongoing
From: William Gallafent (william_at_[hidden])
Date: 2015-07-14 06:09:52

On 13 July 2015 at 21:24, Antony Polukhin <antoshkka_at_[hidden]> wrote:
> I was trying to keep namings platform neutral: "dynamic library" is too
> Windows specific, "shared object" is too POSIX specific... Let it bee DLL
> for library abbreviation and "shared object" mostly in docs and source
> codes.

On Mac OS, the files in question are generally named
“libSomething.dylib”, whereas on Windows the equivalent file would be
“something.dll”. That seems to directly contradict your assertion that
“dynamic library” is more Windows-specific, since “dylib” looks more
like a contraction of that phrase than “dll” to me.

More generally, and fwiw, in my mind I connect “DLL” very tightly to
Windows, to the extent that if somebody says “DLL” I think “we're
talking about something which is exclusively related to Windows”. I
tend to use instead the term “shared library” when referring to these
files in a platform-neutral way (in other words, when I say “shared
library” I mean .dll on Windows, .dylib on Mac OS, and .so on Linux,
for example). In that way (none of these platforms uses a contraction
of “shared library” as its way of visually identifying these files in
the filesystem) I try to separate cross-platform discussion from
platform-specific discussion. To me, “shared object” feels, as you
say, very POSIX-specific.

By way of comparison, the “file” utility on this Mac OS machine
returns, for example, “/opt/local/lib/libgtk-3.0.dylib: Mach-O 64-bit
dynamically linked shared library x86_64”. A similar example on Ubuntu
Linux: “/lib/libfuse.so.2.8.6: ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked,
BuildID[sha1]=0x8776ddf840d71df11e0f99388074338a4dbc05c7, stripped”.
Finally, on Windows I see of course
“/cygdrive/c/Windows/System32/ntdll.dll: PE32+ executable (DLL)
(console) x86-64, for MS Windows”.

There is in fact no /shared/ nomenclature between all three at all
there (because DLLs /are/ executables on Windows!). Something which
has the right connotations but which isn't the terminology returned by
that utility, or used as a filesystem contraction, for any specific
platform seems ideal.

> Any library related comments from any reviewer are welcomed even after the
> review end.

Apologies for the fact that my comments are purely in the area of nomenclature!

-- 
Bill Gallafent.