setting LIBDIR_IN_LDCONFIG fails if /lib is a symlink to /usr/lib

setting LIBDIR_IN_LDCONFIG fails if /lib is a symlink to /usr/lib

[David Bremner]

On my laptop, /lib is a symlink to to /usr/lib (this might or might not
be a good idea, but is likely to become increasingly common if some
people get their way).

$ /sbin/ldconfig -NX -v | grep -v ^$'\t'

yields

        /sbin/ldconfig: Can't stat /usr/local/lib/x86_64-linux-gnu: No such file or directory
        /sbin/ldconfig: Path `/usr/lib/x86_64-linux-gnu' given more than once
        /sbin/ldconfig: Path `/lib/x86_64-linux-gnu' given more than once
        /sbin/ldconfig: Path `/usr/lib/x86_64-linux-gnu' given more than once
        /sbin/ldconfig: Path `/usr/lib' given more than once
        /usr/lib/x86_64-linux-gnu/libfakeroot:
        /usr/local/lib:
        /lib/x86_64-linux-gnu:
        /sbin/ldconfig: /lib/x86_64-linux-gnu/ld-2.27.so is the dynamic linker, ignoring

        /lib:

with libdir=/usr/lib/x86_64-linux-gnu, our sed hackery fails, since the
directory we are looking for never appears at the beggining of a
line.

One option is to do more proccesing of the output and look for the path
in "given more than once" lines as well. Still, this is an obviously
fragile way of doing things (parsing human readable output from
ldconfig), so I wondered if anyone has some better ideas.

This informattion is used two places

1) to avoid adding an unecessary RPATH to the binary. Having such an RPATH will
cause at least Debian (and I suppose other distro) tooling to complain
loudly.

2) To know whether to run ldconfig after installing the library.

Re: setting LIBDIR_IN_LDCONFIG fails if /lib is a symlink to /usr/lib

[Tomi Ollila]

On Sat, May 26 2018, David Bremner wrote:

> On my laptop, /lib is a symlink to to /usr/lib (this might or might not
> be a good idea, but is likely to become increasingly common if some
> people get their way).
>
> $ /sbin/ldconfig -NX -v | grep -v ^$'\t'
>
> yields
>
>         /sbin/ldconfig: Can't stat /usr/local/lib/x86_64-linux-gnu: No such file or directory
>         /sbin/ldconfig: Path `/usr/lib/x86_64-linux-gnu' given more than once
>         /sbin/ldconfig: Path `/lib/x86_64-linux-gnu' given more than once
>         /sbin/ldconfig: Path `/usr/lib/x86_64-linux-gnu' given more than once
>         /sbin/ldconfig: Path `/usr/lib' given more than once
>         /usr/lib/x86_64-linux-gnu/libfakeroot:
>         /usr/local/lib:
>         /lib/x86_64-linux-gnu:
>         /sbin/ldconfig: /lib/x86_64-linux-gnu/ld-2.27.so is the dynamic linker, ignoring
>
>         /lib:
>
> with libdir=/usr/lib/x86_64-linux-gnu, our sed hackery fails, since the
> directory we are looking for never appears at the beggining of a
> line.
>
> One option is to do more proccesing of the output and look for the path
> in "given more than once" lines as well. Still, this is an obviously
> fragile way of doing things (parsing human readable output from
> ldconfig), so I wondered if anyone has some better ideas.

we could try:

    for path in $ldconfig_paths; do
        if [ "$path" = "$libdir_expanded" ]; then
            libdir_in_ldconfig=1
            break
        fi
        if [ "$path" -ef "$libdir_expanded" ]; then
            libdir_in_ldconfig=1
            break
        fi
    done

>
> This informattion is used two places
>
> 1) to avoid adding an unecessary RPATH to the binary. Having such an RPATH will
> cause at least Debian (and I suppose other distro) tooling to complain
> loudly.
>
> 2) To know whether to run ldconfig after installing the library.

