Re: Do convenience libraries propagate -R linker flags?

[Rhys Ulerich]

Hi Ralf,

>> I've got a convenience library where the LDFLAGS includes -R:
>>     noinst_LTLIBRARIES = libsomething.la
>>     ...
>>     libsomething_la_LDFLAGS = -Rsomewhere
>> and I indeed see "-Rsomewhere" appear within libsomething.la's 
>> dependency_libs
>> line the way I expect.
>>
>> In another directory, I build a program depending on libsomething.la
>>     bin_PROGRAMS = myprog
>>     myprog_LDADD = ../lib/libsomething.la
>> and then issue 'make install' to install it.
>>
>> After installation, I'm not seeing '-Rsomething' appear within the installed
>> binary's rpath according to 'readelf -d myprog'. 'ldd myprog' issued after
>> emptying my LD_LIBRARY_PATH confirms that -Rsomething isn't present.
>>
>> Should I expect -R flags provided at convenience library creation time to be
>> propagated to an installed binary which uses that convenience library?

> I think they are not propagated currently for convenience archives.  As
> to whether they should, I'm not sure.  I remember that this has been
> reported before.  I also remember that the issue has not been entirely
> noncontroversial.
>
> Somebody would have to dig in mailing list and commit history (of the
> Libtool project) to find out for sure.

Thanks for the quick response.  Took me a little time to do the digging...

This same issue was reported and discussed within
http://lists.gnu.org/archive/html/bug-libtool/2010-01/msg00005.html.  Comically,
I too am trying to use -R to have an installed binary automatically find the
right Intel MKL installation.  An  earlier report is
http://lists.gnu.org/archive/html/bug-libtool/2009-09/msg00037.html.  Original
reasons for the behavior apparently stem from
http://lists.gnu.org/archive/html/libtool-patches/2003-03/msg00086.html.

In http://lists.gnu.org/archive/html/bug-libtool/2010-01/msg00016.html Todd
Gamblin says

> I imagine a lot of people probably expect the current behavior, so maybe
> the practical thing to do short-term is to "fix" the documentation... the
> manual still claims that -R gets propagated, but it looks like that
> hasn't been the case since 2003. That's not to say that I like the
> current behavior (I would like -R propagation) but I was surprised when
> this didn't work for me.

which I'll second.  The current documentation says,

> -R libdir
>     If output-file is a program, add libdir to its run-time path. If
>     output-file is a library, add -Rlibdir to its dependency_libs,
>     so that, whenever the library is linked into a program, libdir
>     will be added to its run-time path.)

which I kept reading and thinking I doing something wrong.  From what
I can glean, that second sentence should be replaced with "If output-file
is a library, add -Rlibdir to its dependency_libs.  However, subsequently
linking a program against this library will not add libdir to the program's
run-time path.  To accomplish this aim, you must again supply -Rlibdir when
linking the program."

Any suggestions, aside from some minor sed work, for how to manually
dig this -Rlibdir from a library's dependency_libs so it can be re-supplied?
This way a program could "poll" libsomething.la for any -Rsomewhere
information it provides.

Mildly related, is there an option to insert content into
inherited_linker_flags?
I'm debating abusing inherited_linker_flags to accomplish -R propagation.
This would allow a library to "push" -Rsomewhere information to others.

Thank you for your time,
Rhys