What documentation says:
"$ORIGIN sequences within a DT_NEEDED entry or path passed as a parameter to dlopen() are treated as errors."
(From "System V Application Binary Interface - DRAFT - 10 June 2013" / "Chapter 5 - Program Loading and Dynamic Linking" / "Dynamic Linking" / "Shared Object Dependencies" / "Substitution Sequences" <http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#substitution>.)
What in reality happens:
- Having $ORIGIN string within DT_NEEDED section with shared library that DOES NOT uses versioning, causes '$ORIGIN' to be interpreted as path-to-directory-where-binary-is-located (despite, per documentation, it should/must be treated as error).
- Having $ORIGIN string within DT_NEEDED section with shared library that USES versioning, causes assertion failure (see below) or segmentation fault (not on my system) (however, it doesn't look like intentional/graceful message related to explicitly documented case of ORIGIN within DT_NEEDED — it more looks like that ld.so was put into unexpected state).
On my system, having $ORIGIN within DT_NEEDED together with versioning causes the following output: "Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != NULL' failed!". Some other people say they observe segmentation fault instead. I used the attached script test-origin-in-needed.sh to test behavior.
I'd better report the bug to libc maintainers (upstream). Because it seems to be upstream-related specification violation. But the libc bug reporting policy says: "Distributions may include their own modifications to glibc in the binaries and sources you get with the operating system. If the glibc you are using comes from a complete operating system distribution, you should report bugs to that distribution project first." So, I report here first.
3) I expected handling of $ORIGIN strings within DT_NEEDED sections to be conforming "System V Application Binary Interface". Or, at least, to see non-conforming parts explicitly documented somewhere in GNU documentation.
4) See above. Having $ORIGIN string within DT_NEEDED section without versioning causes $ORIGIN to work as if it's within (for example) RPATH section — violates documentation. Having $ORIGIN string within DT_NEEDED section with versioning causes assertion failure (formally doesn't violate documentation, but really it looks more like unexpected state than graceful condition handling). I used attached script to test.
What documentation says: www.sco. com/developers/ gabi/latest/ ch5.dynamic. html#substituti on>.)
"$ORIGIN sequences within a DT_NEEDED entry or path passed as a parameter to dlopen() are treated as errors."
(From "System V Application Binary Interface - DRAFT - 10 June 2013" / "Chapter 5 - Program Loading and Dynamic Linking" / "Dynamic Linking" / "Shared Object Dependencies" / "Substitution Sequences" <http://
What in reality happens: directory- where-binary- is-located (despite, per documentation, it should/must be treated as error). graceful message related to explicitly documented case of ORIGIN within DT_NEEDED — it more looks like that ld.so was put into unexpected state).
- Having $ORIGIN string within DT_NEEDED section with shared library that DOES NOT uses versioning, causes '$ORIGIN' to be interpreted as path-to-
- Having $ORIGIN string within DT_NEEDED section with shared library that USES versioning, causes assertion failure (see below) or segmentation fault (not on my system) (however, it doesn't look like intentional/
On my system, having $ORIGIN within DT_NEEDED together with versioning causes the following output: "Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_ map_versions: Assertion `needed != NULL' failed!". Some other people say they observe segmentation fault instead. I used the attached script test-origin- in-needed. sh to test behavior.
I'd better report the bug to libc maintainers (upstream). Because it seems to be upstream-related specification violation. But the libc bug reporting policy says: "Distributions may include their own modifications to glibc in the binaries and sources you get with the operating system. If the glibc you are using comes from a complete operating system distribution, you should report bugs to that distribution project first." So, I report here first.
1) lsb_release -rd
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2) pt-cache policy libc6 ua.archive. ubuntu. com/ubuntu xenial-updates/main amd64 Packages dpkg/status ua.archive. ubuntu. com/ubuntu xenial/main amd64 Packages
libc6:
Installed: 2.23-0ubuntu4
Candidate: 2.23-0ubuntu4
Version table:
*** 2.23-0ubuntu4 500
500 http://
100 /var/lib/
2.23-0ubuntu3 500
500 http://
3) I expected handling of $ORIGIN strings within DT_NEEDED sections to be conforming "System V Application Binary Interface". Or, at least, to see non-conforming parts explicitly documented somewhere in GNU documentation.
4) See above. Having $ORIGIN string within DT_NEEDED section without versioning causes $ORIGIN to work as if it's within (for example) RPATH section — violates documentation. Having $ORIGIN string within DT_NEEDED section with versioning causes assertion failure (formally doesn't violate documentation, but really it looks more like unexpected state than graceful condition handling). I used attached script to test.