[opensuse-factory] where did libstdc++.la go?
In making a tool, I got libtool: error: cannot find the library '/usr/lib64/../lib64/libstdc++.la' or unhandled argument '/usr/lib64/../lib64/libstdc++.la' So I went to look for it. I can't find it in tumbleweed. What could have happened to it? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2018-10-13 10:46, L A Walsh wrote:
In making a tool, I got libtool: error: cannot find the library '/usr/lib64/../lib64/libstdc++.la' or unhandled argument '/usr/lib64/../lib64/libstdc++.la'
So I went to look for it.
I can't find it in tumbleweed. What could have happened to it?
like most .la files, it never really existed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 13/10/2018 19:16, L A Walsh wrote:
In making a tool, I got libtool: error: cannot find the library '/usr/lib64/../lib64/libstdc++.la' or unhandled argument '/usr/lib64/../lib64/libstdc++.la'
So I went to look for it.
I can't find it in tumbleweed. What could have happened to it?
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 because it mostly doesn't make sense for us vs dynamic linking, maybe we could / should for gcc though. Is there a specific reason why your using static linking? if not try dynamic linking instead and you won't have these issues. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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
Hello, On Sun, 14 Oct 2018, L A Walsh wrote:
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.
That's not the point. The .la file is _NOT_ needed[1]. You just need the static lib (in /usr/lib{,32,64}/gcc/${host-triplet}/${version}/libstdc++.a, which will be picked up by the linker when you use '-static -lstdc++'. Not even a need for -L. Your project searching for the .la file in /usr/lib64/ is broken. I should neither explicitly look for the .la file nor explicitly in /usr/lib64 (or /usr/lib64/foo/../lib64). Sample host: $ locate libstdc++.la $ locate libstdc++.a /usr/lib64/gcc/x86_64-pc-linux-gnu/6.4.0/32/libstdc++.a /usr/lib64/gcc/x86_64-pc-linux-gnu/6.4.0/libstdc++.a /usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/32/libstdc++.a /usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/libstdc++.a It's been this way for many many years (at least since oS 12.1 in 2011/11). Using .la files has been strongly discouraged even before that, and I think it's policy now for years, though I can't find that online. JFTR: on a 12.1: $ ls /usr/lib64/*.la | wc -l 72 $ ls /usr/lib64/*.a | wc -l 201 $ ls /usr/lib64/*.so | wc -l 1111 $ rpm -qf /usr/lib64/*.la | sort -u | wc -l 28 Different host (current): $ ls /usr/lib64/*.la | wc -l 111 $ ls /usr/lib64/*.a | wc -l 203 $ ls /usr/lib64/*.so | wc -l 1739 $ [analog to rpm -qf /usr/lib64/*.la | sort -u | wc -l] 73 And in both ISTR it's considered a bug that those .la files are there. Oh, and: $ cat t.cc #include <iostream> int main(void) { std::cout << "Hello World!" << std::endl; return 0; } $ g++ -Wl,-t t.cc -o t.out [..] /tmp/ccall71V.o -lstdc++ (/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/libstdc++.so) [..] $ ./t.out Hello World! $ g++ -c -o t.o t.cc $ clang++ -Wl,-t -o t.out t.o [..] t.o -lstdc++ (/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/libstdc++.so) $ clang++ -Wl,-t -o t.out t.cc [..] /tmp/t-bf16f5.o -lstdc++ (/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/libstdc++.so) Go figure! Actually, explicitly linking against libstdc++ (or libc) is broken anyway, unless you have very good reasons to directly use ld instead of g++ or clang++ etc. as a linker call. And if you'd do, you'd not need to ask. So, as you're not even telling what "project" that is, and how the call to the linker is and from where ... -dnh [1] there might be some corner cases, but I know of none. -- The documentation is in Japanese. Good luck. -- Rich $alz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 14 Oct 2018, Simon Lees wrote:
On 13/10/2018 19:16, L A Walsh wrote:
In making a tool, I got libtool: error: cannot find the library '/usr/lib64/../lib64/libstdc++.la' or unhandled argument '/usr/lib64/../lib64/libstdc++.la'
So I went to look for it.
I can't find it in tumbleweed. What could have happened to it?
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 because it mostly doesn't make sense for us vs dynamic linking, maybe we could / should for gcc though.
Static runtime libs from GCC are shipped with the gcc{,-c++,-fortran,...} {,-32bit,-64bit} packages. Statically linking those is under control of the compiler driver because it usually isn't "simple" enough so that what .la files provide is enough. There's even specific flags to link specific libs statically, like -static-libstdc++.
Is there a specific reason why your using static linking? if not try dynamic linking instead and you won't have these issues.
... but of course a simple -static also links libstdc++ statically.
I'm curious what piece of software looks for libstdc++.la and refuses
to statically link when that's not available.
Richard.
--
Richard Biener
On 10/15/2018 1:28 AM, Richard Biener wrote:
I'm curious what piece of software looks for libstdc++.la and refuses to statically link when that's not available.
On 10/15/2018 7:12 AM, David Haller wrote:
So, as you're not even telling what "project" that is, and how the call to the linker is and from where ...
-------- Original Message -------- Subject: [ANNOUNCE] util-linux v2.33-rc1 Date: Tue, 25 Sep 2018 12:47:01 +0200 From: Karel Zak The util-linux release v2.33-rc1 is available at http://www.kernel.org/pub/linux/utils/util-linux/v2.33/ Feedback and bug reports, as always, are welcomed. Karel ---- As for my results....I'm getting different results now than before and not sure why, so checking w/util-linux list. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
David Haller -
Jan Engelhardt -
L A Walsh -
Richard Biener -
Simon Lees