bug#19893: GNU libtool-2.4.6 released [stable]

[Michael Felt]

OK - it took awhile to understand this test - and I think it does indicate a bug.

If I understand the test it is expecting the directory addrunpath=`pwd`/foobar to be added to the .la file (and now I understand the name of the test :)) -- tests/runpath-in-lalib.at

I expect this is to 'happen' with this statement

AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la a.lo -rpath $libdir -R$addrunpath],
         [], [ignore], [ignore])

At the end of the test - this is the contents of the .la files regarding libraries:
address@hidden:[/data/prj/gnu/libtool/libtool-2.4.6/tests/testsuite.dir/070]tail -3 liba.la

# Directory that this library needs to be installed in:
libdir='/data/prj/gnu/libtool/libtool-2.4.6/tests/testsuite.dir/070/inst/lib'

address@hidden:[/data/prj/gnu/libtool/libtool-2.4.6/tests/testsuite.dir/070]tail -3 libb.la
# Directory that this library needs to be installed in:
libdir='/data/prj/gnu/libtool/libtool-2.4.6/tests/testsuite.dir/070/inst/lib'
relink_command="(cd /data/prj/gnu/libtool/libtool-2.4.6/tests/testsuite.dir/070; /bin/sh \"/data/prj/gnu/libtool/libtool-2.4.6/libtool\"  --mode=relink cc -O2 -qlanglvl=extc99 -o libb.la b.lo -rpath /data/prj/gnu/libtool/libtool-2.4.6/tests/testsuite.dir/070/inst/lib liba.la @inst_prefix_dir@)"

Looking at the .so.0 files though...

address@hidden:[/data/prj/gnu/libtool/libtool-2.4.6/tests/testsuite.dir/070]dump -H .libs/liba.so.0 | tail -3
                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER             
0      /data/prj/gnu/libtool/libtool-2.4.6/tests/testsuite.dir/070/foobar:/usr/vac/lib:/usr/lib:/lib

address@hidden:[/data/prj/gnu/libtool/libtool-2.4.6/tests/testsuite.dir/070]dump -H .libs/libb.so.0 | tail -4
                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER             
0      /data/prj/gnu/libtool/libtool-2.4.6/tests/testsuite.dir/070/inst/lib:/usr/vac/lib:/usr/lib:/lib                                        
1                                    liba.a              liba.so.0          

We see that .../foobar has been added to the internal LIBPATH variable.

I am a bit surprised by this because -R is suppossed to be a NULL op unless the -bsvr4 flag is also specified - maybe that is also heppening in the background - will look more carefully for that.

In any case, .../foobar is getting added to the shared object, but not the .la text.

I have no clue where to look beyond this - hints/patch is welcome!

Michael

On Thu, Feb 19, 2015 at 7:09 PM, Michael Felt <address@hidden> wrote:

thanks.

On Feb 18, 2015 3:46 PM, "Nick Bowler" <address@hidden> wrote:

Hi,

I don't know about the specific failure but I can answer your
questions...

On 2015-02-18 09:18 +0100, Michael Felt wrote:
> Test 70, e.g., proceeds fine but at line 61 - it fails
[...]
> in the test file runpath-in-lalib.at
>
>    +61  AT_CHECK([$GREP /foobar $libdir/liba.la], [], [ignore])
>    +62  AT_CHECK([$GREP /foobar $libdir/libb.la], [], [ignore])
>    +63
>    +64  # TODO: check that m gets -R, too.
>    +65
>    +66  AT_CLEANUP
[...]
> Two questions:
>
> 1. the word [ignore] at the end does not mean to ignore exit status - I am
> guessing. So what does it mean?

It means to ignore the standard output of the command (not completely;
it is still recorded in the testsuite log file).

> 2. How can I easily run a (verbose) single-test (and maybe have it echo the
> values of things like $GREP)

You can pass flags to the testsuite by setting TESTSUITEFLAGS, e.g.,

  make check TESTSUITEFLAGS='70'

to run just test 70.  See ./tests/testsuite --help for more testsuite
options; perhaps --trace will be helpful for you.

Regards,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)