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
