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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org