the libc++abi-devel provides libc++abi.so only
Hi
Correct, no static (*.a) files are provided only shared.
what’s the point to have the -devel package at all if it doesn’t differ from the normal libc++abi?
also, why doesn’t libc++ depend on libc++abi package? one does not function without another.
Devel has headers and other things that are not required for pure runtime operation of other packages. Some distros and os platforms do not do separate sub-packaging of devel files, bsd ports being a good example, but it has been a common feature of most linux distros.
There are various opinions about static libraries that range from licensing issues to being able to efficiently share security fixes. None of the enterprise distros generally use or accept packages with or that are linked by static libs as a matter of policy, though there was the curious exception of gcc’s c++17 filesystem support library, largely because the api was not stable.
That being said, I do feel there are valid use cases for static libs, but if anything, I think they should logically be designated in a -static, not a -devel package. For c++ it is also tempting to resolve redundant code segments from templating issues that cross compilation units and shared objects thru static linking, too. AlpineLinux offers static versions of most libs it builds and has good support for building pure static binaries, but it is the exception at present.
Hi
There are static libs in openSUSE, the package naming convention used is *-devel-static.
I did not notice that! Thanks!
It does look like libstdc++ does not have a devel-static (at least in leap), though glibc does, and I think that may well have been the original issue in this thread, too.
Dude look at the libc++abi and libc++abi-devel they are literally identical.
Is debian, for example, enterprise enough? Besides, the fact that distro itself doesn’t use it, dosn’t mean it shouldn’t provide the static libs for its users.
There are tons of reasons why static linking makes a lot of sense, especially in the realm of C++ (not C) development.
I seem to remember the static vs. dynamic linking wars, maybe 20 years ago. I hope we are not going back to that again.
I think its quite silly to force your views on others. If you don’t like static linking - fine! But please provide the static libs for others to use. Just like all debian derivatives do. The moon is not going to fall on earth if you include static libraries into the repository
In real world, there is still scenarios that the static libaries are useful.
The thing that block me build envoy proxy in openSUSE is that there is no official libc++.a and libc++abi.a provided.
/usr/bin/ld: cannot find -l:libc++.a
/usr/bin/ld: cannot find -l:libc++abi.a
although maybe you don’t like static libaries, we can build a seperate pakage, so users can install them seperately.
There is envoy-proxy package for openSUSE Leap 15.3, so apparently building is possible on openSUSE even without these libraries.
maybe you don’t like static libaries
You are barking up the wrong tree. This is user to user forum. To reach maintainers you need to open bug report and provide convincing arguments.