Re: setting LIBDIR_IN_LDCONFIG fails if /lib is a symlink to /usr/lib

[David Bremner]

Tomi Ollila <tomi.ollila@iki.fi> writes:

> we could try:
>
>     for path in $ldconfig_paths; do
>         if [ "$path" = "$libdir_expanded" ]; then
>             libdir_in_ldconfig=1
>             break
>         fi
>         if [ "$path" -ef "$libdir_expanded" ]; then
>             libdir_in_ldconfig=1
>             break
>         fi
>     done
>

That looks less horrible than my idea. How portable is it? I guess test
-ef is not POSIX.

d

Re: setting LIBDIR_IN_LDCONFIG fails if /lib is a symlink to /usr/lib

[Tomi Ollila]

On Sun, May 27 2018, David Bremner wrote:

> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> we could try:
>>
>>     for path in $ldconfig_paths; do
>>         if [ "$path" = "$libdir_expanded" ]; then
>>             libdir_in_ldconfig=1
>>             break
>>         fi
>>         if [ "$path" -ef "$libdir_expanded" ]; then
>>             libdir_in_ldconfig=1
>>             break
>>         fi
>>     done
>>
>
> That looks less horrible than my idea. How portable is it? I guess test
> -ef is not POSIX.

-ef is not POSIX; but probably all shells that are used when executing this
line have builtin test which groks -ef .

  $ dash -c 'test / -ef /' || echo noef
  $ bash -c 'test / -ef /' || echo noef
  $ zsh -c 'test / -ef /' || echo noef
  $ ksh -c 'test / -ef /' || echo noef

but, problem arises when test does not support -ef -- script may exit
prematurely...

  $ ./heirloom-sh/sh -c 'if test / -ef /; then echo foo; else echo bar; fi'
  ./heirloom-sh/sh: test: unknown operator -ef
  zsh: exit 1     ./heirloom-sh/sh -c 'if test / -ef /; then echo foo; ...

OTOH:

  $ dash -c 'if test / -exf /; then echo foo; else echo bar; fi'    /home/too
  test: 1: /: unexpected operator
  bar

... so probably the shells that can succesfully execute our configure 
scripts (heirloom sh definitely will not) will not fail if, for some
reason it could not handle the -ef -option -- that particular test
just would not ever pass.

Tomi

