[opensuse] why embedded versions for everything?
I compiled a new version some of the linux utils for some specific bug fix or feature, and with libsmartcols.so.1 getting recompiled. Afterwards, several programs would no longer run and I got messages like: /bin/findmnt: /lib64/libsmartcols.so.1: version `SMARTCOLS_2.25' not found (required by /bin/findmnt). The first thing I noted, was libsmartcols.so.1 had 3 versions: 1.0, 1.1 and 1.2, with version '1' pointing at '1.2'. None of those were version 2.25 -- the version number of the release of the linux utils. So why does findmnt look for a bogus version number when the version number is given in the file name? Second, what benefit does this provide to the end user? Why are these bogus version numbers being added to libraries and programs that run perfectly fine with out them (unless something requires them and failed when it can't fined them). I fail to see the benefit w/o unless a specific lib is messed up. Is there an easy util to run to strip all these out -- from libs and the programs that require them? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Wed, 22 Aug 2018, L A Walsh wrote:
/bin/findmnt: /lib64/libsmartcols.so.1: version `SMARTCOLS_2.25' not found (required by /bin/findmnt). [..] Second, what benefit does this provide to the end user? Why are these bogus version numbers being added to libraries and programs that run perfectly fine with out them (unless something requires them and failed when it can't fined them).
Those are _SYMBOL_ versions. $ nm /lib64/libsmartcols.so.1 0000000000000000 A SMARTCOLS_2.25 0000000000000000 A SMARTCOLS_2.27 0000000000000000 A SMARTCOLS_2.28 0000000000000000 A SMARTCOLS_2.29 [..] $ nm /lib64/libc.so.6 0000000000000000 A GLIBC_2.10 0000000000000000 A GLIBC_2.11 0000000000000000 A GLIBC_2.12 [..] ==== libsmartcols/src/libsmartcols.sym ==== SMARTCOLS_2.25 { global: scols_cell_copy_content; scols_cell_get_color; [..] SMARTCOLS_2.27 { global: scols_column_is_hidden; scols_table_enable_json; scols_table_is_json; scols_table_set_name; } SMARTCOLS_2.25; [..] ==== See Section '3.9 VERSION Command' of 'info ld'. HTH, -dnh -- printk(KERN_DEBUG "%s: Flex. Ttttt...\n", DRV_NAME); linux-2.6.6/drivers/net/wan/dscc4.c -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David Haller wrote:
Those are _SYMBOL_ versions. === Ok, so why do I need symbol version in everything? They prevent linkage with binaries built upstream as well as most binaries I build from source.
They seem to provide no useful feature -- especially considering that they cause many things to break that used to work.
See Section '3.9 VERSION Command' of 'info ld'.
I have no section 3.9 version command' in info ld or man ld. For that matter it has no section numbering at all. Mine comes up with an Overview, Invocation, Scripts, Machine Dependent features, BFD, Reporting Bugs and License. Nothing about Version or sections. Nothing in the manpage about a version command either. I had other problems in linkage and one upstream project source saw a switch regarding default-version symbols that I was unfamiliar with. He indicated that it might be the cause of some of my linking problems and to not use that switch as it was 'evil'. Not sure what he meant exactly, but maybe all the linkage problems are symptomatic of that? I tried googling on this as well and found that it was a way of working around something called a Diamond problem where some program depends on 2 different versions of the same library (something that would usually be called "a bug"). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-08-25 08:58, L A Walsh wrote:
David Haller wrote:
Those are _SYMBOL_ versions. === Ok, so why do I need symbol version in everything? They prevent linkage with binaries built upstream as well as most binaries I build from source.
They seem to provide no useful feature -- especially considering that they cause many things to break that used to work.
See Section '3.9 VERSION Command' of 'info ld'.
I have no section 3.9 version command' in info ld or man ld.
For that matter it has no section numbering at all.
Mine comes up with an Overview, Invocation, Scripts, Machine Dependent features, BFD, Reporting Bugs and License.
Nothing about Version or sections. Nothing in the manpage about a version command either.
Interestingly, there is, but not in all the document. I don't know how to locate a chapter directly. I had to use "pinfo" instead of info. Then, on the main page I type "s" for search, then enter "version command", which goes to: File: ld.info, Node: Scripts, Next: Machine Dependent, Prev: Invocation, Up: Top * VERSION:: VERSION Command * Expressions:: Expressions in Linker Scripts * Implicit Linker Scripts:: Implicit Linker Scripts Pressing "enter" on "VERSION" goes to: File: ld.info, Node: VERSION, Next: Expressions, Prev: PHDRS, Up: Scripts 3.9 VERSION Command =================== The linker supports symbol versions when using ELF. Symbol versions are only useful when using shared libraries. The dynamic linker can use In the main index page: * Overview:: is section 1. * Invocation:: is section 2 * Scripts:: is section 3 * Machine Dependent:: is section 4 * BFD:: 5 * Reporting Bugs:: 6 * MRI:: none * GNU Free Documentation License:: * LD Index:: And * Scripts:: (section 3) has another list of subchapters * Basic Script Concepts:: Basic Linker Script Concepts * Script Format:: Linker Script Format * Simple Example:: Simple Linker Script Example * Simple Commands:: Simple Linker Script Commands * Assignments:: Assigning Values to Symbols * SECTIONS:: SECTIONS Command * MEMORY:: MEMORY Command * PHDRS:: PHDRS Command * VERSION:: VERSION Command ====> is 3.9 * Expressions:: Expressions in Linker Scripts * Implicit Linker Scripts:: Implicit Linker Scripts -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
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. Think of it as a finer grained SONAME.
They prevent linkage with binaries built upstream as well as most binaries I build from source.
Blab..
They seem to provide no useful feature -- especially considering that they cause many things to break that used to work.
RTFM.
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' And if you'd look at the .sym file, you'd see what stuff is versioned with. -dnh -- I'll give you a definite maybe. -Samuel Goldwyn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
26.08.2018 10:47, L A Walsh пишет: ...
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.
... And how exactly ranting on this list is going to help? Why do not you contact developers of util-linux or even better binutils? I'm sure they do not mean any harm, they are simply ignorant of how to properly handle dynamic libraries and as soon as they get your educated advice they immediately drop this stupid useless support for symbol versioning. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/26/2018 4:03 AM, Andrei Borzenkov wrote:
26.08.2018 10:47, L A Walsh пишет: ...
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.
And how exactly ranting on this list is going to help?
Informing suse about similar practices that they have implemented -- even against the upstream developers recommendations hasn't helped when posted to suse's bugtrack. It seems useful to discuss the point here to see if there is any justification for such practice on suse's part before going to the upstream vendor.
Why do not you contact developers of util-linux or even better binutils?
I'm sure they do not mean any harm, they are simply ignorant of how to properly handle dynamic libraries and as soon as they get your (educated advice)[sic] question they [will] immediately drop this stupid useless support for symbol versioning.
--- I asked the same question on util-linux, though I didn't add your description of it. Would you like me to give them your heart felt opinion? I assume you are speaking in your role as an open suse contributor? FWIW, I'll stand by my comment that having a label inside a library for no apparent purpose that doesn't match the version number on the outside (derived from the filename) and doesn't allow default matching by older versions against the older symbols nor current versions (w/o the bogus internal version). Turning on *optional* module versioning in the kernel can allow a module to be compiled against multiple kernel versions. That's not the case here. So it doesn't appear to serve any useful purpose. There can be a use for symbol versioning -- if different symbols implement different features in different versions, but such practice is usually frowned up. More to the point, though, it would imply multiple copies of a symbol in different versioned sections. Such is not the case in most of the utilities (or any I've run it with so far, though I see evidence that it might be the case with some of them. Creating multiple interfaces by the same name is not good practice even though it may sometimes be necessary. To use that mechanism on all modules would appear to be laziness unless there is a better reason. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
David Haller -
L A Walsh