Re: Bug#961417: RFS: libudfread/1.0.0-1 -- UDF reader library
On Mon, Jun 1, 2020 at 3:04 PM The Wanderer wrote:
> If I need to compile a program to run in an environment where I can't
> know what libraries / library versions are going to be available, or
> maybe even do know for a fact that certain ones will not be available,
> the obvious solution is to link it statically
Do you have any examples of environments where you would ship Debian
derived static binaries?
AFAICT, outside the language communities where dynamic linking is
either impractical (due to ABI instability or other issues) or not
available, static linking has been replaced by things like
Docker/AppImage/Flatpak. Usually static linking isn't enough anyway,
since there are almost always files that aren't libraries that you
want to bundle with your application. Docker/AppImage/Flatpak allow
this extra bundling. Also, people tend to vendor code instead of
static linking distro static libs. Indeed, there is a general trend
away from distros.
Also, ISTR there is something about glibc nss not working in static binaries?
> - but if Debian doesn't ship the static libraries
> how exactly am I supposed to do that in Debian?
Either rebuild or request addition of the static lib to the package(s) needed.
> Can you point me to a reference for the statement that it is now general
> practice to discourage shipping of static libraries (as distinct from
> statically-linked executables) in Debian packages?
Its more of a trend I have noticed in both discussions and packages
than a specific policy.
For example there are a lot more libraries that can be linked
dynamically than statically:
$ apt-file search -x '/usr/lib/.*\.a$' | wc -l
$ apt-file search -x '/usr/lib/.*\.so$' | wc -l
Some packages explicitly enable static libs but a few more explicitly
Probably some of that is a 2015 change I made to dh-make that disables
them by default: