Why don't Unix/Linux systems traverse through directories until they find the required version of a linked library?Confusion about linking boost library while compilationIs it possible to configure dynamic loader for an executableI am getting an error while loading shared libraries libXm.so.3Satisfying lib dependencyError while building snipersim: “relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC”How do I find the libraries this program needs for its environment variable?How to regain access to the lost user , linux3 , of two side by side Ubuntu 16.04 instances?Where do C# executables running on an Ubuntu Linux 16.04 desktop which use source code that DLLImport's shared objects look for them at runtime?Cannot find shared object file even though it's in library pathPlaced library in /usr/lib, but ldconfig doesn't put it in cache
Has the Hulk always been able to talk?
How to use dependency injection and avoid temporal coupling?
Didn't attend field-specific conferences during my PhD; how much of a disadvantage is it?
Why has the UK chosen to use Huawei infrastructure when Five Eyes allies haven't?
I'm in your subnets, golfing your code
Will 700 more planes a day fly because of the Heathrow expansion?
What does this arrow symbol mean?
How can I support myself financially as a 17 year old with a loan?
Is there an official reason for not adding a post-credits scene?
What was the design of the Macintosh II's MMU replacement?
Do you know any research on finding closed forms of recursively-defined sequences?
Building a list of products from the elements in another list
What was Bran's plan to kill the Night King?
I need a disease
Why wasn't the Night King naked in S08E03?
Appropriate certificate to ask for a fibre installation (ANSI/TIA-568.3-D?)
Using column size much larger than necessary
Why does Professor Hulk wear glasses?
Would glacier 'trees' be plausible?
Validation rule Scheduled Apex
Which module had more 'comfort' in terms of living space, the Lunar Module or the Command module?
Nominativ or Akkusativ
Why do people keep telling me that I am a bad photographer?
How long would it take for people to notice a mass disappearance?
Why don't Unix/Linux systems traverse through directories until they find the required version of a linked library?
Confusion about linking boost library while compilationIs it possible to configure dynamic loader for an executableI am getting an error while loading shared libraries libXm.so.3Satisfying lib dependencyError while building snipersim: “relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC”How do I find the libraries this program needs for its environment variable?How to regain access to the lost user , linux3 , of two side by side Ubuntu 16.04 instances?Where do C# executables running on an Ubuntu Linux 16.04 desktop which use source code that DLLImport's shared objects look for them at runtime?Cannot find shared object file even though it's in library pathPlaced library in /usr/lib, but ldconfig doesn't put it in cache
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I have a binary executable named "alpha" that requires a linked library (libz.so.1.2.7) which is placed at /home/username/myproduct/lib/libz.so.1.2.7
I export the same to my terminal instance before spawning my binary executable by executing the following command.
export LD_LIBRARY_PATH=/home/username/myproduct/lib/:$LD_LIBRARY_PATH
Now, when I spawn another application "bravo" that requires the same library but of different version, i.e (libz.so.1.2.8) which is available in/lib/x86_64-linux-gnu/libz.so.1.2.8, system throws the following error.
version `ZLIB_1.2.3.3' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2)
If I unset the LD_LIBRARY_PATH, "bravo" starts up fine. I understand that the above behaviour is because LD_LIBRARY_PATH takes precedence over the directory paths defined in /etc/ld.so.conf while looking for linked libraries and consequently the above error occurred. I am just curious about why have not the developers of UNIX/LINUX designed the OS to search for linked libraries in other directories according to the hierarchy if the first instance of library is of different version.
Simply put, UNIX/LINUX systems traverse through a set of directories until it finds the required library. But why does it not do the same until it finds the expected version rather than accepting the first instance of library irrespective of its version?
libraries dynamic-linking shared-library ld
edited Apr 9 at 11:23
Stephen Kitt
184k26422501
asked Apr 9 at 6:48
daedalus_hamletdaedalus_hamlet
965
add a comment |
I have a binary executable named "alpha" that requires a linked library (libz.so.1.2.7) which is placed at /home/username/myproduct/lib/libz.so.1.2.7
I export the same to my terminal instance before spawning my binary executable by executing the following command.
export LD_LIBRARY_PATH=/home/username/myproduct/lib/:$LD_LIBRARY_PATH
Now, when I spawn another application "bravo" that requires the same library but of different version, i.e (libz.so.1.2.8) which is available in/lib/x86_64-linux-gnu/libz.so.1.2.8, system throws the following error.
version `ZLIB_1.2.3.3' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2)
If I unset the LD_LIBRARY_PATH, "bravo" starts up fine. I understand that the above behaviour is because LD_LIBRARY_PATH takes precedence over the directory paths defined in /etc/ld.so.conf while looking for linked libraries and consequently the above error occurred. I am just curious about why have not the developers of UNIX/LINUX designed the OS to search for linked libraries in other directories according to the hierarchy if the first instance of library is of different version.
Simply put, UNIX/LINUX systems traverse through a set of directories until it finds the required library. But why does it not do the same until it finds the expected version rather than accepting the first instance of library irrespective of its version?
libraries dynamic-linking shared-library ld
edited Apr 9 at 11:23
Stephen Kitt
184k26422501
asked Apr 9 at 6:48
daedalus_hamletdaedalus_hamlet
965
I'm not quite sure, but I'd guess for security. I personally would rather not have to worry about a sym-link anywhere on my machines
– Joe
Apr 9 at 7:08
@Joe Many of the libraries themselves have symlinks pointing to them.libz.so.1is a symlink tolibz.so.1.2.8
– Nasir Riley
Apr 9 at 7:24
add a comment |
I have a binary executable named "alpha" that requires a linked library (libz.so.1.2.7) which is placed at /home/username/myproduct/lib/libz.so.1.2.7
I export the same to my terminal instance before spawning my binary executable by executing the following command.
export LD_LIBRARY_PATH=/home/username/myproduct/lib/:$LD_LIBRARY_PATH
Now, when I spawn another application "bravo" that requires the same library but of different version, i.e (libz.so.1.2.8) which is available in/lib/x86_64-linux-gnu/libz.so.1.2.8, system throws the following error.
version `ZLIB_1.2.3.3' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2)
If I unset the LD_LIBRARY_PATH, "bravo" starts up fine. I understand that the above behaviour is because LD_LIBRARY_PATH takes precedence over the directory paths defined in /etc/ld.so.conf while looking for linked libraries and consequently the above error occurred. I am just curious about why have not the developers of UNIX/LINUX designed the OS to search for linked libraries in other directories according to the hierarchy if the first instance of library is of different version.
Simply put, UNIX/LINUX systems traverse through a set of directories until it finds the required library. But why does it not do the same until it finds the expected version rather than accepting the first instance of library irrespective of its version?
libraries dynamic-linking shared-library ld
edited Apr 9 at 11:23
Stephen Kitt
184k26422501
asked Apr 9 at 6:48
daedalus_hamletdaedalus_hamlet
965
I have a binary executable named "alpha" that requires a linked library (libz.so.1.2.7) which is placed at /home/username/myproduct/lib/libz.so.1.2.7
I export the same to my terminal instance before spawning my binary executable by executing the following command.
export LD_LIBRARY_PATH=/home/username/myproduct/lib/:$LD_LIBRARY_PATH
Now, when I spawn another application "bravo" that requires the same library but of different version, i.e (libz.so.1.2.8) which is available in/lib/x86_64-linux-gnu/libz.so.1.2.8, system throws the following error.
version `ZLIB_1.2.3.3' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2)
If I unset the LD_LIBRARY_PATH, "bravo" starts up fine. I understand that the above behaviour is because LD_LIBRARY_PATH takes precedence over the directory paths defined in /etc/ld.so.conf while looking for linked libraries and consequently the above error occurred. I am just curious about why have not the developers of UNIX/LINUX designed the OS to search for linked libraries in other directories according to the hierarchy if the first instance of library is of different version.
Simply put, UNIX/LINUX systems traverse through a set of directories until it finds the required library. But why does it not do the same until it finds the expected version rather than accepting the first instance of library irrespective of its version?
libraries dynamic-linking shared-library ld
libraries dynamic-linking shared-library ld
edited Apr 9 at 11:23
Stephen Kitt
184k26422501
asked Apr 9 at 6:48
daedalus_hamletdaedalus_hamlet
965
edited Apr 9 at 11:23
Stephen Kitt
184k26422501
asked Apr 9 at 6:48
daedalus_hamletdaedalus_hamlet
965
edited Apr 9 at 11:23
Stephen Kitt
184k26422501
edited Apr 9 at 11:23
Stephen Kitt
184k26422501
edited Apr 9 at 11:23
Stephen Kitt
184k26422501
184k26422501
asked Apr 9 at 6:48
daedalus_hamletdaedalus_hamlet
965
asked Apr 9 at 6:48
daedalus_hamletdaedalus_hamlet
965
asked Apr 9 at 6:48
daedalus_hamletdaedalus_hamlet
965
965
I'm not quite sure, but I'd guess for security. I personally would rather not have to worry about a sym-link anywhere on my machines
– Joe
Apr 9 at 7:08
@Joe Many of the libraries themselves have symlinks pointing to them.libz.so.1is a symlink tolibz.so.1.2.8
– Nasir Riley
Apr 9 at 7:24
add a comment |
I'm not quite sure, but I'd guess for security. I personally would rather not have to worry about a sym-link anywhere on my machines
– Joe
Apr 9 at 7:08
@Joe Many of the libraries themselves have symlinks pointing to them.libz.so.1is a symlink tolibz.so.1.2.8
– Nasir Riley
Apr 9 at 7:24
I'm not quite sure, but I'd guess for security. I personally would rather not have to worry about a sym-link anywhere on my machines
– Joe
Apr 9 at 7:08
I'm not quite sure, but I'd guess for security. I personally would rather not have to worry about a sym-link anywhere on my machines
– Joe
Apr 9 at 7:08
@Joe Many of the libraries themselves have symlinks pointing to them.
libz.so.1 is a symlink to libz.so.1.2.8– Nasir Riley
Apr 9 at 7:24
@Joe Many of the libraries themselves have symlinks pointing to them.
libz.so.1 is a symlink to libz.so.1.2.8– Nasir Riley
Apr 9 at 7:24
add a comment |
1 Answer
1
active
oldest
votes
But why does it not do the same until it finds the expected version rather than accepting the first instance of library irrespective of its version?
It does, as far as it’s aware. zlib.so.1.2.7 and zlib.so.1.2.8 both have an soname of zlib.so.1, so your alpha and bravo binaries say they need zlib.so.1. The dynamic loader loads the first matching library it finds; it doesn’t know that version 1.2.8 provides additional symbols which bravo needs. (This is why distributions take pains to specify additional dependency information, such as zlib1g (>= 1.2.8) for bravo.)
You might think this should be easy to fix, but it isn’t, not least because binaries and libraries list the symbols they need separately from the libraries they need, so the loader can’t check that a given library provides all the symbols that are needed from it. Symbols can be provided in a variety of ways, and introducing a link between symbols and the libraries providing them could break existing binaries. There’s also the added fun of symbol interposition to complicate things (and make security-sensitive developers tear their hair out).
Some libraries provide version information which ends up being stored in .gnu.version_r, with a link to the providing library, which would help here, but libz isn’t one of them.
(Given the sonames, I’d expect your alpha binary to work fine with zlib.so.1.2.8.)
answered Apr 9 at 7:17
Stephen KittStephen Kitt
184k26422501
And one should note as well that GNU-style library versioning is different from the semantic(-ish) versioning with which we are most accustomed. Since they have the same "current" number, 1, zlib.so.1.2.8 should not provide any features that zlib.so.1.2.7 does not, hence it ought not to matter (from an ABI perspective) which one is found. That it does matter should be considered a flaw.
– John Bollinger
Apr 9 at 15:40
4
@John no, the only guarantee is that libraries with the same soname are backwards-compatible; newer libraries can add features, they can’t remove any or change any in a backwards-incompatible fashion. That is to say, a binary built against zlib 1.2.7 will work with that or any newer zlib 1; but a binary built against zlib 1.2.8 won’t necessarily work with an older zlib 1. (And semantic versioning allows that; but soname handling isn’t semantic versioning.)
– Stephen Kitt
Apr 9 at 15:49
1
I'm talking specifically about GNU conventions, as I said, and I guess about libtool in particular. Not every project follows that convention, so perhaps it's too strong to call zlib flawed, but on the other hand, even a semantic-versioning interpretation of the library version numbers involved would come to the same conclusion. Forwards (binary) compatibility in such cases is not a promise inherent in the soname, but it is a reasonable expectation in this case.
– John Bollinger
Apr 9 at 16:01
1
Yes, I well understand the relationship between CRA numbers and SOVERSION, which comes back around to my original point: the situation described by the OP seems to be inconsistent with correct usage of the CRA scheme. Avoiding problems such as the OP's is one of the key objectives of that scheme. If zlib adds a new (version of a) binary interface, then its C number ought to be increased. That such a bump may lead to a soversion bump as well is secondary.
– John Bollinger
Apr 9 at 16:32
2
@John right, I suspect we’re in violent agreement and that I misunderstood the point you were making.zlibdoesn’t uselibtoolanyway, except on Darwin where it’sar;-).
– Stephen Kitt
Apr 9 at 16:38
|
show 2 more comments
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f511380%2fwhy-dont-unix-linux-systems-traverse-through-directories-until-they-find-the-re%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
But why does it not do the same until it finds the expected version rather than accepting the first instance of library irrespective of its version?
It does, as far as it’s aware. zlib.so.1.2.7 and zlib.so.1.2.8 both have an soname of zlib.so.1, so your alpha and bravo binaries say they need zlib.so.1. The dynamic loader loads the first matching library it finds; it doesn’t know that version 1.2.8 provides additional symbols which bravo needs. (This is why distributions take pains to specify additional dependency information, such as zlib1g (>= 1.2.8) for bravo.)
You might think this should be easy to fix, but it isn’t, not least because binaries and libraries list the symbols they need separately from the libraries they need, so the loader can’t check that a given library provides all the symbols that are needed from it. Symbols can be provided in a variety of ways, and introducing a link between symbols and the libraries providing them could break existing binaries. There’s also the added fun of symbol interposition to complicate things (and make security-sensitive developers tear their hair out).
Some libraries provide version information which ends up being stored in .gnu.version_r, with a link to the providing library, which would help here, but libz isn’t one of them.
(Given the sonames, I’d expect your alpha binary to work fine with zlib.so.1.2.8.)
answered Apr 9 at 7:17
Stephen KittStephen Kitt
184k26422501
And one should note as well that GNU-style library versioning is different from the semantic(-ish) versioning with which we are most accustomed. Since they have the same "current" number, 1, zlib.so.1.2.8 should not provide any features that zlib.so.1.2.7 does not, hence it ought not to matter (from an ABI perspective) which one is found. That it does matter should be considered a flaw.
– John Bollinger
Apr 9 at 15:40
4
@John no, the only guarantee is that libraries with the same soname are backwards-compatible; newer libraries can add features, they can’t remove any or change any in a backwards-incompatible fashion. That is to say, a binary built against zlib 1.2.7 will work with that or any newer zlib 1; but a binary built against zlib 1.2.8 won’t necessarily work with an older zlib 1. (And semantic versioning allows that; but soname handling isn’t semantic versioning.)
– Stephen Kitt
Apr 9 at 15:49
1
I'm talking specifically about GNU conventions, as I said, and I guess about libtool in particular. Not every project follows that convention, so perhaps it's too strong to call zlib flawed, but on the other hand, even a semantic-versioning interpretation of the library version numbers involved would come to the same conclusion. Forwards (binary) compatibility in such cases is not a promise inherent in the soname, but it is a reasonable expectation in this case.
– John Bollinger
Apr 9 at 16:01
1
Yes, I well understand the relationship between CRA numbers and SOVERSION, which comes back around to my original point: the situation described by the OP seems to be inconsistent with correct usage of the CRA scheme. Avoiding problems such as the OP's is one of the key objectives of that scheme. If zlib adds a new (version of a) binary interface, then its C number ought to be increased. That such a bump may lead to a soversion bump as well is secondary.
– John Bollinger
Apr 9 at 16:32
2
@John right, I suspect we’re in violent agreement and that I misunderstood the point you were making.zlibdoesn’t uselibtoolanyway, except on Darwin where it’sar;-).
– Stephen Kitt
Apr 9 at 16:38
|
show 2 more comments
But why does it not do the same until it finds the expected version rather than accepting the first instance of library irrespective of its version?
It does, as far as it’s aware. zlib.so.1.2.7 and zlib.so.1.2.8 both have an soname of zlib.so.1, so your alpha and bravo binaries say they need zlib.so.1. The dynamic loader loads the first matching library it finds; it doesn’t know that version 1.2.8 provides additional symbols which bravo needs. (This is why distributions take pains to specify additional dependency information, such as zlib1g (>= 1.2.8) for bravo.)
You might think this should be easy to fix, but it isn’t, not least because binaries and libraries list the symbols they need separately from the libraries they need, so the loader can’t check that a given library provides all the symbols that are needed from it. Symbols can be provided in a variety of ways, and introducing a link between symbols and the libraries providing them could break existing binaries. There’s also the added fun of symbol interposition to complicate things (and make security-sensitive developers tear their hair out).
Some libraries provide version information which ends up being stored in .gnu.version_r, with a link to the providing library, which would help here, but libz isn’t one of them.
(Given the sonames, I’d expect your alpha binary to work fine with zlib.so.1.2.8.)
answered Apr 9 at 7:17
Stephen KittStephen Kitt
184k26422501
And one should note as well that GNU-style library versioning is different from the semantic(-ish) versioning with which we are most accustomed. Since they have the same "current" number, 1, zlib.so.1.2.8 should not provide any features that zlib.so.1.2.7 does not, hence it ought not to matter (from an ABI perspective) which one is found. That it does matter should be considered a flaw.
– John Bollinger
Apr 9 at 15:40
4
@John no, the only guarantee is that libraries with the same soname are backwards-compatible; newer libraries can add features, they can’t remove any or change any in a backwards-incompatible fashion. That is to say, a binary built against zlib 1.2.7 will work with that or any newer zlib 1; but a binary built against zlib 1.2.8 won’t necessarily work with an older zlib 1. (And semantic versioning allows that; but soname handling isn’t semantic versioning.)
– Stephen Kitt
Apr 9 at 15:49
1
I'm talking specifically about GNU conventions, as I said, and I guess about libtool in particular. Not every project follows that convention, so perhaps it's too strong to call zlib flawed, but on the other hand, even a semantic-versioning interpretation of the library version numbers involved would come to the same conclusion. Forwards (binary) compatibility in such cases is not a promise inherent in the soname, but it is a reasonable expectation in this case.
– John Bollinger
Apr 9 at 16:01
1
Yes, I well understand the relationship between CRA numbers and SOVERSION, which comes back around to my original point: the situation described by the OP seems to be inconsistent with correct usage of the CRA scheme. Avoiding problems such as the OP's is one of the key objectives of that scheme. If zlib adds a new (version of a) binary interface, then its C number ought to be increased. That such a bump may lead to a soversion bump as well is secondary.
– John Bollinger
Apr 9 at 16:32
2
@John right, I suspect we’re in violent agreement and that I misunderstood the point you were making.zlibdoesn’t uselibtoolanyway, except on Darwin where it’sar;-).
– Stephen Kitt
Apr 9 at 16:38
|
show 2 more comments
But why does it not do the same until it finds the expected version rather than accepting the first instance of library irrespective of its version?
It does, as far as it’s aware. zlib.so.1.2.7 and zlib.so.1.2.8 both have an soname of zlib.so.1, so your alpha and bravo binaries say they need zlib.so.1. The dynamic loader loads the first matching library it finds; it doesn’t know that version 1.2.8 provides additional symbols which bravo needs. (This is why distributions take pains to specify additional dependency information, such as zlib1g (>= 1.2.8) for bravo.)
You might think this should be easy to fix, but it isn’t, not least because binaries and libraries list the symbols they need separately from the libraries they need, so the loader can’t check that a given library provides all the symbols that are needed from it. Symbols can be provided in a variety of ways, and introducing a link between symbols and the libraries providing them could break existing binaries. There’s also the added fun of symbol interposition to complicate things (and make security-sensitive developers tear their hair out).
Some libraries provide version information which ends up being stored in .gnu.version_r, with a link to the providing library, which would help here, but libz isn’t one of them.
(Given the sonames, I’d expect your alpha binary to work fine with zlib.so.1.2.8.)
answered Apr 9 at 7:17
Stephen KittStephen Kitt
184k26422501
But why does it not do the same until it finds the expected version rather than accepting the first instance of library irrespective of its version?
It does, as far as it’s aware. zlib.so.1.2.7 and zlib.so.1.2.8 both have an soname of zlib.so.1, so your alpha and bravo binaries say they need zlib.so.1. The dynamic loader loads the first matching library it finds; it doesn’t know that version 1.2.8 provides additional symbols which bravo needs. (This is why distributions take pains to specify additional dependency information, such as zlib1g (>= 1.2.8) for bravo.)
You might think this should be easy to fix, but it isn’t, not least because binaries and libraries list the symbols they need separately from the libraries they need, so the loader can’t check that a given library provides all the symbols that are needed from it. Symbols can be provided in a variety of ways, and introducing a link between symbols and the libraries providing them could break existing binaries. There’s also the added fun of symbol interposition to complicate things (and make security-sensitive developers tear their hair out).
Some libraries provide version information which ends up being stored in .gnu.version_r, with a link to the providing library, which would help here, but libz isn’t one of them.
(Given the sonames, I’d expect your alpha binary to work fine with zlib.so.1.2.8.)
answered Apr 9 at 7:17
Stephen KittStephen Kitt
184k26422501
edited Apr 9 at 7:23
answered Apr 9 at 7:17
Stephen KittStephen Kitt
184k26422501
answered Apr 9 at 7:17
Stephen KittStephen Kitt
184k26422501
answered Apr 9 at 7:17
Stephen KittStephen Kitt
184k26422501
184k26422501
And one should note as well that GNU-style library versioning is different from the semantic(-ish) versioning with which we are most accustomed. Since they have the same "current" number, 1, zlib.so.1.2.8 should not provide any features that zlib.so.1.2.7 does not, hence it ought not to matter (from an ABI perspective) which one is found. That it does matter should be considered a flaw.
– John Bollinger
Apr 9 at 15:40
4
@John no, the only guarantee is that libraries with the same soname are backwards-compatible; newer libraries can add features, they can’t remove any or change any in a backwards-incompatible fashion. That is to say, a binary built against zlib 1.2.7 will work with that or any newer zlib 1; but a binary built against zlib 1.2.8 won’t necessarily work with an older zlib 1. (And semantic versioning allows that; but soname handling isn’t semantic versioning.)
– Stephen Kitt
Apr 9 at 15:49
1
I'm talking specifically about GNU conventions, as I said, and I guess about libtool in particular. Not every project follows that convention, so perhaps it's too strong to call zlib flawed, but on the other hand, even a semantic-versioning interpretation of the library version numbers involved would come to the same conclusion. Forwards (binary) compatibility in such cases is not a promise inherent in the soname, but it is a reasonable expectation in this case.
– John Bollinger
Apr 9 at 16:01
1
Yes, I well understand the relationship between CRA numbers and SOVERSION, which comes back around to my original point: the situation described by the OP seems to be inconsistent with correct usage of the CRA scheme. Avoiding problems such as the OP's is one of the key objectives of that scheme. If zlib adds a new (version of a) binary interface, then its C number ought to be increased. That such a bump may lead to a soversion bump as well is secondary.
– John Bollinger
Apr 9 at 16:32
2
@John right, I suspect we’re in violent agreement and that I misunderstood the point you were making.zlibdoesn’t uselibtoolanyway, except on Darwin where it’sar;-).
– Stephen Kitt
Apr 9 at 16:38
|
show 2 more comments
And one should note as well that GNU-style library versioning is different from the semantic(-ish) versioning with which we are most accustomed. Since they have the same "current" number, 1, zlib.so.1.2.8 should not provide any features that zlib.so.1.2.7 does not, hence it ought not to matter (from an ABI perspective) which one is found. That it does matter should be considered a flaw.
– John Bollinger
Apr 9 at 15:40
4
@John no, the only guarantee is that libraries with the same soname are backwards-compatible; newer libraries can add features, they can’t remove any or change any in a backwards-incompatible fashion. That is to say, a binary built against zlib 1.2.7 will work with that or any newer zlib 1; but a binary built against zlib 1.2.8 won’t necessarily work with an older zlib 1. (And semantic versioning allows that; but soname handling isn’t semantic versioning.)
– Stephen Kitt
Apr 9 at 15:49
1
I'm talking specifically about GNU conventions, as I said, and I guess about libtool in particular. Not every project follows that convention, so perhaps it's too strong to call zlib flawed, but on the other hand, even a semantic-versioning interpretation of the library version numbers involved would come to the same conclusion. Forwards (binary) compatibility in such cases is not a promise inherent in the soname, but it is a reasonable expectation in this case.
– John Bollinger
Apr 9 at 16:01
1
Yes, I well understand the relationship between CRA numbers and SOVERSION, which comes back around to my original point: the situation described by the OP seems to be inconsistent with correct usage of the CRA scheme. Avoiding problems such as the OP's is one of the key objectives of that scheme. If zlib adds a new (version of a) binary interface, then its C number ought to be increased. That such a bump may lead to a soversion bump as well is secondary.
– John Bollinger
Apr 9 at 16:32
2
@John right, I suspect we’re in violent agreement and that I misunderstood the point you were making.zlibdoesn’t uselibtoolanyway, except on Darwin where it’sar;-).
– Stephen Kitt
Apr 9 at 16:38
And one should note as well that GNU-style library versioning is different from the semantic(-ish) versioning with which we are most accustomed. Since they have the same "current" number, 1, zlib.so.1.2.8 should not provide any features that zlib.so.1.2.7 does not, hence it ought not to matter (from an ABI perspective) which one is found. That it does matter should be considered a flaw.
– John Bollinger
Apr 9 at 15:40
And one should note as well that GNU-style library versioning is different from the semantic(-ish) versioning with which we are most accustomed. Since they have the same "current" number, 1, zlib.so.1.2.8 should not provide any features that zlib.so.1.2.7 does not, hence it ought not to matter (from an ABI perspective) which one is found. That it does matter should be considered a flaw.
– John Bollinger
Apr 9 at 15:40
4
4
@John no, the only guarantee is that libraries with the same soname are backwards-compatible; newer libraries can add features, they can’t remove any or change any in a backwards-incompatible fashion. That is to say, a binary built against zlib 1.2.7 will work with that or any newer zlib 1; but a binary built against zlib 1.2.8 won’t necessarily work with an older zlib 1. (And semantic versioning allows that; but soname handling isn’t semantic versioning.)
– Stephen Kitt
Apr 9 at 15:49
@John no, the only guarantee is that libraries with the same soname are backwards-compatible; newer libraries can add features, they can’t remove any or change any in a backwards-incompatible fashion. That is to say, a binary built against zlib 1.2.7 will work with that or any newer zlib 1; but a binary built against zlib 1.2.8 won’t necessarily work with an older zlib 1. (And semantic versioning allows that; but soname handling isn’t semantic versioning.)
– Stephen Kitt
Apr 9 at 15:49
1
1
I'm talking specifically about GNU conventions, as I said, and I guess about libtool in particular. Not every project follows that convention, so perhaps it's too strong to call zlib flawed, but on the other hand, even a semantic-versioning interpretation of the library version numbers involved would come to the same conclusion. Forwards (binary) compatibility in such cases is not a promise inherent in the soname, but it is a reasonable expectation in this case.
– John Bollinger
Apr 9 at 16:01
I'm talking specifically about GNU conventions, as I said, and I guess about libtool in particular. Not every project follows that convention, so perhaps it's too strong to call zlib flawed, but on the other hand, even a semantic-versioning interpretation of the library version numbers involved would come to the same conclusion. Forwards (binary) compatibility in such cases is not a promise inherent in the soname, but it is a reasonable expectation in this case.
– John Bollinger
Apr 9 at 16:01
1
1
Yes, I well understand the relationship between CRA numbers and SOVERSION, which comes back around to my original point: the situation described by the OP seems to be inconsistent with correct usage of the CRA scheme. Avoiding problems such as the OP's is one of the key objectives of that scheme. If zlib adds a new (version of a) binary interface, then its C number ought to be increased. That such a bump may lead to a soversion bump as well is secondary.
– John Bollinger
Apr 9 at 16:32
Yes, I well understand the relationship between CRA numbers and SOVERSION, which comes back around to my original point: the situation described by the OP seems to be inconsistent with correct usage of the CRA scheme. Avoiding problems such as the OP's is one of the key objectives of that scheme. If zlib adds a new (version of a) binary interface, then its C number ought to be increased. That such a bump may lead to a soversion bump as well is secondary.
– John Bollinger
Apr 9 at 16:32
2
2
@John right, I suspect we’re in violent agreement and that I misunderstood the point you were making.
zlib doesn’t use libtool anyway, except on Darwin where it’s ar ;-).– Stephen Kitt
Apr 9 at 16:38
@John right, I suspect we’re in violent agreement and that I misunderstood the point you were making.
zlib doesn’t use libtool anyway, except on Darwin where it’s ar ;-).– Stephen Kitt
Apr 9 at 16:38
|
show 2 more comments
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f511380%2fwhy-dont-unix-linux-systems-traverse-through-directories-until-they-find-the-re%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I'm not quite sure, but I'd guess for security. I personally would rather not have to worry about a sym-link anywhere on my machines
– Joe
Apr 9 at 7:08
@Joe Many of the libraries themselves have symlinks pointing to them.
libz.so.1is a symlink tolibz.so.1.2.8– Nasir Riley
Apr 9 at 7:24