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:
root@x064:[/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'

root@x064:[/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...

root@x064:[/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


root@x064:[/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 <aixtools@gmail.com> wrote:

> thanks.
> On Feb 18, 2015 3:46 PM, "Nick Bowler" <nbowler@elliptictech.com> 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/)
>>
>