PS: the test/[ problems that had to be mitigated with [ x"$var" = x ]
has been fixed decades ago -- but still we se these in modern scripts
that require bash...

>
> d

[PATCH] configure: check for links to/from libdir in ldconfig output

[David Bremner]

If e.g. /lib is a link to /usr/lib, then the latter may not show up in
the way we expect in the output of ldconfig. 'test foo -ef bar' checks
if foo and bar have the same device and inode numbers. Since (at least
in bash, ksh, and zsh) the shell dereferences symlinks before applying
the test, this includes both the case where file1 is equal to file2
and the case where one is a symlink to the other.
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 3cefdcc6..ab7e1610 100755
--- a/configure
+++ b/configure
@@ -715,7 +715,7 @@ elif [ $uname = "Linux" ] || [ $uname = "GNU" ] ; then
     IFS="
 "
     for path in $ldconfig_paths; do
-	if [ "$path" = "$libdir_expanded" ]; then
+	if [ "$path" -ef "$libdir_expanded" ]; then
 	    libdir_in_ldconfig=1
 	fi
     done
-- 
2.17.0

Re: [PATCH] configure: check for links to/from libdir in ldconfig output

[Tomi Ollila]

On Tue, May 29 2018, David Bremner wrote:

> If e.g. /lib is a link to /usr/lib, then the latter may not show up in
> the way we expect in the output of ldconfig. 'test foo -ef bar' checks
> if foo and bar have the same device and inode numbers. Since (at least
> in bash, ksh, and zsh) the shell dereferences symlinks before applying

i think you have to add 'dash' to this list in this commit message, as it
is default /bin/sh in debian (and many debian-derived distributions);
that is quite common configuration there when the test line in question
is executed

dash and bash are most relevant, ksh, zsh (and at least some versions of
busybox sh ;) are just emphasizing the fact...

Tomi

> the test, this includes both the case where file1 is equal to file2
> and the case where one is a symlink to the other.
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 3cefdcc6..ab7e1610 100755
> --- a/configure
> +++ b/configure
> @@ -715,7 +715,7 @@ elif [ $uname = "Linux" ] || [ $uname = "GNU" ] ; then
>      IFS="
>  "
>      for path in $ldconfig_paths; do
> -	if [ "$path" = "$libdir_expanded" ]; then
> +	if [ "$path" -ef "$libdir_expanded" ]; then
>  	    libdir_in_ldconfig=1
>  	fi
>      done
> -- 
> 2.17.0

Re: [PATCH] configure: check for links to/from libdir in ldconfig output

[David Bremner]

Tomi Ollila <tomi.ollila@iki.fi> writes:

> On Tue, May 29 2018, David Bremner wrote:
>
>> If e.g. /lib is a link to /usr/lib, then the latter may not show up in
>> the way we expect in the output of ldconfig. 'test foo -ef bar' checks
>> if foo and bar have the same device and inode numbers. Since (at least
>> in bash, ksh, and zsh) the shell dereferences symlinks before applying
>
> i think you have to add 'dash' to this list in this commit message, as it
> is default /bin/sh in debian (and many debian-derived distributions);
> that is quite common configuration there when the test line in question
> is executed

That's right. I even tested dash, _after_ I sent the patch :P 

What do you think about the risk/benefit of including this in 0.27? I
guess we have lived with this bug for a long time.

d

Re: [PATCH] configure: check for links to/from libdir in ldconfig output

[Tomi Ollila]

On Wed, May 30 2018, David Bremner wrote:

> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> On Tue, May 29 2018, David Bremner wrote:
>>
>>> If e.g. /lib is a link to /usr/lib, then the latter may not show up in
>>> the way we expect in the output of ldconfig. 'test foo -ef bar' checks
>>> if foo and bar have the same device and inode numbers. Since (at least
>>> in bash, ksh, and zsh) the shell dereferences symlinks before applying
>>
>> i think you have to add 'dash' to this list in this commit message, as it
>> is default /bin/sh in debian (and many debian-derived distributions);
>> that is quite common configuration there when the test line in question
>> is executed
>
> That's right. I even tested dash, _after_ I sent the patch :P 
>
> What do you think about the risk/benefit of including this in 0.27? I
> guess we have lived with this bug for a long time.

+1 for inclusion. that's how we get testers >:)

>
> d

Re: [PATCH] configure: check for links to/from libdir in ldconfig output

[David Bremner]

Tomi Ollila <tomi.ollila@iki.fi> writes:

> On Wed, May 30 2018, David Bremner wrote:
>
>> Tomi Ollila <tomi.ollila@iki.fi> writes:
>>
>>> On Tue, May 29 2018, David Bremner wrote:
>>>
>>>> If e.g. /lib is a link to /usr/lib, then the latter may not show up in
>>>> the way we expect in the output of ldconfig. 'test foo -ef bar' checks
>>>> if foo and bar have the same device and inode numbers. Since (at least
>>>> in bash, ksh, and zsh) the shell dereferences symlinks before applying
>>>
>>> i think you have to add 'dash' to this list in this commit message, as it
>>> is default /bin/sh in debian (and many debian-derived distributions);
>>> that is quite common configuration there when the test line in question
>>> is executed
>>
>> That's right. I even tested dash, _after_ I sent the patch :P 
>>
>> What do you think about the risk/benefit of including this in 0.27? I
>> guess we have lived with this bug for a long time.
>
> +1 for inclusion. that's how we get testers >:)

Pushed as part of 0.27_rc1

d