David Haller wrote:
Hello,
On Fri, 24 Aug 2018, L A Walsh wrote:
David Haller wrote:
Those are _SYMBOL_ versions. === Ok, so why do I need symbol version in everything?
Because there may be symbols (a function) that are only in e.g. libc GLIBC_2.1x and later, and if your program needs that, it needs to depend on that GLIBC_2.1x (or greater) version.
No, I just get the latest GLIBC and use it for everything. That's how things have worked for the past 20 years... If these things were hints, with a fall back to "use latest revisions of symbols / functions', that would be fine. But it isn't It's select 1 from 20 versions from fileA, 5 versions from fileB, ...etc. With no indication of what one could search for by *file*, because filesystem and web search engines can't peek inside binaries for what versions they support. If you want to support multiple versions, that's usually possible -- the only case where they are needed is where you provide multiple *incompatible* interfaces in the same library and a linking program uses more than one of them at the same time. Then it needs the versions of each of the interfaces. However, that has been universally considered a bad thing to do. MS fixed their DLL hell over a decade ago with Win7/Vista. Unix HAD it fixed with dynamically loaded libs (@ run time), that would give alternate views of programs depending on what libs were loaded, as well as versioning of libs and programs.
Think of it as a finer grained SONAME.
--- That is invisible to tools to look for latest revisioned files to link with. *If* such is absolutely necessary, (and have yet to see a case where it is -- i.e. stripping out versions or rebuilding things w/o the versions, and things work fine again. But the way it is now, you have an interlocking jigsaw of pieces that prevent upgrading, fixing problems or building your own utilities because current ones have problems or are missing needed features.
They prevent linkage with binaries built upstream as well as most binaries I build from source.
Blab..
Blorb!
They seem to provide no useful feature -- especially considering that they cause many things to break that used to work.
RTFM.-
--- I did, with most places indicating they are designed for special use cases...not for every library.
See Section '3.9 VERSION Command' of 'info ld'. I have no section 3.9 version command' in info ld or man ld.
You have. As Carlos explained. Or see
$ info '(ld)VERSION'
--- So I have a 3.9 version command in man ld?.. I beg to differ. I can find it with your followup, but its not very useful for telling me why software would be so poorly designed as to need such detail.
And if you'd look at the .sym file, you'd see what stuff is versioned with.
---- And as I said above -- if the fall back was previous behavior of linking with the latest set of symbols available, that would be find, but it stops a booting system that can't load 'mount' dead in its tracks. Fortunately I found a mount.static, that worked to bring up the system, but there seems little in the way of boot-check utils that can check that a system will come up after several files have been updated. I don't understand why ALL libraries need this. And I don't understand why there is no fail-safe fall back vs. the fail-locked-out behavior I'm seeing now. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org