Mailinglist Archive: opensuse-factory (381 mails)

< Previous Next >
[opensuse-factory] Re: where did libstdc++.la go?
On 10/14/2018 2:16 AM, Simon Lees wrote:
If it existed it would be in a static-devel package generally in
openSUSE we don't ship files for static linking, with a few exceptions
---
That's part of the problem -- I don't know which have exceptions
nor why.




because it mostly doesn't make sense for us vs dynamic linking,
---
Am not entirely sure why it doesn't make sense, other than what appears to be caprice.



Is there a specific reason why your using static linking? if not try
dynamic linking instead and you won't have these issues.
---
The least important, though perhaps easiest to run into, is
using defaults for gnu configure that comes with many 3rd party tools, including newer versions of suse tools. Specifically, these lines, present in many configure-help outputs:

--enable-shared[=PKGS] build shared libraries [default=yes]
--enable-static[=PKGS] build static libraries [default=yes]

Default is to try to build both.

The second and more important reason concerns reliability,
consistency and/or portability for critical system utils.

The worst example has been trying to run 'mount' in /bin, but having some of its libraries in /usr/lib64 when /usr is a separately mountable partition.

According to the usrmerge page, contents on the root partition should
be stand-alone, architecture specific, with the intent that content in /usr
should be not architecture specific.

Specifically they write:

* With the merged /usr directory we can offer a read-only
export of the vendor supplied OS to the network, which will
contain almost the entire operating system resources. The
client hosts will then only need a minimal host-specific root
filesystem with symlinks pointing into the shared /usr
filesystem.

In order to mount "/usr", however, the facilities needed to boot the system
to the point that it can mount file systems needs to function flawlessly from
the root file system. While one might hope that libraries for these utils
would be placed in /lib64, too often they end up in /usr/lib64. The only way to
ensure the needed functions are present when the binaries are executed is to
place
them in 1 file, i.e. a static link.

The safest build is one that doesn't need load-time linking.

While I can recompile some packages for root, I've only managed to recover from
mount missing libs on /usr using archived copies of 'mount' stored in previous bin-dirs.

There has been a resurgence of demand for static mounting if one looks in google, due the many new problems people are discovering w/load-time-linking.

If a package like one basing function on contents of "/etc/nsswitch", needs dynamic linking, let it use *run*-time linking for needed functions and
only when called for. Or let it use plugins. Plugins work for other software (samba, bash, vim, squid to name a few). There is no reason why
it couldn't work for nsswitch dependent SW.

Meanwhile, I see no reason I can't choose a binary that combines the
methods I need and build it to include those methods -- much like one can choose
kernel modules that are hardcoded or can allow then to be run-time loadable modules wouldn't work, no?










--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References