[sr #108637] libtool adds -rpath to staging directory

[Ileana Dumitrescu]

Update of sr#108637 (group libtool):

  Status:None => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[patch #10384] Add a darwin-specific rpath flag

[Mike Frysinger]

Update of patch#10384 (group libtool):

 Summary:  Add a  => Add a darwin-specific
rpath flag


___

Reply to this item at:

  <https://savannah.gnu.org/patch/?10384>

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [EXTERNAL] Re: Q: Forcing a -Wl,-rpath arg to static lib users

[Oleg Smolsky]

On Fri, Nov 18, 2022 at 12:28 PM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:

> On Fri, 18 Nov 2022, Oleg Smolsky wrote:
> >>
> >> The libtool provided as part of a Linux distribution often hacks
> >> libtool so that it does not include full dependency information in the
> >> library.la files.  They do this in order to avoid "excessive linkage"
> >> because they do not want the program/library to retain full linkage
> >> details in case the OS changes the libraries.
> >>
> >
> > Oh, that's a very interesting hint! thanks, Bob! I am using libtoon from
> > the distro.
> >
> > What does it take to take libtool from upstream? Certainly I can fetch
> its
> > source... but how do I marry that with the  `autoreconf` invocation that
> > drives build system generation?
>
> A reasonable thing to do would be to download the autoconf, automake,
> and libtool tarballs from https://ftp.gnu.org/gnu/.  Build and install
> each one using the same installation prefix.  It is best if the
> installation prefix does not interfere with your operating system (the
> default of "/usr/local" normally works).
>
> OK, I've just installed the latest tagged versions of [autoconf, automake,
libtool] into /opt/3p, regenerated my build system and compiled the minimal
test case. The key variable that I would like to carry the -Wl,rpath flags
is still blank for my static lib:

# Linker flags that cannot go in dependency_libs.
inherited_linker_flags=''

So, do you think these versions are new enough?

[autoconf]
GitRevision = v2.71
Source = https://github.com/autotools-mirror/autoconf.git

[automake]
GitRevision = v1.16.5
Source = https://github.com/autotools-mirror/automake.git

[libtool]
GitRevision = v2.4.7
Source = https://github.com/autotools-mirror/libtool.git

Thanks!
Oleg.

Re: [EXTERNAL] Re: Q: Forcing a -Wl,-rpath arg to static lib users

[Bob Friesenhahn]

On Fri, 18 Nov 2022, Oleg Smolsky wrote:


The libtool provided as part of a Linux distribution often hacks
libtool so that it does not include full dependency information in the
library.la files.  They do this in order to avoid "excessive linkage"
because they do not want the program/library to retain full linkage
details in case the OS changes the libraries.



Oh, that's a very interesting hint! thanks, Bob! I am using libtoon from
the distro.

What does it take to take libtool from upstream? Certainly I can fetch its
source... but how do I marry that with the  `autoreconf` invocation that
drives build system generation?


A reasonable thing to do would be to download the autoconf, automake, 
and libtool tarballs from https://ftp.gnu.org/gnu/.  Build and install 
each one using the same installation prefix.  It is best if the 
installation prefix does not interfere with your operating system (the 
default of "/usr/local" normally works).


Relevant m4 files would appear in something like 
/usr/local/share/aclocal.  It is possible that you might want to 
install some other autotools-related packages.  If it is just some m4 
files that you need, it may be sufficient to copy the needed file from 
your operating systems /usr/share/aclocal directory.


Make sure that the bin directory for those tools is in your PATH 
before the OS-provided tools so the new software appears by default. 
Then do 'autoreconf --force' in your project directory to regenerate 
all of the autotool stuff.


Maybe this will make a difference.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: [EXTERNAL] Re: Q: Forcing a -Wl,-rpath arg to static lib users

[Oleg Smolsky]

On Thu, Nov 17, 2022 at 4:05 PM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:

> On Wed, 16 Nov 2022, Oleg Smolsky wrote:
> >
> > Leaving it here for posterity. Perhaps someone will do this with a bit
> more
> > finesse and turn it into a proper feature.
>
> Are you using libtool as originally distributed by the FSF or are you
> using a libtool provided by a Linux system package?
>
> The libtool provided as part of a Linux distribution often hacks
> libtool so that it does not include full dependency information in the
> library.la files.  They do this in order to avoid "excessive linkage"
> because they do not want the program/library to retain full linkage
> details in case the OS changes the libraries.
>

Oh, that's a very interesting hint! thanks, Bob! I am using libtoon from
the distro.

What does it take to take libtool from upstream? Certainly I can fetch its
source... but how do I marry that with the  `autoreconf` invocation that
drives build system generation?

Oleg.

Re: Q: Forcing a -Wl,-rpath arg to static lib users

[Howard Chu via Discussion list for the GNU libtool shared library maintenance tool]

Bob Friesenhahn wrote:
> On Wed, 16 Nov 2022, Oleg Smolsky wrote:
>>
>> Leaving it here for posterity. Perhaps someone will do this with a bit more
>> finesse and turn it into a proper feature.
> 
> Are you using libtool as originally distributed by the FSF or are you using a 
> libtool provided by a Linux system package?
> 
> The libtool provided as part of a Linux distribution often hacks libtool so 
> that it does not include full dependency information in the library.la files. 
>  They
> do this in order to avoid "excessive linkage" because they do not want the 
> program/library to retain full linkage details in case the OS changes the 
> libraries.
> 
> Shared libraries often/usually only need to know the libraries that they 
> immediately link with, but static libraries need to know everything, and the 
> library.la
> files are intended to fill that gap.

You can now build static libraries that only need to know as much as dynamic 
libraries need to know,
using GNU binutils. The feature was merged ~2 years ago already and is 
supported by ar, ld, and gold.

https://sourceware.org/pipermail/binutils/2020-December/114536.html

> 
> I am thinking that you may be trying to fix something which should already be 
> working with the original FSF libtool.
> 
> Bob


-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Q: Forcing a -Wl,-rpath arg to static lib users

[Bob Friesenhahn]

On Wed, 16 Nov 2022, Oleg Smolsky wrote:


Leaving it here for posterity. Perhaps someone will do this with a bit more
finesse and turn it into a proper feature.


Are you using libtool as originally distributed by the FSF or are you 
using a libtool provided by a Linux system package?


The libtool provided as part of a Linux distribution often hacks 
libtool so that it does not include full dependency information in the 
library.la files.  They do this in order to avoid "excessive linkage" 
because they do not want the program/library to retain full linkage 
details in case the OS changes the libraries.


Shared libraries often/usually only need to know the libraries that 
they immediately link with, but static libraries need to know 
everything, and the library.la files are intended to fill that gap.


I am thinking that you may be trying to fix something which should 
already be working with the original FSF libtool.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Q: Forcing a -Wl,-rpath arg to static lib users

[Oleg Smolsky]

On Mon, Nov 14, 2022 at 8:36 PM Oleg Smolsky  wrote:

> Hello folks! I've been using libtool (via autotools) for a while, but have
> been unable to find a clean solution to the following problem:
>
> I have a static `liblocal.la` (built in my build system) that links to a
> third-party shared lib. Obviously I can use my own lib to express that
> dependency:
>
> liblocal_la_LIBADD = -lexternal -L/somewhere/lib
>
> The missing bit of functionality is -Wl,-rpath,/somewhere/lib that I need
> to impose onto the leaf-level executables that link my local lib.
> Unfortunately these attempts do not work:
>  1. Cannot add that flag to _LIBADD as libtool complains: "...belong in
> 'liblocal_la_LDFLAGS"
>  2. Cannot add that flag to _LDFLAGS as it does not carry all the way to
> the leaf-level executable
>
> I have found that I can manually jam the flag into the
> `inherited_linker_flags` variable inside the .la file and that gives me the
> desired result... but I don't know how to do that via Makefile.am.
>

...and I found a hack that lets me jam these flags into the
`inherited_linker_flags` variable. Here is a patch for the `libtool` script
generated by libtool into $builddir:

```
--- libtool.base2022-11-14 21:18:04.867760568 -0800
+++ libtool.patched 2022-11-14 21:17:32.967784300 -0800
@@ -7826,6 +7826,7 @@
;;

   -Wl,*)
+   func_append new_inherited_linker_flags " $arg"
func_stripname '-Wl,' '' "$arg"
args=$func_stripname_result
arg=

```

Leaving it here for posterity. Perhaps someone will do this with a bit more
finesse and turn it into a proper feature.

Oleg.

Q: Forcing a -Wl,-rpath arg to static lib users

[Oleg Smolsky]

Hello folks! I've been using libtool (via autotools) for a while, but have
been unable to find a clean solution to the following problem:

I have a static `liblocal.la` (built in my build system) that links to a
third-party shared lib. Obviously I can use my own lib to express that
dependency:

liblocal_la_LIBADD = -lexternal -L/somewhere/lib

The missing bit of functionality is -Wl,-rpath,/somewhere/lib that I need
to impose onto the leaf-level executables that link my local lib.
Unfortunately these attempts do not work:
 1. Cannot add that flag to _LIBADD as libtool complains: "...belong in
'liblocal_la_LDFLAGS"
 2. Cannot add that flag to _LDFLAGS as it does not carry all the way to
the leaf-level executable

I have found that I can manually jam the flag into the
`inherited_linker_flags` variable inside the .la file and that gives me the
desired result... but I don't know how to do that via Makefile.am.

I'd appreciate any and all hints/suggestions.

Thanks!
Oleg.

Re: rpath stripping

[Bob Friesenhahn]

On Mon, 18 Apr 2022, Richard Purdie wrote:


As I understand it the dynamic loader has a set of search paths it falls back to
(sys_lib_dlsearch_path in libtool). An RPATH or RUNPATH entry matching a system
loader path isn't usually of much use, it just takes up space.


It is of use since it influences the search order.  For example, if 
/usr/local/lib is in the system loader path, and the user installs a 
library in /usr/local/lib, then the user likely wants the library she 
has just installed to be used by apps which link with it, rather than 
some similar library in the default system loader path.


Likewise, it is pointless to install a library which will never be 
used.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: rpath stripping

[Richard Purdie]

On Mon, 2022-04-18 at 07:39 -0400, Carlos O'Donell wrote:
> On 4/17/22 10:06, Bob Friesenhahn wrote:
> > The libtool I was using (originating from Ubuntu Linux) stripped the
> > rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable
> > to embed an rpath in the libcurl I built so that applications linked
> > with that libcurl would find it.
> 
> I agree with our position.
> 
> The behaviour of stripping '-Wl,-rpath' is incorrect.
> 
> With new DT_RUNPATH semantics (DT_RPATH being deprecated and binutils having
> switched defaults), each shared object, including the binary, must correctly
> specify the search path for the immediate needed objects. Stripping this off
> will result in incorrectly built shared objects and binaries that don't
> operate correctly.
> 
> I'm curious what justification is given for this behaviour.

As I understand it the dynamic loader has a set of search paths it falls back to
(sys_lib_dlsearch_path in libtool). An RPATH or RUNPATH entry matching a system
loader path isn't usually of much use, it just takes up space.

I can imagine some cases where that might not be true such as linking with "-z
nodeflib" or some fairly convoluted setups but I suspect those would have other
issues too.

Cheers,

Richard

Re: rpath stripping

[Carlos O'Donell]

On 4/17/22 10:06, Bob Friesenhahn wrote:
> The libtool I was using (originating from Ubuntu Linux) stripped the
> rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable
> to embed an rpath in the libcurl I built so that applications linked
> with that libcurl would find it.

I agree with our position.

The behaviour of stripping '-Wl,-rpath' is incorrect.

With new DT_RUNPATH semantics (DT_RPATH being deprecated and binutils having
switched defaults), each shared object, including the binary, must correctly
specify the search path for the immediate needed objects. Stripping this off
will result in incorrectly built shared objects and binaries that don't
operate correctly.

I'm curious what justification is given for this behaviour.

-- 
Cheers,
Carlos.

rpath stripping

[Bob Friesenhahn]

There is a libtool patch going around (and submitted to 
libtool-patches) entitled "ltmain.sh: Fix sysroot paths being encoded 
into RPATHs".


I have previous unfortunate experience with libtool doing this (I 
believe that even the FSF version does some of this).  Libtool 
behavior prevented me from doing something I needed to do.  It is 
pretty common for end users (vs OS distribution maintainers) to want 
to build libraries and install them to some place like /usr/local/lib 
in order support modifications which are not in a similar 
system-provided library.  To me this represents part of the freedom 
promoted by the GNU project.


This was my unfortunate experience:

While cross-compiling some software ("Curl") for a target which 
already had an older install present, libtool ended up defeating me. I 
wanted to produce my own libcurl and have the apps specifically 
linking with it, use the libcurl that I had built.  I wanted to leave 
the libcurl that came with the system in place for the many other 
existing apps which needed it.  Unfortunately, the add-on software was 
already configured to install and use libraries in "/usr/lib" and the 
popular/default "/usr/local/lib" was included in the default linker 
path so that would not have worked either.


The libtool I was using (originating from Ubuntu Linux) stripped the 
rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable 
to embed an rpath in the libcurl I built so that applications linked 
with that libcurl would find it.


The end result was that apps linked with the new libcurl tried to use 
an older libcurl on the system, and failed to run.


I was unable to circumvent this issue caused by libtool.

It is useful if user-provided options have priority over built-in 
optimizations in libtool.


As a user, I strongly suggest that libtool honor user-supplied options 
to the configure script and provided to the libtool command line, even 
while it optimizes other unneeded options away.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Accounting for -rpath when libtool isn't helping

[Roumen Petrov]

Hi Paul,

Paul "LeoNerd" Evans wrote:

[SNIP]
Alternatively, am I looking at this from the wrong direction? Maybe the
problem is that the exporting library isn't providing -Wl,-rpath in
its .pc file, to assist anyone else who wasn't using libtool to link it
(such as is the case here).

No , I don't think that this is valuable.



With that in mind, I now generate those if required, in the little
shell fragment I use to create the .pc file:

#!/bin/sh

LIBS='-L${libdir} -ltickit'
CFLAGS='-I${includedir}'

case "$LIBDIR" in
   /usr/lib) ;;
   /usr/local/lib) ;;
   *)
     LIBS="$LIBS -Wl,-rpath -Wl,$LIBDIR"
 ;;
esac

cat <

Like you perl (first email) and shell (above) scripts libtool do similar 
to decide when to add "runpath" linker flag. Libtool parses 
/etc/ld.so.conf and "build-in default paths" and if a library path is 
not in list adds "runpath" flag.


On most platform you control this via variable 
lt_cv_sys_lib_dlsearch_path_spec. Pattern *_cv_* mean that this is a 
"autoconf cache variable" and "lt" is custom namespace prefix.


Add $HOME/lib to list to avoid -rpath flag.


For some autoconf builds with use of libtool you could force -rpath if 
needed - add those options to LDFLAGS ( see ./configure --help) .



Regards,
Roumen Petrov


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Accounting for -rpath when libtool isn't helping

[Paul "LeoNerd" Evans]

On Thu, 14 Feb 2019 23:21:26 +
"Paul \"LeoNerd\" Evans"  wrote:

> My earlier suggested approach of trying to hunt down the .la files and
> generate/append extra -Wl,-rpath arguments appears to be working
> reliably though, so it may be that's the best approach. It does feel
> rather fragile however, as I'm second-guessing around what libtool
> would do.

Alternatively, am I looking at this from the wrong direction? Maybe the
problem is that the exporting library isn't providing -Wl,-rpath in
its .pc file, to assist anyone else who wasn't using libtool to link it
(such as is the case here).

With that in mind, I now generate those if required, in the little
shell fragment I use to create the .pc file:

#!/bin/sh

LIBS='-L${libdir} -ltickit'
CFLAGS='-I${includedir}'

case "$LIBDIR" in
  /usr/lib) ;;
  /usr/local/lib) ;;
  *)
LIBS="$LIBS -Wl,-rpath -Wl,$LIBDIR"
;;
esac

cat <https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/


pgpnfDWuo8Bev.pgp
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Accounting for -rpath when libtool isn't helping

[Paul "LeoNerd" Evans]

On Thu, 7 Feb 2019 15:20:32 +0100
Thomas Jahns  wrote:

> Have you tried setting something like
> 
> CC='libtool cc'
> CFLAGS='--mode=compile -some -other -flags -youd -use'
> LDFLAGS='--mode=link -some -further -link -flags'

I've been looking at that, and it doesn't seem to be an easy one.

Ignoring for a moment how complicated it'd be to get those env vars
set, the main trouble seems to be in the "link" step:

$ CC="libtool --mode=compile gcc" LD="libtool --mode=link gcc" ./Build

runs OK up until the point it tries to link the eventual output:

libtool: link: gcc -fstack-protector-strong -o 
blib/arch/auto/Tickit/Async/Async.so lib/Tickit/Async.o  -L/usr/local/lib 
-L/home/leo/lib /home/leo/lib/libtickit.so -Wl,-rpath -Wl,/home/leo/lib 
-Wl,-rpath -Wl,/home/leo/lib
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o: 
in function `_start':
(.text+0x20): undefined reference to `main'
/usr/bin/ld: lib/Tickit/Async.o: in function `invoke_watch':
/home/leo/src/perl/Tickit-Async/lib/Tickit/Async.xs:34: undefined reference to 
`PL_thr_key'
...

it then goes on to complain about a lot of undefined symbols; namely
all the perl ones, because those won't be defined yet. Those get
defined by loading the eventual .so into the perl interpreter.

My earlier suggested approach of trying to hunt down the .la files and
generate/append extra -Wl,-rpath arguments appears to be working
reliably though, so it may be that's the best approach. It does feel
rather fragile however, as I'm second-guessing around what libtool
would do.

-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/


pgpH6Lt5k6Kn9.pgp
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Accounting for -rpath when libtool isn't helping

[Thomas Jahns]

Hello Paul,

On 2/6/19 2:21 PM, Paul "LeoNerd" Evans wrote:

Nowthen - my actual question concerns what happens when I am not using
libtool to build my program. Such a case is common when building
C-level integration libraries for dynamic languages (Perl in my case).
I can't get libtool to directly build the code in question, because
Perl has its own build tooling. I can ask pkg-config what it thinks of
the --cflags and --libs to link against the library, but without
getting libtool involved in the magic step above, I don't get the
-rpath argument added.


Have you tried setting something like

CC='libtool cc'
CFLAGS='--mode=compile -some -other -flags -youd -use'
LDFLAGS='--mode=link -some -further -link -flags'

?

Regards, Thomas
--
Thomas Jahns
HD(CP)^2
Abteilung Anwendungssoftware

Deutsches Klimarechenzentrum GmbH
Bundesstraße 45a • D-20146 Hamburg • Germany

Phone:  +49 40 460094-151
Fax:+49 40 460094-270
Email:  Thomas Jahns 
URL:www.dkrz.de

Geschäftsführer: Prof. Dr. Thomas Ludwig
Sitz der Gesellschaft: Hamburg
Amtsgericht Hamburg HRB 39784

___
https://lists.gnu.org/mailman/listinfo/libtool

Accounting for -rpath when libtool isn't helping

[Paul "LeoNerd" Evans]

Hi all,

A *slightly* offtopic question here but I'm hoping someone will be able
to offer some assistance.

First off, the all-libtool case for comparison. If I install some
libtool-based library, it drops some files in (for example)
$HOME/lib - these files primarily are the libfoo.so* collection of the
actual library, and the libfoo.la file that controls how libtool works.
Combined with pkg-config to set the linker flags to "-L$HOME/lib -lfoo"
if I then use libtool again somewhere else to compile a program using
that library, then it appears that the compiler is invoked with

  cc -L$HOME/lib -lfoo program.c

but something exciting and magical happens - libtool appends the rpath
argument. On my Linux box at least, what this turns into is

  cc -L$HOME/lib -lfoo program.c -Wl,-rpath -Wl,$HOME/lib

This then bakes the appropriate RUNPATH into the compiled program so
that it can find its library at runtime. All is good.

Nowthen - my actual question concerns what happens when I am not using
libtool to build my program. Such a case is common when building
C-level integration libraries for dynamic languages (Perl in my case).
I can't get libtool to directly build the code in question, because
Perl has its own build tooling. I can ask pkg-config what it thinks of
the --cflags and --libs to link against the library, but without
getting libtool involved in the magic step above, I don't get the
-rpath argument added.

So firstly, a question:

  Is there a way I can ask libtool to print what extra arguments it
  would have applied? Or failing that, to just print the full `cc`
  commandline and I can try to parse that back out?

Failing that as an option, I have instead taken to trying to
reïmplement that bit of logic, by trying to read through the ~12k line
shell script that is `libtool`, to see if I can work out what it does.
I think my summary is basically:

  * Collect up the -L$DIR arguments to form a search path

  * Collect up the -l$foo arguments to look for a lib$foo.la file in
the search path.
For each .la file, add its containing directory to the eventual set
of rpaths

  * Append those rpaths to the `cc` commandline

In order to assist my Perl build process, I've come up with the
following code, to try to recreate this magical step and allow things
to link properly. (Variously commented to try to explain the overall
approach to those unfamiliar with Perl):

   # the original commandline goes here
   my @extra_linker_flags = ... 


   my @system_libdirs = my @libdirs = qw( /lib /usr/lib );
   my @rpaths;

   FLAG: foreach my $flag ( @extra_linker_flags ) {
  # Match an -LDIR argument and parse the DIR part out of it
  if( $flag =~ m/^-L(.*)$/ ) {
 push @libdirs, $1;
 next FLAG;
  }

  # Match an -lLIB argument and parse the LIB part out of it
  if( $flag =~ m/^-l(.*)$/ ) {
 my $lafile = "lib$1.la";

 # Look for the first directory in @libdirs containing the $lafile
 my $libdir = first { -f "$_/$lafile" } @libdirs;

 # Skip if we didn't find the lafile
 defined $libdir or next FLAG;

 # Avoid already-known system directories and duplicates that
 # we've already collected
 $_ eq $libdir and next FLAG for @system_libdirs, @rpaths;

 print STDERR "Accumulated extra -rpath=$libdir\n";
 push @rpaths, $libdir;
 next FLAG;
  }
   }

   # Append the appropriate linker arguments for the new rpaths we found
   foreach my $rpath ( @rpaths ) {
      push @extra_linker_flags, "-Wl,-rpath", "-Wl,$rpath";
   }

Does that overall logic feel about right? Is this the best thing to be
doing, or is there a different approach I ought to be taking?

-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/


pgplih7GuZ34K.pgp
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: How can I get rid of the -L entry of LDLIBS from RPATH?

[Bob Friesenhahn]

On Mon, 31 Jul 2017, Krisztian Kovacs wrote:


Hi!

I haven't seen any examples how to set these script variables:
https://www.gnu.org/software/libtool/manual/html_node/
libtool-script-contents.html#libtool-script-contents
Can are they set per project?
If so, how?


All libtool script content is generated by 'configure' as described. 
In many cases, configure arguments may be used to set/override values 
(e.g. 'CC').  Many of these values may also be obtained from the shell 
environment in which configure is run.


A config.site script (e.g. /usr/local/share/config.site) may be used 
to set default values for most variables set or used by configure and 
may be used to remember any settings found in the generated 
config.status script.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

How can I get rid of the -L entry of LDLIBS from RPATH?

[Krisztian Kovacs]

Hi!

I haven't seen any examples how to set these script variables:
https://www.gnu.org/software/libtool/manual/html_node/
libtool-script-contents.html#libtool-script-contents
Can are they set per project?
If so, how?

The full question is on stackoverflow:
https://stackoverflow.com/questions/45282061/how-when-
where-to-set-script-variables-of-libtool-e-g-hardcode-minus-l

E.g., rtorrent has 2 files: "configure.ac" and "Makefile.am" :

- makefile.am won't do anything
- I tried to insert this at the end of configure.ac, but it also doesn't do
anything:
_LT_TAGVAR('hardcode_minus_L)=yes


Thanks
___
https://lists.gnu.org/mailman/listinfo/libtool

Rpath issues when attempting to cross compile

[Alex Barker]

Hi,

I appear to be running into an at least 9 year old issue with rpath and the
auto-magic that is libtool paths.  According to the docs
<https://www.gnu.org/software/automake/manual/html_node/Conditional-Libtool-Libraries.html>,
the rpath should be calculated for me, however, upon installation, lib tool
decides to look in /usr/lib instead of
/usr/armv6j-hardfloat-linux-gnueabihf/usr/lib.
Notice that it does indeed build and link correctly, but the installation
phase tries to get smart and fails miserably. How do I work around this
problem? It's blocking my development on an unrelated project. Build log
can be found here: https://572732.bugs.gentoo.org/attachment.cgi?id=423734

Best,
Alex
___
https://lists.gnu.org/mailman/listinfo/libtool

rpath for an inter-library dependency

[Marcin Zalewski]

Hello.

I have a contrib jemalloc library in my project that is not being
built using libtool. When I build my libtool library, I add this to
the link line:

-ljemalloc -R/rpath/to/jemalloc

This works fine, and my .la file includes:

dependency_libs=' -R/rpath/to/jemalloc -ljemalloc'

However, when I link my programs with the .la file, I do not get rpath
on the liker line, which causes a run-time failure when the program is
run. Am I using the -R option correctly? I was hoping that I could
make it a dependency in my .la file and not have to worry about it.
The documentation for -R says:

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.

As far as I understood this, once my library has this dependency, the
rpath will be added to any program that links to my library, but that
is not happening.

Any help would be appreciated,
-m

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: rpath for an inter-library dependency

[Robert Boehne]

So if I read these correctly, you specify the runtime path with -R but not
the link time location with -L ?  Does too run without help if you specify
both when you build your Libtool library?

Robert Boehne
On Feb 11, 2015 2:39 PM, Bert Wesarg bert.wes...@googlemail.com wrote:

 Hi,

 On Wed, Feb 11, 2015 at 5:28 PM, Marcin Zalewski
 marcin.zalew...@gmail.com wrote:
  Hello.
 
  I have a contrib jemalloc library in my project that is not being
  built using libtool. When I build my libtool library, I add this to
  the link line:
 
  -ljemalloc -R/rpath/to/jemalloc
 
  This works fine, and my .la file includes:
 
  dependency_libs=' -R/rpath/to/jemalloc -ljemalloc'
 
  However, when I link my programs with the .la file, I do not get rpath
  on the liker line, which causes a run-time failure when the program is
  run. Am I using the -R option correctly? I was hoping that I could
  make it a dependency in my .la file and not have to worry about it.
  The documentation for -R says:
 
  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.
 
  As far as I understood this, once my library has this dependency, the
  rpath will be added to any program that links to my library, but that
  is not happening.

 this is a known problem, though it seems that it is not considered as
 one by the libtool team:

 http://lists.gnu.org/archive/html/libtool/2011-11/msg00010.html

 Bert

 
  Any help would be appreciated,
  -m

 ___
 https://lists.gnu.org/mailman/listinfo/libtool

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: rpath for an inter-library dependency

[Bert Wesarg]

Robert,

On Wed, Feb 11, 2015 at 9:46 PM, Robert Boehne rboe...@gmail.com wrote:
 So if I read these correctly, you specify the runtime path with -R but not
 the link time location with -L ?

where did you get the impression, that I did not specify -L in
conjunction with -R? We obviously do this, because linking always
succeeds, but running the application not, because the runtime path is
missing.


 Does too run without help if you specify
 both when you build your Libtool library?

It is not about building libtool libraries, it is about linking
applications against libtool libraries, which depend on other
libraries which need rpath information.

Bert


 Robert Boehne

 On Feb 11, 2015 2:39 PM, Bert Wesarg bert.wes...@googlemail.com wrote:

 Hi,

 On Wed, Feb 11, 2015 at 5:28 PM, Marcin Zalewski
 marcin.zalew...@gmail.com wrote:
  Hello.
 
  I have a contrib jemalloc library in my project that is not being
  built using libtool. When I build my libtool library, I add this to
  the link line:
 
  -ljemalloc -R/rpath/to/jemalloc
 
  This works fine, and my .la file includes:
 
  dependency_libs=' -R/rpath/to/jemalloc -ljemalloc'
 
  However, when I link my programs with the .la file, I do not get rpath
  on the liker line, which causes a run-time failure when the program is
  run. Am I using the -R option correctly? I was hoping that I could
  make it a dependency in my .la file and not have to worry about it.
  The documentation for -R says:
 
  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.
 
  As far as I understood this, once my library has this dependency, the
  rpath will be added to any program that links to my library, but that
  is not happening.

 this is a known problem, though it seems that it is not considered as
 one by the libtool team:

 http://lists.gnu.org/archive/html/libtool/2011-11/msg00010.html

 Bert

 
  Any help would be appreciated,
  -m

 ___
 https://lists.gnu.org/mailman/listinfo/libtool

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: rpath for an inter-library dependency

[Bert Wesarg]

Hi,

On Wed, Feb 11, 2015 at 5:28 PM, Marcin Zalewski
marcin.zalew...@gmail.com wrote:
 Hello.

 I have a contrib jemalloc library in my project that is not being
 built using libtool. When I build my libtool library, I add this to
 the link line:

 -ljemalloc -R/rpath/to/jemalloc

 This works fine, and my .la file includes:

 dependency_libs=' -R/rpath/to/jemalloc -ljemalloc'

 However, when I link my programs with the .la file, I do not get rpath
 on the liker line, which causes a run-time failure when the program is
 run. Am I using the -R option correctly? I was hoping that I could
 make it a dependency in my .la file and not have to worry about it.
 The documentation for -R says:

 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.

 As far as I understood this, once my library has this dependency, the
 rpath will be added to any program that links to my library, but that
 is not happening.

this is a known problem, though it seems that it is not considered as
one by the libtool team:

http://lists.gnu.org/archive/html/libtool/2011-11/msg00010.html

Bert


 Any help would be appreciated,
 -m

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: rpath for an inter-library dependency

[Marcin Zalewski]

Thanks Bert.

This is indeed exactly the same issue I am facing. I would like the
-rpath option to be added to all programs that use my .la library with
the -R flag in dependency_libs, but that is not happening. As far as I
understand, we agree that the documentation says that an -R flag in
.la lib should result in the appropriate -rpath flags to the linker
when a program linking to that library is compiled. So the patch in
your email thread does the trick? The solution seems very simple.

Regards,
Marcin

On Wed, Feb 11, 2015 at 3:39 PM, Bert Wesarg bert.wes...@googlemail.com wrote:
 Hi,

 On Wed, Feb 11, 2015 at 5:28 PM, Marcin Zalewski
 marcin.zalew...@gmail.com wrote:
 Hello.

 I have a contrib jemalloc library in my project that is not being
 built using libtool. When I build my libtool library, I add this to
 the link line:

 -ljemalloc -R/rpath/to/jemalloc

 This works fine, and my .la file includes:

 dependency_libs=' -R/rpath/to/jemalloc -ljemalloc'

 However, when I link my programs with the .la file, I do not get rpath
 on the liker line, which causes a run-time failure when the program is
 run. Am I using the -R option correctly? I was hoping that I could
 make it a dependency in my .la file and not have to worry about it.
 The documentation for -R says:

 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.

 As far as I understood this, once my library has this dependency, the
 rpath will be added to any program that links to my library, but that
 is not happening.

 this is a known problem, though it seems that it is not considered as
 one by the libtool team:

 http://lists.gnu.org/archive/html/libtool/2011-11/msg00010.html

 Bert


 Any help would be appreciated,
 -m

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Tune rpath by env. variable

[Gary V. Vaughan]

Hi Pavel,

On Dec 13, 2014, at 5:58 PM, Pavel Raiskup prais...@redhat.com wrote:
 
 On Friday 12 of December 2014 11:17:03 Gary V. Vaughan wrote:
 I'll commit a follow on patch, to tweak it like this, later today.
 
 Thanks for the patch!  It is almost perfect.  During testing I noted that
 there is still one dollar sign not substituted with quadrigraph.  Patch
 0001 attached.
 
 Also, I noted having LT_SYS_SEARCH_PATH=/lib64: specified in config.site
 does not change libtool's content;  it the LT_SYS_LIBRARY_PATH default
 value stays empty.  I would like to have it fixed before 2.4.5, if
 possible, because I would like to enable something like the following in
 our default /usr/share/config.site file:
 
  if $arch_64bit; then
: ${LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64:}
  fi
 
 Also, I'm not sure whether we should touch the lt_cv_sys_*.  That should
 not hurt too much but I would feel quite more safe if we use separate
 variable and let the lt_cv_* for existing workarounds in the wild.
 Something like the attachment 0002 would be nice to have pushed.

Thanks for the patches.  I tweaked them to pass `make syntax-check`, applied
and pushed both.

 That code seems like asking for test-case also?

The more the better!

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Tune rpath by env. variable

[Pavel Raiskup]

On Tuesday 20 of January 2015 07:40:20 Pavel Raiskup wrote:
  Something like the attachment 0002 would be nice to have pushed.
 
 This would be nice to have it in git also.  The LT_SYS_SEARCH_PATH does
 not survive automatic re-autoconf of configure script:

Argh :(, sorry.  Fixing the example:

  // libtool after LT_SYS_SEARCH_PATH=/lib64: ./configure

  # Configured defaults for sys_lib_dlsearch_path munging.
  : ${LT_SYS_LIBRARY_PATH=/lib64:}

  // libtool after 'touch configure.ac ; make'

  # Configured defaults for sys_lib_dlsearch_path munging.
  : ${LT_SYS_LIBRARY_PATH=}

  //  ^^


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Tune rpath by env. variable

[Pavel Raiskup]

On Saturday 13 of December 2014 18:58:58 Pavel Raiskup wrote:
 On Friday 12 of December 2014 11:17:03 Gary V. Vaughan wrote:
  I'll commit a follow on patch, to tweak it like this, later today.
 
 Thanks for the patch!  It is almost perfect.  During testing I noted that
 there is still one dollar sign not substituted with quadrigraph.  Patch
 0001 attached.

Sorry for not pinging you because of this issue before the 2.4.5 release,
pinging now to get it fixed at least in 'master'.  The LT_SYS_LIBRARY_PATH
variable is probably completely broken.  Current problem:

  $ LT_SYS_LIBRARY_PATH=/lib64: ./configure
  [...]
  checking dynamic linker characteristics... GNU/Linux ld.so
  ./configure: line 8532: @1: command not found
  ./configure: eval: line 8532: unexpected EOF while looking for matching `'
  ./configure: eval: line 8533: syntax error: unexpected end of file
  checking how to hardcode library paths into programs... immediate
  checking for shl_load... no
  [...]

 Also, I noted having LT_SYS_SEARCH_PATH=/lib64: specified in config.site
 does not change libtool's content;  it the LT_SYS_LIBRARY_PATH default
 value stays empty.  I would like to have it fixed before 2.4.5, if
 possible, because I would like to enable something like the following in
 our default /usr/share/config.site file:
 
   if $arch_64bit; then
 : ${LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64:}
   fi
 
 Also, I'm not sure whether we should touch the lt_cv_sys_*.  That should
 not hurt too much but I would feel quite more safe if we use separate
 variable and let the lt_cv_* for existing workarounds in the wild.
 Something like the attachment 0002 would be nice to have pushed.

This would be nice to have it in git also.  The LT_SYS_SEARCH_PATH does
not survive automatic re-autoconf of configure script:

  // libtool after LT_SYS_SEARCH_PATH=/lib64:

  # Configured defaults for sys_lib_dlsearch_path munging.
  : ${LT_SYS_LIBRARY_PATH=/lib64:}

  // libtool after 'touch configure.ac ; make'

  # Configured defaults for sys_lib_dlsearch_path munging.
  : ${LT_SYS_LIBRARY_PATH=/lib64:}


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Tune rpath by env. variable

[Pavel Raiskup]

On Friday 12 of December 2014 11:17:03 Gary V. Vaughan wrote:
 I'll commit a follow on patch, to tweak it like this, later today.

Thanks for the patch!  It is almost perfect.  During testing I noted that
there is still one dollar sign not substituted with quadrigraph.  Patch
0001 attached.

Also, I noted having LT_SYS_SEARCH_PATH=/lib64: specified in config.site
does not change libtool's content;  it the LT_SYS_LIBRARY_PATH default
value stays empty.  I would like to have it fixed before 2.4.5, if
possible, because I would like to enable something like the following in
our default /usr/share/config.site file:

  if $arch_64bit; then
: ${LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64:}
  fi

Also, I'm not sure whether we should touch the lt_cv_sys_*.  That should
not hurt too much but I would feel quite more safe if we use separate
variable and let the lt_cv_* for existing workarounds in the wild.
Something like the attachment 0002 would be nice to have pushed.

That code seems like asking for test-case also?

Thanks,
Pavel
From 562a2a74f7cbaf236aee46b88cf01e06217300cb Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Sat, 13 Dec 2014 10:59:37 +0100
Subject: [PATCH 1/2] libtool.m4: typofix, subst last '$' with quadrigraph

* m4/libtool.m4 (_LT_LIBTOOL_TAG_VARS): Encase the
configure/libtool shared function into parseable borders; for
testing purposes.
(func_munge_path_list): Typo s/$/@S|@/.
* tests/configure-funcs.at: New testcase.
* Makefile.am (TESTSUITE_AT): Mention new testcase.
---
 Makefile.am  |  1 +
 m4/libtool.m4|  9 ---
 tests/configure-funcs.at | 70 
 3 files changed, 76 insertions(+), 4 deletions(-)
 create mode 100644 tests/configure-funcs.at

diff --git a/Makefile.am b/Makefile.am
index f1b7ead..ede28c7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -651,6 +651,7 @@ testsuite	= $(tests_dir)/testsuite
 # that it can check for previous failures and skip if necessary.
 TESTSUITE	= tests/testsuite
 TESTSUITE_AT	= tests/testsuite.at \
+		  tests/configure-funcs.at \
 		  tests/libtoolize.at \
 		  tests/libtool.at \
 		  tests/demo.at \
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index f879988..31431ee 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -748,13 +748,14 @@ _LT_LIBTOOL_TAG_VARS
 _LT_EOF
 
 cat '_LT_EOF'  $cfgfile
-## -- ##
-## Shell functions shared with configure. ##
-## -- ##
+
+# ### BEGIN FUNCTIONS SHARED WITH CONFIGURE
 
 _LT_PREPARE_MUNGE_PATH_LIST
 _LT_PREPARE_CC_BASENAME
 
+# ### END FUNCTIONS SHARED WITH CONFIGURE
+
 _LT_EOF
 
   case $host_os in
@@ -2256,7 +2257,7 @@ func_munge_path_list ()
 x)
 ;;
 *:)
-eval @S|@1=\`$ECHO @S|@2 | $SED 's/:/ /g'` \$@S|@1\
+eval @S|@1=\`$ECHO @S|@2 | $SED 's/:/ /g'` \@S|@@S|@1\
 ;;
 x:*)
 eval @S|@1=\\@S|@@S|@1 `$ECHO @S|@2 | $SED 's/:/ /g'`\
diff --git a/tests/configure-funcs.at b/tests/configure-funcs.at
new file mode 100644
index 000..eab84a0
--- /dev/null
+++ b/tests/configure-funcs.at
@@ -0,0 +1,70 @@
+# configure-functions.at -- Linking and loading. -*- Autotest -*-
+#
+#   Copyright (C) 2014 Free Software Foundation, Inc.
+#
+#   This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING.  If not, a copy
+# can be downloaded from  http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+AT_BANNER([Functions shared with configure and libtool.])
+
+m4_define([_AT_FUNC_SETUP], [dnl
+AT_SETUP($1)dnl
+_lt_bin=$abs_top_builddir/libtool
+re_begincf='^# ### BEGIN FUNCTIONS SHARED WITH CONFIGURE'
+re_endcf='^# ### END FUNCTIONS SHARED WITH CONFIGURE'
+
+$ECHO '#!/bin/sh'$1
+$ECHO '#: ${SED=sed}'$1
+$ECHO '#: ${ECHO=echo}'  $1
+
+sed 1,/$re_begincf/d;/$re_endcf/,\$d  $_lt_bin  $1
+])
+
+_AT_FUNC_SETUP([func_munge_path_list])
+
+cat \EOF  func_munge_path_list
+for orig in /usr/lib  /lib /usr/lib ; do
+  $ECHO '$orig':
+  for path in /p1: /p3:/p2: :/a1 :/a2:/a3 /p4::/a4 /p6:/p5::/a5:/a6; do
+old=$orig
+func_munge_path_list orig $path || exit 1
+$ECHO munge ($path) = $orig
+  done
+done
+EOF
+chmod +x func_munge_path_list
+
+AT_CHECK([ECHO=$ECHO SED=$SED ./func_munge_path_list], [0],
+['/usr/lib':
+munge 

Re: Tune rpath by env. variable

[Pavel Raiskup]

On Thursday 11 of December 2014 23:29:56 Gary V. Vaughan wrote:
 I applied your patch with some fairly heavy-handed changes:

   1. Added a NEWS update.
   2. Simplified the new documentation.
   3. Changed the name of some internal API symbols.
   4. Fixed dollar quoting with quadrigraphs, and then expand the shared
  function directly into libtool.

Thanks a lot for all of this ^.

   5. Remove the scripts for slicing and dicing that function out of one
  file and into another the hard way.

The libtool's code is so sophisticated, thanks, thats perfect!  I need
to give the code-reading another chance (yeah a minute or so) to review
everything properly;  I'll do so but it looks fine to me now.

 I still have some small concerns about the correctness.

 Do we really want the configure time LT_SYS_LIBRARY_PATH adjusted
 lt_lib_dlsearch_path_spec injected into the installed libtool script? That
 makes me think that if LT_SYS_LIBRARY_PATH is set in /etc/profile or similar,
 that the adjustment will happen twice.

Yes.  Thats why I wanted let the libtool ignore environment var (to avoid
duplicities);  and because for me, the ./configure time
LT_SYS_LIBRARY_PATH seems to be more important...

 I think it would work better to leave lt_lib_dlsearch_path_spec in the
 generated file as it was before (just the heuristic configure time values),
 and add to the top of libtool:

   : ${LT_SYS_LIBRARY_PATH=/configure/time:/path/list}

 Then installed libtool will work whether the user wants to set it differently,
 or not at all, or if LT_SYS_LIBRARY_PATH is set in the environment for both
 configure and libtool, without double adjusting.

 WDYT?

Thats definitely cleaner.  Ack.  I mean, only if we still can use
LT_SYS_LIBRARY_PATH to enhance ltdl.m4's runtime library path
during ./configure time.  Now however, the path munging routine from
libtool.m4 should be easy to reuse in ltdl.m4.  And also if:

  LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64: ./configure

.. is enough to to stop thinking about LT_SYS_LIBRARY_PATH during
development as it should survive things like 'touch configure.ac ; make'.

Pavel


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Tune rpath by env. variable

[Gary V. Vaughan]

Hi Pavel,

On Dec 12, 2014, at 10:02 AM, Pavel Raiskup prais...@redhat.com wrote:
 On Thursday 11 of December 2014 23:29:56 Gary V. Vaughan wrote:
 I think it would work better to leave lt_lib_dlsearch_path_spec in the
 generated file as it was before (just the heuristic configure time values),
 and add to the top of libtool:
 
  : ${LT_SYS_LIBRARY_PATH=/configure/time:/path/list}
 
 Then installed libtool will work whether the user wants to set it 
 differently,
 or not at all, or if LT_SYS_LIBRARY_PATH is set in the environment for both
 configure and libtool, without double adjusting.
 
 WDYT?
 
 Thats definitely cleaner.  Ack.  I mean, only if we still can use
 LT_SYS_LIBRARY_PATH to enhance ltdl.m4's runtime library path
 during ./configure time.  Now however, the path munging routine from
 libtool.m4 should be easy to reuse in ltdl.m4.  And also if:
 
  LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64: ./configure
 
 .. is enough to to stop thinking about LT_SYS_LIBRARY_PATH during
 development as it should survive things like 'touch configure.ac ; make'.

Right, and in that case we'd generate a libtool that contains:

  : ${LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64:}

  sys_lib_dlsearch_path=/lib /usr/lib

  [[...]]

  func_munge_path_list ()
  {
  [[...]]
  }

  [[...]]

  func_munge_path_list sys_lib_dlsearch_path $LT_SYS_LIBRARY_PATH

Which means by default libtool uses the configured additional paths, but
still has the flexibility for the caller to change them (cross-compiling
to Fedora?).

I'll commit a follow on patch, to tweak it like this, later today.

Thanks for the help and feedback!

Cheers,
-- 
Gary V. Vaughan (gary AT vaughan DOT pe)
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Tune rpath by env. variable

[Gary V. Vaughan]

Hi Pavel,

 On Dec 10, 2014, at 6:41 PM, Pavel Raiskup prais...@redhat.com wrote:
 
 On Tuesday 09 of December 2014 19:38:53 Gary V. Vaughan wrote:
 .. however, maybe you think that quite problematic the share with ltdl.m4
 (via sys_lib_dlsearch_path).  That is ?clearly? configure-time only
 variable which generates variable LT_DLSEARCH_PATH in c-header file.
 
 We will probably need to promote the macros required to support that to
 libtool.m4 now that we care about setting sys_dlsearch_path_spec, without
 requiring every package to use ltdl.m4.
 
 In this case, using LT_SYS_LIBRARY_PATH at runtime would differentiate
 LT_DLSEARCH_PATH with libtool's 'sys_dlsearch_path_spec' ... and could
 cause confusion later.
 
 It's a lot of variables, but technically it seems sound to me.
 
 Hmm, due to its requirments, it seems like LT_SYS_LIBRARY_PATH should be
 AC_ARG_VAR-ed.  The system-wide libtool should be pre-configured correctly
 according to system's needs anyway.  WDYT?
 
 I think it would be easier to have both installed and in-tree libtool
 respect LT_SYS_LIBRARY_PATH, otherwise we have to edit the installed script
 to take out the substitution code.
 
 Hi Gary, I tried to patch libtool according to previous discussion.
 That requires good review, however.  Patch attached.
 
 Pavel
 0001-libtool-allow-adjusting-run-time-library-path.patch

Many thanks for working on this.

I applied your patch with some fairly heavy-handed changes:

  1. Added a NEWS update.
  2. Simplified the new documentation.
  3. Changed the name of some internal API symbols.
  4. Fixed dollar quoting with quadrigraphs, and then expand the shared
 function directly into libtool.
  5. Remove the scripts for slicing and dicing that function out of one
 file and into another the hard way.

I still have some small concerns about the correctness.

Do we really want the configure time LT_SYS_LIBRARY_PATH adjusted
lt_lib_dlsearch_path_spec injected into the installed libtool script? That
makes me think that if LT_SYS_LIBRARY_PATH is set in /etc/profile or similar,
that the adjustment will happen twice.

I think it would work better to leave lt_lib_dlsearch_path_spec in the
generated file as it was before (just the heuristic configure time values),
and add to the top of libtool:

  : ${LT_SYS_LIBRARY_PATH=/configure/time:/path/list}

Then installed libtool will work whether the user wants to set it differently,
or not at all, or if LT_SYS_LIBRARY_PATH is set in the environment for both
configure and libtool, without double adjusting.

WDYT?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Tune rpath by env. variable

[Pavel Raiskup]

On Tuesday 09 of December 2014 19:38:53 Gary V. Vaughan wrote:
  .. however, maybe you think that quite problematic the share with ltdl.m4
  (via sys_lib_dlsearch_path).  That is ?clearly? configure-time only
  variable which generates variable LT_DLSEARCH_PATH in c-header file.
 
 We will probably need to promote the macros required to support that to
 libtool.m4 now that we care about setting sys_dlsearch_path_spec, without
 requiring every package to use ltdl.m4.
 
  In this case, using LT_SYS_LIBRARY_PATH at runtime would differentiate
  LT_DLSEARCH_PATH with libtool's 'sys_dlsearch_path_spec' ... and could
  cause confusion later.
 
 It's a lot of variables, but technically it seems sound to me.
 
  Hmm, due to its requirments, it seems like LT_SYS_LIBRARY_PATH should be
  AC_ARG_VAR-ed.  The system-wide libtool should be pre-configured correctly
  according to system's needs anyway.  WDYT?
 
 I think it would be easier to have both installed and in-tree libtool
 respect LT_SYS_LIBRARY_PATH, otherwise we have to edit the installed script
 to take out the substitution code.

Hi Gary, I tried to patch libtool according to previous discussion.
That requires good review, however.  Patch attached.

Pavel
From fdc38af01a9079f712787db451ca6003101d53f1 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Sat, 6 Dec 2014 16:35:41 +0100
Subject: [PATCH] libtool: allow adjusting run-time library path

Some GNU/Linux distributions install libraries into /lib64 (or
/usr/lib64) on 64-bit machines, while /lib (/usr/lib respectively)
stays for multilib variant.  Other distributions keep /usr/lib for
64-bit variant and reserve other directory for multilib.
Distributions also have ldconfig configured properly to search
corresponding library PATH.

For libtool, it is quite difficult to detect which approach the
particular GNU/Linux box uses, however.  Glibc's ldconfig does not
provide complete PATH either.  So, by using LT_SYS_LIBRARY_PATH we
are able to enhance the dynamic library search path now, either
during ./configure time, or at run-time.

References:
http://thread.gmane.org/gmane.comp.gnu.libtool.general/8339/focus=8345

* m4/libtool.m4 (_LT_PATH_ENHANCE): New function to parse
the new path format.  Defines func_path_enhance () shell function.
(_LT_SYS_DYNAMIC_LINKER): Requires _LT_PATH_ENHANCE. AC_ARG_VAR
the LT_SYS_LIBRARY_PATH (to survive automatic autoreconf).
Avoid hardcoding list of CPUs. Call the new func_path_enhance on
sys_lib_dlsearch_path_spec - this propagates results to ltdl.m4.
* build-aux/ltmain.in: Expand the func_path_enhance function.
* Makefile.am (SCRIPT_ENV): Add $(AWK).
(m4_expand, m4_extract): New variables.
(EXTRA_DIST): Mention the two new vars ^.
(bootstrap_edit): Substitute also @libtool_m4@.
($ltmain_sh): Pipe through $(m4_expand) also.
* build-aux/m4-expand: New helper to extract code from m4 file for
other use.
* build-aux/m4-extract: Likewise.
* doc/libtool.texi: Document new LT_SYS_LIBRARY_PATH.
* doc/notes.texi: Likewise.
---
 Makefile.am  | 13 
 build-aux/ltmain.in  |  7 +++
 build-aux/m4-expand  | 18 
 build-aux/m4-extract | 17 +++
 doc/libtool.texi | 20 ++
 doc/notes.texi   | 11 +-
 m4/libtool.m4| 58 +++-
 7 files changed, 125 insertions(+), 19 deletions(-)
 create mode 100755 build-aux/m4-expand
 create mode 100755 build-aux/m4-extract

diff --git a/Makefile.am b/Makefile.am
index f1b7ead..f7a2078 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -54,7 +54,7 @@ rebuild = rebuild=:; revision=`$(lt__cd) $(srcdir)  $(git_version_gen) | $(SED
 # Bootstrap. #
 # -- #
 
-SCRIPT_ENV	= GREP='$(GREP)' SED='$(SED)'
+SCRIPT_ENV	= GREP='$(GREP)' SED='$(SED)' AWK='$(AWK)'
 
 build_scripts	= $(srcdir)/$(aux_dir)/announce-gen \
 		  $(srcdir)/$(aux_dir)/do-release-commit-and-tag \
@@ -86,16 +86,20 @@ ltmain_in	= $(srcdir)/$(aux_dir)/ltmain.in
 libtool_m4	= $(srcdir)/$(macro_dir)/libtool.m4
 ltversion_in	= $(srcdir)/$(macro_dir)/ltversion.in
 ltversion_m4	= $(srcdir)/$(macro_dir)/ltversion.m4
+m4_expand	= $(srcdir)/$(aux_dir)/m4-expand
+m4_extract	= $(srcdir)/$(aux_dir)/m4-extract
 options_parser	= $(srcdir)/$(aux_dir)/options-parser
 
 EXTRA_DIST += $(extract_trace) $(funclib_sh) $(inline_source) \
 		  $(libtoolize_in) $(ltmain_in) $(ltmain_sh) \
-		  $(ltversion_in) $(ltversion_m4) $(options_parser)
+		  $(ltversion_in) $(ltversion_m4) $(options_parser) \
+		  $(m4_extract) $(m4_expand)
 
 ## These are the replacements that need to be made at bootstrap time,
 ## because they must be static in distributed files, and not accidentally
 ## changed by configure running on the build machine.
 bootstrap_edit  = $(SED) \
+		  -e 's|@libtool_m4\@|$(libtool_m4)|g' \
 		  -e 's|@MACRO_VERSION\@|$(VERSION)|g' \
 		  -e s|@MACRO_REVISION\@|$$revision|g \
 		  -e s|@MACRO_SERIAL\@|$$serial|g \
@@ -162,8 +166,9 @@ $(ltmain_sh): 

Tune rpath by env. variable (was: Use ldconfig to generate sys_lib_dlsearch_path_spec)

[Pavel Raiskup]

On Monday 08 of December 2014 15:55:22 Gary V. Vaughan wrote:
 [..]
   LT_SYS_LIBRARY_PATH
 [..]

That LT_SYS_LIBRARY_PATH concept sounds good, thanks!

  * should I use AC_ARG_VAR rather?

 I'm not entirely clear yet exactly when the extra directories are
 important...

 It seems not that useful for it to be only at configure time, since we
 also want our installed libtool to honor changes in the environment.  Or
 do we bake the configure time setting into the installed and client
 project generated libtool always?

 If at configure time only, AC_ARG_VAR is sensible, but at libtool time
 seems more flexible, at the expense of being centralised in config.site.

 WDYT?

That makes sense.  Ideally, we could make the variable ./configure time
sensitive and also sensitive to environment.  Something like
: ${LT_SYS_LIBRARY_PATH=/configure/time/detected/LT_SYS_LIBRARY_PATH}?

 If $host_cpu heuristics are an improvement, then I don't think it hurts
 to leave them, so that LT_SYS_LIBRARY_PATH is not always necessary.  Is
 it the case that adding /lib64:/usr/lib64 is a pessimisation in some
 case?

Cowardly, I know.., thats not what I initially said, sorry.  But more I
read the history of this issue, more unsure I'm.  I'm not 100% against
that so don't take me too seriously:

It has been proven it works for Fedora and it does not break Debian [1]
(though that patch does not follow debian's policy).  On the other hand,
taking into account there can be /usr/lib32-like GNU/Linux distributions..
or just user setups..

If there are reasons to not apply this unconditionally at least for
GNU/Linux (and there surely are), I'm not sure whether we shouldn't
rather avoid such 'linux*'  subset(64-bit arches) only conditions
(because reasons for not to do it must be the same).  And that can result
in more tricky debugging scenarios.

[1] https://wiki.debian.org/RpathIssue

Pavel


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Tune rpath by env. variable (was: Use ldconfig to generate sys_lib_dlsearch_path_spec)

[Gary V. Vaughan]

[remembered to remove Orion from the Cc: list this time as requested]

Hi Pavel,

 On 9 Dec 2014, at 08:14, Pavel Raiskup prais...@redhat.com wrote:
 
 On Monday 08 of December 2014 15:55:22 Gary V. Vaughan wrote:
 [..]
  LT_SYS_LIBRARY_PATH
 [..]
 
 That LT_SYS_LIBRARY_PATH concept sounds good, thanks!
 
 * should I use AC_ARG_VAR rather?
 
 I'm not entirely clear yet exactly when the extra directories are
 important...
 
 It seems not that useful for it to be only at configure time, since we
 also want our installed libtool to honor changes in the environment.  Or
 do we bake the configure time setting into the installed and client
 project generated libtool always?
 
 If at configure time only, AC_ARG_VAR is sensible, but at libtool time
 seems more flexible, at the expense of being centralised in config.site.
 
 WDYT?
 
 That makes sense.  Ideally, we could make the variable ./configure time
 sensitive and also sensitive to environment.  Something like
 : ${LT_SYS_LIBRARY_PATH=/configure/time/detected/LT_SYS_LIBRARY_PATH}?

Great. The only wrinkle I can see here is that we need the function for
injecting lt_cv_sys_dlsearch_path into the dangling colon in the runtime
LT_SYS_LIBRARY_PATH shared between libtool.m4 and ltmain.in. I haven't
double checked, but I'm certain we have functions that are shared like this
without duplicated code already we can copy from.

 If $host_cpu heuristics are an improvement, then I don't think it hurts
 to leave them, so that LT_SYS_LIBRARY_PATH is not always necessary.  Is
 it the case that adding /lib64:/usr/lib64 is a pessimisation in some
 case?
 
 Cowardly, I know.., thats not what I initially said, sorry.  But more I
 read the history of this issue, more unsure I'm.  I'm not 100% against
 that so don't take me too seriously:
 
 It has been proven it works for Fedora and it does not break Debian [1]
 (though that patch does not follow debian's policy).  On the other hand,
 taking into account there can be /usr/lib32-like GNU/Linux distributions..
 or just user setups..
 
 If there are reasons to not apply this unconditionally at least for
 GNU/Linux (and there surely are), I'm not sure whether we shouldn't
 rather avoid such 'linux*'  subset(64-bit arches) only conditions
 (because reasons for not to do it must be the same).  And that can result
 in more tricky debugging scenarios.
 
 [1] https://wiki.debian.org/RpathIssue
 
 Pavel

Okay, I agree with your arguments, and will revert the hardcoded settings
before applying your patch.

Cheers,
Gary V. Vaughan (gary AT gnu DOT org)

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Tune rpath by env. variable

[Pavel Raiskup]

On Tuesday 09 of December 2014 11:53:22 Gary V. Vaughan wrote:
  That makes sense.  Ideally, we could make the variable ./configure time
  sensitive and also sensitive to environment.  Something like
  : ${LT_SYS_LIBRARY_PATH=/configure/time/detected/LT_SYS_LIBRARY_PATH}?
 
 Great. The only wrinkle I can see here is that we need the function for
 injecting lt_cv_sys_dlsearch_path into the dangling colon in the runtime
 LT_SYS_LIBRARY_PATH shared between libtool.m4 and ltmain.in.
 I haven't double checked, but I'm certain we have functions that are
 shared like this without duplicated code already we can copy from.

Ouch, thats quite complicated.

If you think about new LT_SYS_LIBRARY_PATH like its just something which
enhances 'sys_dlsearch_path_spec', then that code-share should not be
necessary?  There would be two coexisting variables - and only libtool
binary (ltmain.sh) should be able to deal with that.  LT_SYS_LIBRARY_PATH
could be just overwritten at libtool time if defined in environment.  But
all that dependencies are quite confusing so I can be wrong..

.. however, maybe you think that quite problematic the share with ltdl.m4
(via sys_lib_dlsearch_path).  That is ?clearly? configure-time only
variable which generates variable LT_DLSEARCH_PATH in c-header file.

In this case, using LT_SYS_LIBRARY_PATH at runtime would differentiate
LT_DLSEARCH_PATH with libtool's 'sys_dlsearch_path_spec' ... and could
cause confusion later.

Hmm, due to its requirments, it seems like LT_SYS_LIBRARY_PATH should be
AC_ARG_VAR-ed.  The system-wide libtool should be pre-configured correctly
according to system's needs anyway.  WDYT?

Pavel


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Tune rpath by env. variable

[Gary V. Vaughan]

 On Dec 9, 2014, at 1:53 PM, Pavel Raiskup prais...@redhat.com wrote:
 
 On Tuesday 09 of December 2014 11:53:22 Gary V. Vaughan wrote:
 That makes sense.  Ideally, we could make the variable ./configure time
 sensitive and also sensitive to environment.  Something like
 : ${LT_SYS_LIBRARY_PATH=/configure/time/detected/LT_SYS_LIBRARY_PATH}?
 
 Great. The only wrinkle I can see here is that we need the function for
 injecting lt_cv_sys_dlsearch_path into the dangling colon in the runtime
 LT_SYS_LIBRARY_PATH shared between libtool.m4 and ltmain.in.
 I haven't double checked, but I'm certain we have functions that are
 shared like this without duplicated code already we can copy from.
 
 Ouch, thats quite complicated.
 
 If you think about new LT_SYS_LIBRARY_PATH like its just something which
 enhances 'sys_dlsearch_path_spec', then that code-share should not be
 necessary?  There would be two coexisting variables - and only libtool
 binary (ltmain.sh) should be able to deal with that.  LT_SYS_LIBRARY_PATH
 could be just overwritten at libtool time if defined in environment.  But
 all that dependencies are quite confusing so I can be wrong..

Hmmm... I think you're right.

 .. however, maybe you think that quite problematic the share with ltdl.m4
 (via sys_lib_dlsearch_path).  That is ?clearly? configure-time only
 variable which generates variable LT_DLSEARCH_PATH in c-header file.

We will probably need to promote the macros required to support that to
libtool.m4 now that we care about setting sys_dlsearch_path_spec, without
requiring every package to use ltdl.m4.

 In this case, using LT_SYS_LIBRARY_PATH at runtime would differentiate
 LT_DLSEARCH_PATH with libtool's 'sys_dlsearch_path_spec' ... and could
 cause confusion later.

It's a lot of variables, but technically it seems sound to me.

 Hmm, due to its requirments, it seems like LT_SYS_LIBRARY_PATH should be
 AC_ARG_VAR-ed.  The system-wide libtool should be pre-configured correctly
 according to system's needs anyway.  WDYT?

I think it would be easier to have both installed and in-tree libtool
respect LT_SYS_LIBRARY_PATH, otherwise we have to edit the installed script
to take out the substitution code.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108637] libtool adds -rpath to staging directory

[anonymous]

Follow-up Comment #2, sr #108637 (project libtool):

As pointed out by Roumen Petrov, overriding the sys_lib_dlsearch_path_spec
variable gets the behavior I want. In specific, passing
lt_cv_sys_lib_dlsearch_path_spec=... with a list of paths to ./configure gets
them excluded from the default -rpath.

http://lists.gnu.org/archive/html/libtool/2014-08/msg4.html

More follow up on this issue here:

http://lists.gnu.org/archive/html/libtool/2014-12/msg3.html

I think this one can be closed now.


___

Reply to this item at:

  http://savannah.gnu.org/support/?108637

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

[Filipe Brandenburger]

Hi Gary, Bob,

Thanks for your feedback!

In the end, I found Roumen Petrov replied to the list indicating that
setting lt_cv_sys_lib_dlsearch_path_spec when calling configure might
be able to solve this and indeed it did.

http://lists.gnu.org/archive/html/libtool/2014-08/msg4.html

By passing lt_cv_sys_lib_dlsearch_path_spec=${stagedir}/usr/lib (I'm
not linking to anything under the system's /usr/lib so it's OK for me
to omit it) I managed to get it not to add that directory to the
rpath.

I wish that this sys_lib_dlsearch_path_spec variable was better
documented in libtool's documentation... I'd be happy to try to
contribute but unfortunately I don't think I understand them well
enough to give them a good description... Let me know if you think I
could help with it anyhow.

Replying to some of your comments:

On Fri, Nov 28, 2014 at 10:37 AM, Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
 I am not sure what OS is being discussed here since it was never mentioned.

This is on GNU/Linux and I'm using either the GNU ld and the gold
linker (ideally I want both to work.) Both seem to support -rpath and
-rpath-link but that doesn't seem to be part of the problem (as just
adding the directory to lt_cv_sys_lib_dlsearch_path_spec was enough to
solve it.)

 GNU ld on GNU/Linux has these options:

   -rpath PATH Set runtime shared library search path
   -rpath-link PATHSet link time shared library search path

 Notice that one is the path used for the installed library and the other is
 for linking.  It is more correct to use -rpath-link for libraries which are
 not in their final resting place.  However, the libraries do remember the
 -rpath-link option which was used when they were linked, and libraries
 linked with them inherit the option (to support cascading linkage).

So in my actual case I'm installing libraries to a ${GNU_PLATFORM}
subdirectory of /usr/lib where ${GNU_PLATFORM} is set to the GNU
triplet.

So, I'm actually passing ./configure both the
lt_cv_sys_lib_dlsearch_path_spec=${stagedir}/usr/lib/${GNU_PLATFORM}
variable and also LDFLAGS=-Wl,-rpath,/usr/lib/${GNU_PLATFORM}
-Wl,-rpath-link,${stagedir}/usr/lib/${GNU_PLATFORM} which gets it to
*add* the -rpath I want and to link to the libraries in the correct
location.

 I don't think that linking against libraries in DESTDIR is portable. DESTDIR
 should be considered an install/copy-only option to support packaging.

Well, in my use case I'm often/usually cross compiling so having the
final libraries installed under /usr/lib is not really an option... It
seems that lt_cv_sys_lib_dlsearch_path_spec solved the issue for me,
but I'm not 100% positive how portable that is, if you can think of
some reasons why this is not a good fix and if there's a cleaner way
to accomplish this then please let me know.

Cheers,
Filipe

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

[Bob Friesenhahn]

On Tue, 2 Dec 2014, Filipe Brandenburger wrote:



I don't think that linking against libraries in DESTDIR is portable. DESTDIR
should be considered an install/copy-only option to support packaging.


Well, in my use case I'm often/usually cross compiling so having the
final libraries installed under /usr/lib is not really an option... It
seems that lt_cv_sys_lib_dlsearch_path_spec solved the issue for me,
but I'm not 100% positive how portable that is, if you can think of
some reasons why this is not a good fix and if there's a cleaner way
to accomplish this then please let me know.


This solves the problem (automatic addition of -rpath) caused by 
libtool on GNU/Linux.  It is not truely portable since it can not 
solve automatic tool behavior on other operating systems.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

[Gary V. Vaughan]

[[former maintainers removed from Cc:]]

Hi Filipe,

 On Aug 26, 2014, at 5:17 AM, Filipe Brandenburger filbran...@google.com 
 wrote:
 
 Friendly ping?
 
 +cc the libtool maintainers according to http://www.gnu.org/software/libtool/
 
 If this is indeed a bug, I'd be willing to invest some time in trying
 to fix it, but I'd need some pointers on what would be the proper way
 to fix it...

Currently, I believe libtool uses the presence of -rpath to determine
whether it should try to link a shared archive (at least in my very
cursory testing, I only get static archives if I miss the -rpath argument).

Also, the use of -rpath is fairly deeply ingrained into the way that
automake generated rules call libtool, so if you want to tackle a complete
patch, there will be at least some work there too.

I suspect that there is a fairly good chance that the -rpath requirement came
about because some supported architectures refuse to build shared libraries
without it, but I have access to only a tiny fraction of the architectures that
libtool supports so I can't test my hypothesis.

All of that said, I do agree that it is a bug for libtool not to respect
the value of $DESTDIR when it assembles the rpath directories.  I would think
a patch should be relatively straight forward though - find the parts of
ltmain.in that assemble the link line with the rpath directories, and strip
out any $DESTDIR prefixes from those paths before handing off to the linker.

 I really think libtool should be creating a wrapper script and not a
 binary with an rpath pointing to the stage directory, am I wrong?

No, I agree with you.

And I'd be happy to help you massage a suitable patch into something I can
apply to the repository.

 Cheers,
 Filipe

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

 On Tue, Aug 19, 2014 at 4:33 PM, Filipe Brandenburger
 filbran...@google.com wrote:
 Hi,
 
 I'm trying to link binaries to libraries that are not installed on the
 system, but just unpacked to a staging directory.
 
 Consider this (real) example:
 
 1) Build expat with --libdir=/usr/lib/${platform}
 2) Install expat with make install DESTDIR=${stagedir}
 3) Configure dbus with -L${stagedir}/usr/lib/${platform} where it
 will find expat now, and -rpath /usr/lib/${platform} where it will
 find expat at real runtime when both are installed.
 4) Build expat
 
 The problem is that ${stagedir} is leaking and the resulting
 dbus-daemon gets both /usr/lib/${platform} and
 ${stagedir}/usr/lib/${platform} added to it...
 
 I tried working around it by passing --with-sysroot=${stagedir} to the
 dbus configure, but unfortunately that didn't work...
 
 Do you have a suggestion of something I could do to accomplish what
 I'm trying to accomplish?
 
 Is this a libtool bug?
 
 Any suggestions of workarounds?
 
 (I also filed a bug at
 http://savannah.gnu.org/support/index.php?108637 in case this is
 actually a libtool bug.)
 
 Thanks in advance!
 Filipe


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

[Bob Friesenhahn]

On Fri, 28 Nov 2014, Gary V. Vaughan wrote:


Also, the use of -rpath is fairly deeply ingrained into the way that
automake generated rules call libtool, so if you want to tackle a complete
patch, there will be at least some work there too.

I suspect that there is a fairly good chance that the -rpath requirement came
about because some supported architectures refuse to build shared libraries
without it, but I have access to only a tiny fraction of the architectures that
libtool supports so I can't test my hypothesis.

All of that said, I do agree that it is a bug for libtool not to respect
the value of $DESTDIR when it assembles the rpath directories.  I would think
a patch should be relatively straight forward though - find the parts of
ltmain.in that assemble the link line with the rpath directories, and strip
out any $DESTDIR prefixes from those paths before handing off to the linker.


I really think libtool should be creating a wrapper script and not a
binary with an rpath pointing to the stage directory, am I wrong?


No, I agree with you.


I am not sure what OS is being discussed here since it was never 
mentioned.


GNU ld on GNU/Linux has these options:

  -rpath PATH Set runtime shared library search path
  -rpath-link PATHSet link time shared library search path

Notice that one is the path used for the installed library and the 
other is for linking.  It is more correct to use -rpath-link for 
libraries which are not in their final resting place.  However, the 
libraries do remember the -rpath-link option which was used when they 
were linked, and libraries linked with them inherit the option (to 
support cascading linkage).


Some systems hard code the linker run-time path and this may be 
necessary in order for libtool to support executing built uninstalled 
binaries for testing.  That is why libtool supports a 'finish' mode so 
make sure that finally installed executables contain the correct 
embedded path information.


I don't think that linking against libraries in DESTDIR is portable. 
DESTDIR should be considered an install/copy-only option to support 
packaging.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

how does libtool order -Wl,--rpath?

[Myles C. Maxfield]

Sorry to resurrect an old thread, but I just ran into the problem at
https://lists.gnu.org/archive/html/libtool/2003-07/msg00062.html. Does
anyone know libtool handles this?

I'm trying to understand how a particular library that's installed on my
system works, so I compiled a debug version and installed it into a folder
in my home directory. However, whenever I use libtool to try to link with
my debug version, it seems to always put /usr/local/lib at the front of the
rpath. Is there some way to enforce ordering of the -Wl,-rpath arguments
that libtool emits? I should note that all the necessary folders are in the
rpath arguments; they're just in the wrong order.

I know I can solve my problem with LD_LIBRARY_PATH, but I'm trying to find
a solution that doesn't require this.

Thanks,
Myles
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

[Filipe Brandenburger]

Friendly ping?

+cc the libtool maintainers according to http://www.gnu.org/software/libtool/

If this is indeed a bug, I'd be willing to invest some time in trying
to fix it, but I'd need some pointers on what would be the proper way
to fix it...

I really think libtool should be creating a wrapper script and not a
binary with an rpath pointing to the stage directory, am I wrong?

Cheers,
Filipe


On Tue, Aug 19, 2014 at 4:33 PM, Filipe Brandenburger
filbran...@google.com wrote:
 Hi,

 I'm trying to link binaries to libraries that are not installed on the
 system, but just unpacked to a staging directory.

 Consider this (real) example:

 1) Build expat with --libdir=/usr/lib/${platform}
 2) Install expat with make install DESTDIR=${stagedir}
 3) Configure dbus with -L${stagedir}/usr/lib/${platform} where it
 will find expat now, and -rpath /usr/lib/${platform} where it will
 find expat at real runtime when both are installed.
 4) Build expat

 The problem is that ${stagedir} is leaking and the resulting
 dbus-daemon gets both /usr/lib/${platform} and
 ${stagedir}/usr/lib/${platform} added to it...

 I tried working around it by passing --with-sysroot=${stagedir} to the
 dbus configure, but unfortunately that didn't work...

 Do you have a suggestion of something I could do to accomplish what
 I'm trying to accomplish?

 Is this a libtool bug?

 Any suggestions of workarounds?

 (I also filed a bug at
 http://savannah.gnu.org/support/index.php?108637 in case this is
 actually a libtool bug.)

 Thanks in advance!
 Filipe

___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108637] libtool adds -rpath to staging directory

[anonymous]

Follow-up Comment #1, sr #108637 (project libtool):

Small correction, step #4 should read Build dbus.

If someone could confirm this is indeed a bug and whether there's a good
workaround for it that would be great.

Thinking about it, my impression is that bintest should actually be a wrapper
shell script with the actual binary under .libs/bintest and make install
should possibly relink it without the rpath to the staging directory...

I'd be happy to contribute code, but I'd need some pointers on where the issue
is and what would be an acceptable way to fix this.

Thanks!
Filipe


___

Reply to this item at:

  http://savannah.gnu.org/support/?108637

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

[Roumen Petrov]

Hi Filipe,

Filipe Brandenburger wrote:

Hi,

I'm trying to link binaries to libraries that are not installed on the
system, but just unpacked to a staging directory.

[SNIP]


Is this a libtool bug?

Any suggestions of workarounds?

(I also filed a bug at
http://savannah.gnu.org/support/index.php?108637  in case this is
actually a libtool bug.)


Libtool exclude directories from RPATH if path is listed in 
sys_lib_dlsearch_path_spec - list of space separated directories.



Variable sys_lib_dlsearch_path_spec is generated from a libtool macro. 
On linux with FSF libtool version value start with /lib /usr/lib and 
existing directories from /etc/ld.so.conf .



After configuration user could check current value with command:
$ ./libtool --config | grep sys_lib_dlsearch_path_spec
( I assume that package build process generate libtool script in build 
directory )



You could use lt_cv_sys_lib_dlsearch_path_spec to override it at 
configure time.

.../configure  \
...
lt_cv_sys_lib_dlsearch_path_spec=ORIGINAL VALUE STAGING_PATH
...


Regards
Roumen Petrov


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108637] libtool adds -rpath to staging directory

[anonymous]

URL:
  http://savannah.gnu.org/support/?108637

 Summary: libtool adds -rpath to staging directory
 Project: GNU Libtool
Submitted by: None
Submitted on: Tue 19 Aug 2014 11:30:33 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: filbran...@google.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

Hi,

I'm trying to link binaries to libraries that are not installed on the system,
but just unpacked to a staging directory.

Consider this (real) example:

1) Build expat with --libdir=/usr/lib/${platform}
2) Install expat with make install DESTDIR=${stagedir}
3) Configure dbus with -L${stagedir}/usr/lib/${platform} where it will find
expat now, and -rpath /usr/lib/${platform} where it will find expat at real
runtime when both are installed.
4) Build expat

The problem is that ${stagedir} is leaking and the resulting dbus-daemon gets
both /usr/lib/${platform} *and* ${stagedir}/usr/lib/${platform} added to
it...

I tried working around it by passing --with-sysroot=${stagedir} to the dbus
configure, but unfortunately that didn't work...

I wrote a small reproducer that seems to illustrate the issue, I tried it with
latest libtool from git (commit ac180507c123469d0fe9b25437d459af24b3f789) and
I still have the same problem.

$ libtool_rpath/reproduce.sh
...
=== RPATH of bintest:
 0x000f (RPATH)  Library rpath:
[/path/to/libtool_rpath/destdir/usr/lib/platform:/usr/lib/platform]

Do you have a suggestion of something I could do to accomplish what I'm trying
to accomplish?

Is this a libtool bug?

Any suggestions of workarounds?

Thanks!
Filipe




___

File Attachments:


---
Date: Tue 19 Aug 2014 11:30:33 PM UTC  Name: libtool_rpath.tgz  Size: 912B  
By: None
Script to reproduce this bug.
http://savannah.gnu.org/support/download.php?file_id=31921

___

Reply to this item at:

  http://savannah.gnu.org/support/?108637

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

Trying to get libtool not to add -rpath, since libs are only in a staging directory

[Filipe Brandenburger]

Hi,

I'm trying to link binaries to libraries that are not installed on the
system, but just unpacked to a staging directory.

Consider this (real) example:

1) Build expat with --libdir=/usr/lib/${platform}
2) Install expat with make install DESTDIR=${stagedir}
3) Configure dbus with -L${stagedir}/usr/lib/${platform} where it
will find expat now, and -rpath /usr/lib/${platform} where it will
find expat at real runtime when both are installed.
4) Build expat

The problem is that ${stagedir} is leaking and the resulting
dbus-daemon gets both /usr/lib/${platform} and
${stagedir}/usr/lib/${platform} added to it...

I tried working around it by passing --with-sysroot=${stagedir} to the
dbus configure, but unfortunately that didn't work...

Do you have a suggestion of something I could do to accomplish what
I'm trying to accomplish?

Is this a libtool bug?

Any suggestions of workarounds?

(I also filed a bug at
http://savannah.gnu.org/support/index.php?108637 in case this is
actually a libtool bug.)

Thanks in advance!
Filipe

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: rpath configuration

[Bob Rossi]

On Fri, May 24, 2013 at 07:15:50PM -0400, Bob Rossi wrote:
 I'm building a program that links against boost with libtool.
 
 The boost library is installed on the system and is a shared library.
 
 When i run my program ./test_suite I get,
 $ ./test_suite 
 .../build/.libs/lt-test_suite: error while loading shared libraries: 
 libboost_filesystem.so.1.53.0: cannot open shared object file: No such file 
 or directory
 
 My Makefile looks like,
 
 noinst_PROGRAMS += test_suite
 
 test_suite_SOURCES = \
 src/progs/test_suite/fixture.cpp \
 src/progs/test_suite/main.cpp
 
 test_suite_CPPFLAGS = \
 @BOOST_CPPFLAGS@
 
 test_suite_LDFLAGS = \
 @BOOST_LDFLAGS@
 
 test_suite_LDADD = \
 @BOOST_LIBS@
 
 Where the boost variables are,
 BOOST_CPPFLAGS = -IBOOSTDIR/boost_1_53_0_prefix/include
 BOOST_LDFLAGS = -LBOOSTDIR/boost_1_53_0_prefix/lib
 BOOST_LIBS = -lboost_filesystem -lboost_system
 
 I have a few questions.
 
 For linking against system libraries, is using LDFLAGS and LDADD
 appropriate the way I have done it?
 
 Is it my responsibility to add the -rpath libtool option to include
 BOOSTDIR/boost_1_53_0_prefix/lib?
 
 Should I be setting LD_LIBRARY_PATH when running from the build
 directory?
 
 I notice that when I link against libtool created libraries in the
 same Makefile I don't see this issue at all.

Ping.

Is this the active libtool mailing list?

Bob

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: rpath configuration

[Gary V. Vaughan]

Hi Bob,

On 31 May 2013, at 08:28, Bob Rossi b...@brasko.net wrote:
 Ping.
 
 Is this the active libtool mailing list?


Yes it is.  If you don't get a reply it means that nobody who read your
request is confident about the right answer.

In my case, I only know just enough about C++ to avoid it at all costs,
which is why I didn't respond initially :)

 On Fri, May 24, 2013 at 07:15:50PM -0400, Bob Rossi wrote:
 I'm building a program that links against boost with libtool.
 
 The boost library is installed on the system and is a shared library.
 
 When i run my program ./test_suite I get,
 $ ./test_suite 
 .../build/.libs/lt-test_suite: error while loading shared libraries: 
 libboost_filesystem.so.1.53.0: cannot open shared object file: No such file 
 or directory
 
 My Makefile looks like,
 
 noinst_PROGRAMS += test_suite

To avoid building the test_suite unless invoked with `make check` you
can use:

  check_PROGRAMS += test_suite

 test_suite_SOURCES = \
src/progs/test_suite/fixture.cpp \
src/progs/test_suite/main.cpp
 
 test_suite_CPPFLAGS = \
@BOOST_CPPFLAGS@
 
 test_suite_LDFLAGS = \
@BOOST_LDFLAGS@
 
 test_suite_LDADD = \
@BOOST_LIBS@
 
 Where the boost variables are,
 BOOST_CPPFLAGS = -IBOOSTDIR/boost_1_53_0_prefix/include

Not literally -IBOOSTDIR I trust.  You probably need something more
like:

  -I $(BOOSTDIR)/...

 BOOST_LDFLAGS = -LBOOSTDIR/boost_1_53_0_prefix/lib

Likewise.

 BOOST_LIBS = -lboost_filesystem -lboost_system
 
 I have a few questions.
 
 For linking against system libraries, is using LDFLAGS and LDADD
 appropriate the way I have done it?

I don't see any reference to libtool or a libtool archive here, so how
does Automake know it should be linking with libtool in this case?

Unfortunately, some distributions remove the .la files from system
directories that libtool uses to figure out the correct linker
invocation.  If your system is missing files such as:

  $(BOOSTDIR)/boost_1_53_0_prefix/lib/boost_system.la

...then you have to force Automake to use libtool.  Check the Automake
manual for details of how to set test_suite_LINK appropriately.

Also, you need to add the CXX tag to LT_INIT to incorporate C++ settings
into your generated project libtool script, if you didn't do that
already.


 Is it my responsibility to add the -rpath libtool option to include
 BOOSTDIR/boost_1_53_0_prefix/lib?

Libtool's -rpath option is for specifying the target library's install
destination, not for adding the location of deplibs.  Automake will set
-rpath for you, so there's almost never any need to specify it manually.

 Should I be setting LD_LIBRARY_PATH when running from the build
 directory?

No, libtool will take care of that (LD_LIBRARY_PATH is just one spelling
of that variable for linux and a few other Unices) automatically.

 I notice that when I link against libtool created libraries in the
 same Makefile I don't see this issue at all.

Is that because Automake can tell you want to link using libtool, but in
the case of the Makefile.am you paste above, Automake thinks you want to
link with g++?

Please show the output from running make to demonstrate what you are
actually seeing.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: rpath configuration

[Gary V. Vaughan]

Hi Bob,

On 31 May 2013, at 09:57, Gary V. Vaughan g...@gnu.org wrote:
 On 31 May 2013, at 08:28, Bob Rossi b...@brasko.net wrote:
 On Fri, May 24, 2013 at 07:15:50PM -0400, Bob Rossi wrote:
 I'm building a program that links against boost with libtool.
 
 The boost library is installed on the system and is a shared library.
 
 When i run my program ./test_suite I get,
 $ ./test_suite 
 .../build/.libs/lt-test_suite: error while loading shared libraries: 
 libboost_filesystem.so.1.53.0: cannot open shared object file: No such file 
 or directory

Didn't notice this on first blush, sorry.  It seems you are getting a libtool
link invocation out of Automake after all, so you can probably ignore most of
my earlier reply.

This error seems to indicate that the ./test_suite wrapper script is not
setting LD_LIBRARY_PATH correctly.  Take a look inside that script to see what
is going on, and get some clues of what went wrong with the link.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: rpath configuration

[Dan Nicholson]

On May 30, 2013 8:03 PM, Gary V. Vaughan g...@gnu.org wrote:

 Hi Bob,

 On 31 May 2013, at 09:57, Gary V. Vaughan g...@gnu.org wrote:
  On 31 May 2013, at 08:28, Bob Rossi b...@brasko.net wrote:
  On Fri, May 24, 2013 at 07:15:50PM -0400, Bob Rossi wrote:
  I'm building a program that links against boost with libtool.
 
  The boost library is installed on the system and is a shared library.
 
  When i run my program ./test_suite I get,
  $ ./test_suite
  .../build/.libs/lt-test_suite: error while loading shared libraries:
libboost_filesystem.so.1.53.0: cannot open shared object file: No such file
or directory

 Didn't notice this on first blush, sorry.  It seems you are getting a
libtool
 link invocation out of Automake after all, so you can probably ignore
most of
 my earlier reply.

 This error seems to indicate that the ./test_suite wrapper script is not
 setting LD_LIBRARY_PATH correctly.  Take a look inside that script to see
what
 is going on, and get some clues of what went wrong with the link.

Or do ./libtool --mode=run your command line to have libtool set the
appropriate paths for you.

Dan
___
https://lists.gnu.org/mailman/listinfo/libtool

rpath configuration

[Bob Rossi]

Hi,

I'm building a program that links against boost with libtool.

The boost library is installed on the system and is a shared library.

When i run my program ./test_suite I get,
$ ./test_suite 
.../build/.libs/lt-test_suite: error while loading shared libraries: 
libboost_filesystem.so.1.53.0: cannot open shared object file: No such file or 
directory

My Makefile looks like,

noinst_PROGRAMS += test_suite

test_suite_SOURCES = \
src/progs/test_suite/fixture.cpp \
src/progs/test_suite/main.cpp

test_suite_CPPFLAGS = \
@BOOST_CPPFLAGS@

test_suite_LDFLAGS = \
@BOOST_LDFLAGS@

test_suite_LDADD = \
@BOOST_LIBS@

Where the boost variables are,
BOOST_CPPFLAGS = -IBOOSTDIR/boost_1_53_0_prefix/include
BOOST_LDFLAGS = -LBOOSTDIR/boost_1_53_0_prefix/lib
BOOST_LIBS = -lboost_filesystem -lboost_system

I have a few questions.

For linking against system libraries, is using LDFLAGS and LDADD
appropriate the way I have done it?

Is it my responsibility to add the -rpath libtool option to include
BOOSTDIR/boost_1_53_0_prefix/lib?

Should I be setting LD_LIBRARY_PATH when running from the build
directory?

I notice that when I link against libtool created libraries in the
same Makefile I don't see this issue at all.

Thanks,
Bob

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool, rpath, and libGL.so

[Peter O'Gorman]

On 11/29/2011 11:48 PM, Adam Mercer wrote:

On Mon, Nov 28, 2011 at 23:30, Andy Spencerandy753...@gmail.com  wrote:


This seems to be caused by libtool adding a -rpath flag which forces the
application to use the /usr/lib64 version provided by mesa even though
ld.so.conf has been properly configured to use the nvidia version.


I raised this question a week or so ago and the workaround suggested was to set:

lt_cv_sys_lib_dlsearch_path_spec=/lib64 /usr/lib64


Does anyone want to try again?

http://lists.gnu.org/archive/html/libtool-patches/2010-11/msg00027.html

I only have red hat like distros, so if someone could update the patch 
and look at other distros that'd be great.


Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool, rpath, and libGL.so

[Adam Mercer]

On Wed, Dec 7, 2011 at 23:26, Peter O'Gorman pe...@pogma.com wrote:

 Does anyone want to try again?

 http://lists.gnu.org/archive/html/libtool-patches/2010-11/msg00027.html

 I only have red hat like distros, so if someone could update the patch and
 look at other distros that'd be great.

I can have a play, I need to support Scientific Linux 6, Debian
Squeeze, and Mac OS X (Snow Leopard and Lion) for one of my projects
(one which has been hit by this problem). It may take me a while as
I'm in the middle of preparing a new release of our software.

Cheers

Adam

___
https://lists.gnu.org/mailman/listinfo/libtool

Libtool, rpath, and libGL.so

[Andy Spencer]

I'm building a library of mine on Fedora 64-bit and running into some
problems. I'm running configure as follows:

  ./configure --prefix=/usr --libdir=/usr/lib64

The problem is that the wrong version of libGL.so is being used at
runtime. The correct version is /usr/lib64/nvidia/libGL.so.* but any
application built against my library uses /usr/lib64/libGL.so.* instead.

This seems to be caused by libtool adding a -rpath flag which forces the
application to use the /usr/lib64 version provided by mesa even though
ld.so.conf has been properly configured to use the nvidia version.

I can fix the problem for other programs by manually deleting all the
.la files provided by my library after I install it. However, my library
also comes with a demo program which is compiled along side the library
and I don't know how to make that use the correct version of libGL.

Is there any way to prevent the demo program from getting build with a
rpath, or are there any other ways to fix this?


pgpKhH0XiIbSJ.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool, rpath, and libGL.so

[Adam Mercer]

On Mon, Nov 28, 2011 at 23:30, Andy Spencer andy753...@gmail.com wrote:

 This seems to be caused by libtool adding a -rpath flag which forces the
 application to use the /usr/lib64 version provided by mesa even though
 ld.so.conf has been properly configured to use the nvidia version.

I ran into essentially the same problem on Scientific Linux 6,
essentially libtool sometimes incorrectly determines the system
library paths. I imagine if you look at the sys_lib_dlsearch_path_spec
variable within the libtool script it will state that /usr/lib is a
system library path and not /usr/lib64. Therefore libtool will assume
it needs to pass /usr/lib64 on the command line thereby leading to
this linking problem.

I raised this question a week or so ago and the workaround suggested was to set:

lt_cv_sys_lib_dlsearch_path_spec=/lib64 /usr/lib64

during configure, this overrides the paths found by libtool and solved
the linking problem for me. Unfortunately this is a hack and ignores
any paths specified in ld.so.conf so you may need to tweak this
accordingly.

Hope this is of some help.

Cheers

Adam

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool sysroot RPATH problems

[Richard Purdie]

Hi Ralf,

Thanks for the reply.

On Thu, 2011-01-13 at 08:24 +0100, Ralf Wildenhues wrote:
 * Richard Purdie wrote on Wed, Jan 12, 2011 at 12:06:13AM CET:
  Firstly, for the first time ever for us, it appears libtool is no longer
  relinking our libraries at install time.
 
 That's weird, I don't think the sysroot feature should've caused this
 change.  Not quite sure though.
 
  This is welcome as we're cross
  compiling to a sysroot and we'd never want to actually run them in situ
  so this could probably save us some build time. It does however mean we
  never go for a relink step so we're hitting codepaths and issues that
  I've never seen. For reference, we always used to set installed=no in
  our staged libraries prior to sysroot support since this let us hack
  around the lack of sysroot support easier.
  
  Anyhow, the problem I'm seeing is that the final library has an RPATH
  including the sysroot prefix when make is calling libtool with
  -rpath /usr/lib at link time. I looked at the code in ltmain.m4sh
  starting at line 7240 (see the end of the email for a quotation) and
  firstly, I don't understand why the func_replace_sysroot call is inside
  the $hardcode_libdir_separator test? Surely it should be outside it and
  happen whenever $hardcode_libdir_flag_spec is set?

Firstly let me be upfront and clear, I do have some patches applied on
top of libtool 2.4 to address some problems. These are:

http://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/libtool/libtool/rename-with-sysroot.patch?h=sgarman/libtool-sysroot
(to stop conflicts with gcc/binutils configure options)
http://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/libtool/libtool/prefix.patch?h=sgarman/libtool-sysroot
(renamed libtool to TARGET_PREFIX-libtool, which is mainly useful to
detect when our libtool patches aren't being noticed)
http://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/libtool/libtool/trailingslash.patch?h=sgarman/libtool-sysroot
(a path comparison problem I never did get to the bottom of to report
properly but the fix appears harmless)
http://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/libtool/libtool/use-sysroot-in-libpath.patch?h=sgarman/libtool-sysroot
(a sysroot fix I believe is in libtool git now)

I don't believe any of these are contributing to the issues I'm seeing
though.

http://git.pokylinux.org/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/libtool/libtool/fix-final-rpath.patch?h=sgarman/libtool-sysroot
is a WIP patch which addresses some of the problems I refer to in this
email thread. Its not applied for the tests below.

 Please show the --mode={link,install} commands plus all of their output,
 also './libtool --config'.  Please also show how exactly you invoke
 configure.  Thanks.

A link command and output showing the problem:

/bin/sh ./i586-poky-linux-libtool --tag=CC   --mode=link i586-poky-linux-gcc 
-march=i586 
--sysroot=/media/build2/builds/rptest/b2/tmp/sysroots/i586-poky-linux  
-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb 
-feliminate-unused-debug-types -no-undefined -export-dynamic -version-number 
0:44:0 -Wl,--version-script=libpng.vers  -Wl,-O1 -Wl,--hash-style=gnu 
-Wl,--as-needed -o libpng12.la -rpath /usr/lib libpng12_la-png.lo 
libpng12_la-pngset.lo libpng12_la-pngget.lo libpng12_la-pngrutil.lo 
libpng12_la-pngtrans.lo libpng12_la-pngwutil.lo libpng12_la-pngread.lo 
libpng12_la-pngrio.lo libpng12_la-pngwio.lo libpng12_la-pngwrite.lo 
libpng12_la-pngrtran.lo libpng12_la-pngwtran.lo libpng12_la-pngmem.lo 
libpng12_la-pngerror.lo libpng12_la-pngpread.lo  -lz -lm 
i586-poky-linux-libtool: link: i586-poky-linux-gcc -march=i586 
--sysroot=/media/build2/builds/rptest/b2/tmp/sysroots/i586-poky-linux -shared  
-fPIC -DPIC  .libs/libpng12_la-png.o .libs/libpng12_la-pngset.o 
.libs/libpng12_la-pngget.o .libs/libpng12_la-pngrutil.o 
.libs/libpng12_la-pngtrans.o .libs/libpng12_la-pngwutil.o 
.libs/libpng12_la-pngread.o .libs/libpng12_la-pngrio.o 
.libs/libpng12_la-pngwio.o .libs/libpng12_la-pngwrite.o 
.libs/libpng12_la-pngrtran.o .libs/libpng12_la-pngwtran.o 
.libs/libpng12_la-pngmem.o .libs/libpng12_la-pngerror.o 
.libs/libpng12_la-pngpread.o   -Wl,-rpath 
-Wl,/media/build2/builds/rptest/b2/tmp/sysroots/i586-poky-linux/usr/lib 
/media/build2/builds/rptest/b2/tmp/sysroots/i586-poky-linux/usr/lib/libz.so -lm 
 -march=i586 
--sysroot=/media/build2/builds/rptest/b2/tmp/sysroots/i586-poky-linux -O2 
-Wl,--version-script=libpng.vers -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed   
-Wl,-soname -Wl,libpng12.so.0 -o .libs/libpng12.so.0.44.0
i586-poky-linux-libtool: link: (cd .libs  rm -f libpng12.so.0  ln -s 
libpng12.so.0.44.0 libpng12.so.0)
i586-poky-linux-libtool: link: (cd .libs  rm -f libpng12.so  ln -s 
libpng12.so.0.44.0 libpng12.so)
mv -f .deps/libpng_la-pngwtran.Tpo .deps/libpng_la-pngwtran.Plo
i586-poky-linux-libtool: link: i586-poky-linux-ar cru .libs/libpng12

Re: Libtool sysroot RPATH problems

[Ralf Wildenhues]

Hello Richard,

* Richard Purdie wrote on Wed, Jan 12, 2011 at 12:06:13AM CET:
 Firstly, for the first time ever for us, it appears libtool is no longer
 relinking our libraries at install time.

That's weird, I don't think the sysroot feature should've caused this
change.  Not quite sure though.

 This is welcome as we're cross
 compiling to a sysroot and we'd never want to actually run them in situ
 so this could probably save us some build time. It does however mean we
 never go for a relink step so we're hitting codepaths and issues that
 I've never seen. For reference, we always used to set installed=no in
 our staged libraries prior to sysroot support since this let us hack
 around the lack of sysroot support easier.
 
 Anyhow, the problem I'm seeing is that the final library has an RPATH
 including the sysroot prefix when make is calling libtool with
 -rpath /usr/lib at link time. I looked at the code in ltmain.m4sh
 starting at line 7240 (see the end of the email for a quotation) and
 firstly, I don't understand why the func_replace_sysroot call is inside
 the $hardcode_libdir_separator test? Surely it should be outside it and
 happen whenever $hardcode_libdir_flag_spec is set?

Please show the --mode={link,install} commands plus all of their output,
also './libtool --config'.  Please also show how exactly you invoke
configure.  Thanks.

 Changing that helps a bit and I end up with an RPATH of =/usr/lib so
 the sysroot prefix is gone but the = is there. I suspect that isn't
 valid so I added the following code after the func_replace_sysroot call
 
 func_stripname '=' '' $libdir
 libdir=$func_stripname_result
 
 and then I get an RPATH of /usr/lib which is ok to a point.

The replacing of '=' can be achieved by running 'libtool --mode=finish
LIB' later, although I see we don't document this everywhere yet.

 Of course this is listed in $sys_lib_dlsearch_path_spec so shouldn't be
 getting added at all. Its coming to this function via $compile_rpath
 which is being set around line 5939 which in turn is coming from absdir.
 absdir is being compared against $sys_lib_dlsearch_path_spec but without
 adding/removing any sysroot prefixes.

Hmm, that sounds like a bug indeed.

 I'd really therefore like to ask what behaviour to be expecting from
 libtool before I try and write patches to fix any of this. To summarise
 some of my questions:

I can answer them only with more information, sorry.

Thanks,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool

Libtool sysroot RPATH problems

[Richard Purdie]

Hi,

I work on OpenEmbedded/Poky and we're been experimenting with the recent
libtool sysroot support. To say I'm pleased to have this is an
understatement! We're having a few problems around incorrect RPATHs
being encoded into libraries however.

Firstly, for the first time ever for us, it appears libtool is no longer
relinking our libraries at install time. This is welcome as we're cross
compiling to a sysroot and we'd never want to actually run them in situ
so this could probably save us some build time. It does however mean we
never go for a relink step so we're hitting codepaths and issues that
I've never seen. For reference, we always used to set installed=no in
our staged libraries prior to sysroot support since this let us hack
around the lack of sysroot support easier.

Anyhow, the problem I'm seeing is that the final library has an RPATH
including the sysroot prefix when make is calling libtool with
-rpath /usr/lib at link time. I looked at the code in ltmain.m4sh
starting at line 7240 (see the end of the email for a quotation) and
firstly, I don't understand why the func_replace_sysroot call is inside
the $hardcode_libdir_separator test? Surely it should be outside it and
happen whenever $hardcode_libdir_flag_spec is set?

Changing that helps a bit and I end up with an RPATH of =/usr/lib so
the sysroot prefix is gone but the = is there. I suspect that isn't
valid so I added the following code after the func_replace_sysroot call

func_stripname '=' '' $libdir
libdir=$func_stripname_result

and then I get an RPATH of /usr/lib which is ok to a point.

Of course this is listed in $sys_lib_dlsearch_path_spec so shouldn't be
getting added at all. Its coming to this function via $compile_rpath
which is being set around line 5939 which in turn is coming from absdir.
absdir is being compared against $sys_lib_dlsearch_path_spec but without
adding/removing any sysroot prefixes.

I'd really therefore like to ask what behaviour to be expecting from
libtool before I try and write patches to fix any of this. To summarise
some of my questions:

a) If I'm using a sysroot can I expect to install without a relink step 
   (I hope so!)
b) I couldn't see a function to add/prepend a sysroot without a = in 
   there. I assume given these usecases we should add one?
c) An RPATH starting with an = is invalid, correct?
d) Should the absdir comparisions with sys_lib_dlsearch_path_spec have 
   the sysroot stripped? Are there other rpath variables that need this 
   treatment when comparing to sys_lib_dlsearch_path_spec?
e) The sysroot treatment should apply whenever 
   $hardcode_libdir_flag_spec is set and not on 
   $hardcode_libdir_separator?

If someone could explain the correct behaviour I might be able to come
up with some patches to help fix things! :)

Cheers,

Richard

http://git.savannah.gnu.org/cgit/libtool.git/tree/libltdl/config/ltmain.m4sh?id=9167aecabd12c5afe7a65d45dc73f8c92ab42f05
line 7240:
  # Test again, we may have decided not to build it any more
  if test $build_libtool_libs = yes; then
# Remove ${wl} instances when linking with ld.
# FIXME: should test the right _cmds variable.
case $archive_cmds in
  *\$LD\ *) wl= ;;
esac
if test $hardcode_into_libs = yes; then
  # Hardcode the library paths
  hardcode_libdirs=
  dep_rpath=
  rpath=$finalize_rpath
  test $opt_mode != relink  rpath=$compile_rpath$rpath
  for libdir in $rpath; do
if test -n $hardcode_libdir_flag_spec; then
  if test -n $hardcode_libdir_separator; then
func_replace_sysroot $libdir
libdir=$func_replace_sysroot_result
if test -z $hardcode_libdirs; then
  hardcode_libdirs=$libdir
line 5929:
  if test $linkmode = lib 
 test $hardcode_into_libs = yes; then
# Hardcode the library path.
# Skip directories that are in the system default run-time
# search path.
case  $sys_lib_dlsearch_path  in
* $absdir *) ;;
*)
  case $compile_rpath  in
  * $absdir *) ;;
  *) func_append compile_rpath  $absdir ;;
  esac
  ;;
esac


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: How to create only target shared library at place not ending in rpath?

[Vitaly V. Ch]

On Tue, Nov 2, 2010 at 9:12 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
 Hello Vitaly,

 please don't top-post, thank you.

 * Vitaly V. Ch wrote on Tue, Nov 02, 2010 at 09:52:41AM CET:
 On Mon, Nov 1, 2010 at 6:30 PM, Ralf Wildenhues wrote:
  Would you like to avoid building both static and shared libraries?
  Use --disable-static or --disable-shared at configure time.
 
  Would you like to speed up 'make install'?  Use the newest Automake
  version, in case you're using a version older than 1.11 now.
 
  Would you like to not install some of the shared libraries you build,
  but still create them as shared rather than convenience archives?
  Use noinst_LTLIBRARIES but also pass '-rpath /nowhere' or so in
  libfoo_la_LDFLAGS.

 I have few tens of projects which I need install into few tens of
 sysroots. Currently it's to slow in following cases:

 1) libtool --mode=link  create shared objects which I newer use.

 Why are they then created even?  Can you disable their creation by some
 --disable-* configure option or similar?  If not, can you modify your
 project to add such options?

They created as intermediate state before libtool --mode=install. As
far as I understand libtool libtool --mode=link is required step
before install, but create non-used shared object.


 2) each libtool --mode=install create same shared objects binaries for
 each sysroot.

 Is this very slow?  In absolute time, or compared to the rest of your
 project overhead, and is the latter very low?

That time is about 5 minutes per sysroot. It's too slow for precompiled tree.


 Cheers,
 Ralf

\\wbr Vitaly Chernooky



-- 
\\wbr Vitaly

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: How to create only target shared library at place not ending in rpath?

[Vitaly V. Ch]

Hello Ralf,

I have few tens of projects which I need install into few tens of
sysroots. Currently it's to slow in following cases:

1) libtool --mode=link  create shared objects which I newer use.
2) each libtool --mode=install create same shared objects binaries for
each sysroot.

Currently I try to install into left dir and during installation I
only copy precreated binaries. I think it's a hack, But have no other
ides.

Anyone have ideas to optimise it in right way?

PS: creating static binaries is disabled.

\\wbr Vitaly Chernooky

On Mon, Nov 1, 2010 at 6:30 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
 Hello Vitaly,

 * Vitaly V. Ch wrote on Mon, Nov 01, 2010 at 02:01:44PM CET:
 I'm try to speed up compilation of my project by removing overhead
 stages. Especially time of installation.

 Please also try to speed up communication for us by slowing down
 communication on your end of the mail writing: Please state your problem
 more clearly, so we don't have to ask what you meant.  Thank you.

 Would you like to avoid building both static and shared libraries?
 Use --disable-static or --disable-shared at configure time.

 Would you like to speed up 'make install'?  Use the newest Automake
 version, in case you're using a version older than 1.11 now.

 Would you like to not install some of the shared libraries you build,
 but still create them as shared rather than convenience archives?
 Use noinst_LTLIBRARIES but also pass '-rpath /nowhere' or so in
 libfoo_la_LDFLAGS.

 Hope that helps.

 Cheers,
 Ralf




-- 
\\wbr Vitaly

___
http://lists.gnu.org/mailman/listinfo/libtool

How to create only target shared library at place not ending in rpath?

[Vitaly V. Ch]

Hi all!

I'm try to speed up compilation of my project by removing overhead
stages. Especially time of installation.

-- 
\\wbr Vitaly Chernooky

___
http://lists.gnu.org/mailman/listinfo/libtool

[PATCH] relax -rpath argument test for Snow Leopard

[Leo Davis]

 Hello,

I had to patch libtool in order to get shared libraries to build with
the Snow Leopard '@rpath/' syntax which stands in for the place where
the lib gets installed.  I thought that this might be useful for more
than just myself.

Cheers,

Leo

From a7f66c6ae219f335d79464350d76245a707e56f9 Mon Sep 17 00:00:00 2001
From: Leo Davis lda...@fonix.com
Date: Wed, 22 Sep 2010 19:29:11 -0600
Subject: [PATCH] relax -rpath argument test for Snow Leopard

* libltdl/config/ltmain.m4sh: Relax the absolute path rules requirement
for -rpath a little to allow '@rpath/' to begin the string for Darwin
(Snow Leopard) load paths.
---
 libltdl/config/ltmain.m4sh |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 0418007..3b21851 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4607,9 +4607,9 @@ func_mode_link ()
   continue
   ;;
 rpath | xrpath)
-  # We need an absolute path.
+  # We need an absolute path or a runpath.
   case $arg in
-  [\\/]* | [A-Za-z]:[\\/]*) ;;
+  [\\/]* | [A-Za-z]:[\\/]* | @rpath[\\/]*) ;;
   *)
 func_fatal_error only absolute run-paths are allowed
 ;;
-- 
1.7.2.3

Re: [PATCH] relax -rpath argument test for Snow Leopard

[Peter O'Gorman]

On 09/22/2010 09:00 PM, Leo Davis wrote:

  Hello,

I had to patch libtool in order to get shared libraries to build with
the Snow Leopard '@rpath/' syntax which stands in for the place where
the lib gets installed.  I thought that this might be useful for more
than just myself.


Well, there is no method to encode @executable_path or @loader_path in 
the library install_name either. I always figured that people would just 
build as normal and then postprocess using install_name_tool(1) if they 
needed to.


Why should libtool treat the Mac OS X @rpath differently to the other 
two special paths?


Peter

Re: [PATCH] relax -rpath argument test for Snow Leopard

[Ralf Wildenhues]

Hello,

* Peter O'Gorman wrote on Thu, Sep 23, 2010 at 07:43:44AM CEST:
 On 09/22/2010 09:00 PM, Leo Davis wrote:
 I had to patch libtool in order to get shared libraries to build with
 the Snow Leopard '@rpath/' syntax which stands in for the place where
 the lib gets installed.  I thought that this might be useful for more
 than just myself.
 
 Well, there is no method to encode @executable_path or @loader_path
 in the library install_name either. I always figured that people
 would just build as normal and then postprocess using
 install_name_tool(1) if they needed to.
 
 Why should libtool treat the Mac OS X @rpath differently to the
 other two special paths?

More generally, $ORIGIN support (which is what a number of other linkers
call it, IIUC) should be added completely if it's added, including a
portable 'libtool' notation, testsuite coverage and fixing of fall-out,
and correct treatment of the non-absolute paths throughout ltmain.
I don't know how much work the latter would be, but guessing from the
sysroot branch, there is work to do there.

The most important question to this end is how to degrade gracefully
on systems without such a feature.

Cheers,
Ralf

Re: checking for header/library mismatch, rpath problem?

[Peter Breitenlohner]

On Tue, 29 Jun 2010, Ralf Wildenhues wrote:


* Peter Breitenlohner wrote on Tue, Jun 29, 2010 at 10:36:32AM CEST:

Here the macro we are using in TeX Live for such tests (C and C++).  Our
purpose is to test properties of libraries that can be either
(1) uninstalled libtool libraries already built when this configure runs,
or (2) installed libraries -- libtool or not.


Good stuff.  Are you willing to turn this into a patch against git
Libtool?  Otherwise we'll put it on our todo list.  You might need
to sign papers though, at least if you're adding test coverage.


Hi Ralf,

see below.


A general set of macros could be LT_USE_LIBTOOL_PUSH and _POP and could
adjust the AC_LANG setting of all configured libtool tags; the pop macro
could reset them to their original state afterwards; that would help for
encapsulation.  Or some better names I can't think of right now.


# _KPSE_USE_LIBTOOL()
# ---
AC_DEFUN([_KPSE_USE_LIBTOOL],
[## $0: Generate a libtool script for use in configure tests
AC_PROVIDE_IFELSE([LT_INIT], ,
  [m4_fatal([$0: requires libtool])])[]dnl
LT_OUTPUT
m4_append([AC_LANG(C)],
[ac_link=./libtool --mode=link --tag=CC $ac_link
])[]dnl
AC_PROVIDE_IFELSE([AC_PROG_CXX],
[m4_append([AC_LANG(C++)],
[ac_link=./libtool --mode=link --tag=CXX $ac_link
])])[]dnl
AC_LANG(_AC_LANG)[]dnl
]) # _KPSE_USE_LIBTOOL


Please feel free to use the basic idea which is simple enough and might not
require paperwork, but I would prefer that you put this on your todo list
and have it handled by someone thoroughly familiar with libtool internals
(which I am certainly not).

Our macro perfectly serves our needs, but probably needs to be improved in
several respects (not counting the PUSH/POP generalization), e.g.,

(1) cover all languages.  Should there be a one-to-one correspondence
between AC_PROG_FOO/AC_LANG(foo)/--tag=FOO?  I am thinking in particular of
ObjC/ObjC++ that might need libtool tags or could use tags CC/CXX. (For TeX
Live we have ObjC/ObjC++ source files but don't have to run test for these
languages.)

(2) There may be subtleties about the ordering of Autoconf macros:
  LT_INIT
  AC_PROG_CXX
has the same effect as
  AC_PROG_CXX
  LT_INIT
but I don't know is if
  LT_INIT
  LT_OUTPUT
  AC_PROG_CXX
also has the same effect as
  LT_INIT
  AC_PROG_CXX
  LT_OUTPUT

Regards
Peter Breitenlohner p...@mppmu.mpg.de

Re: checking for header/library mismatch, rpath problem?

[Ralf Wildenhues]

[ please elide autoconf@ from followups, thanks ]

Hi Peter,

* Peter Breitenlohner wrote on Tue, Jun 29, 2010 at 10:36:32AM CEST:
 Here the macro we are using in TeX Live for such tests (C and C++).  Our
 purpose is to test properties of libraries that can be either
 (1) uninstalled libtool libraries already built when this configure runs,
 or (2) installed libraries -- libtool or not.

Good stuff.  Are you willing to turn this into a patch against git
Libtool?  Otherwise we'll put it on our todo list.  You might need
to sign papers though, at least if you're adding test coverage.

A general set of macros could be LT_USE_LIBTOOL_PUSH and _POP and could
adjust the AC_LANG setting of all configured libtool tags; the pop macro
could reset them to their original state afterwards; that would help for
encapsulation.  Or some better names I can't think of right now.

 # _KPSE_USE_LIBTOOL()
 # ---
 AC_DEFUN([_KPSE_USE_LIBTOOL],
 [## $0: Generate a libtool script for use in configure tests
 AC_PROVIDE_IFELSE([LT_INIT], ,
   [m4_fatal([$0: requires libtool])])[]dnl
 LT_OUTPUT
 m4_append([AC_LANG(C)],
 [ac_link=./libtool --mode=link --tag=CC $ac_link
 ])[]dnl
 AC_PROVIDE_IFELSE([AC_PROG_CXX],
 [m4_append([AC_LANG(C++)],
 [ac_link=./libtool --mode=link --tag=CXX $ac_link
 ])])[]dnl
 AC_LANG(_AC_LANG)[]dnl
 ]) # _KPSE_USE_LIBTOOL

Thanks,
Ralf

Re: rpath

[Ralf Wildenhues]

* Joakim Tjernlund wrote on Sat, Dec 12, 2009 at 12:05:13PM CET:
 Ralf Corsepius wrote on 12/12/2009 07:20:05:
 
  The whole purpose of DESTDIR is being set at install-time and not to be
  AC_SUBST'ed anywhere.
 
  I.e. doing things like outlined above would contradict it's purpose.
 
 It doesn't seem to any other way as far as I can tell.
 
 We build our embedded SW with a different prefix each time to be able
 to separate the different builds alongside each other on the target.
 Each build is performed in a private DESTDIR which will vary depending on
 the actual arch and product.
 Setting DESTDIR via some script for one time builds works fine but
 for repeated build during development where one types make DESTDIR=...
 manually does not work so well.
 Ideally one should be able to set DESTDIR during configure but be able to
 override that by typing make DESTDIR=...

Readoing your reply, I can only guess that you have misunderstood the
purpose of DESTDIR completely and shouldn't be using it at all.
Builds happen in build trees, which you can separate by just running
configure from separate directories.  Build trees have nothing to do
with --prefix nor DESTDIR, which both revolve around install trees.
In case you actually meant separate install trees, then use different
values for --prefix.  DESTDIR is only for things like I am building a
package intended for /usr, but right now I am not the super-user, so
`make install' will fail unless I temporarily divert the installation
elsewhere so that I can still make a binary pacakge from the
installation.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath

[Joakim Tjernlund]

Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 13/12/2009 11:18:31:

 * Joakim Tjernlund wrote on Sat, Dec 12, 2009 at 12:05:13PM CET:
  Ralf Corsepius wrote on 12/12/2009 07:20:05:
  
   The whole purpose of DESTDIR is being set at install-time and not to be
   AC_SUBST'ed anywhere.
  
   I.e. doing things like outlined above would contradict it's purpose.
 
  It doesn't seem to any other way as far as I can tell.
 
  We build our embedded SW with a different prefix each time to be able
  to separate the different builds alongside each other on the target.
  Each build is performed in a private DESTDIR which will vary depending on
  the actual arch and product.
  Setting DESTDIR via some script for one time builds works fine but
  for repeated build during development where one types make DESTDIR=...
  manually does not work so well.
  Ideally one should be able to set DESTDIR during configure but be able to
  override that by typing make DESTDIR=...

 Readoing your reply, I can only guess that you have misunderstood the
 purpose of DESTDIR completely and shouldn't be using it at all.
 Builds happen in build trees, which you can separate by just running
 configure from separate directories.  Build trees have nothing to do

Yes, I do this.

 with --prefix nor DESTDIR, which both revolve around install trees.
 In case you actually meant separate install trees, then use different
 values for --prefix.  DESTDIR is only for things like I am building a
 package intended for /usr, but right now I am not the super-user, so
 `make install' will fail unless I temporarily divert the installation
 elsewhere so that I can still make a binary pacakge from the
 installation.

Lets see, this is what I do:
I am building for /opt/appl/ on the target using a build tree
outside my sources: I want to install my apps/libs into a dir
next to my build tree. Once everything is installed into the
temporary install tree, I build a package from the files in the install
tree into some sort of tar ball which I can transfer to the target and unpack
it using the same tree structure as the install tree I just built.

Currently I build with prefix that is $(build_tree)/opt/appl/
but then rpath will include the build_tree and that is not ideal.
Perhaps there is a simpler way to set rpath?



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath

[Ralf Wildenhues]

* Joakim Tjernlund wrote on Sun, Dec 13, 2009 at 12:26:18PM CET:
 I am building for /opt/appl/ on the target using a build tree
 outside my sources: I want to install my apps/libs into a dir
 next to my build tree. Once everything is installed into the
 temporary install tree, I build a package from the files in the install
 tree into some sort of tar ball which I can transfer to the target and unpack
 it using the same tree structure as the install tree I just built.
 
 Currently I build with prefix that is $(build_tree)/opt/appl/
 but then rpath will include the build_tree and that is not ideal.
 Perhaps there is a simpler way to set rpath?

Specify with configure --prefix the *final* location of the installed
code: where it will be when the end-user runs it.  Divert installation
elsewhere with `make install DESTDIR=...'.  If that doesn't fit your
directory layout, that can be a problem.  Libtool unfortunately doesn't
yet cope with arbitrary install-time diversions a la `make install
prefix=...'.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath

[Joakim Tjernlund]

Ralf Corsepius rc040...@freenet.de wrote on 12/12/2009 07:20:05:

 On 12/12/2009 12:57 AM, Ralf Wildenhues wrote:
  Hi Roumen,
 
  * Roumen Petrov wrote on Fri, Dec 11, 2009 at 09:36:54PM CET:
  Ralf Wildenhues wrote:
 AC_ARG_VAR([DESTDIR], [perform staged installation using DESTDIR])
 
  This  require makefiles generated by configure script to contain
  line like this one:
  destd...@destdir@
 
  Right.  If you wouldn't use Automake, you'd have to add that line
  yourself.

 The whole purpose of DESTDIR is being set at install-time and not to be
 AC_SUBST'ed anywhere.

 I.e. doing things like outlined above would contradict it's purpose.

It doesn't seem to any other way as far as I can tell.

We build our embedded SW with a different prefix each time to be able
to separate the different builds alongside each other on the target.
Each build is performed in a private DESTDIR which will vary depending on
the actual arch and product.
Setting DESTDIR via some script for one time builds works fine but
for repeated build during development where one types make DESTDIR=...
manually does not work so well.
Ideally one should be able to set DESTDIR during configure but be able to
override that by typing make DESTDIR=...

 Jocke



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath

[Ralf Wildenhues]

* Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 08:04:27AM CET:
 Ralf Wildenhues wrote on 10/12/2009 06:16:40:
  * Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 12:50:14AM CET:
   Ralf Wildenhues wrote on 08/12/2009 20:13:13:
  ./configure --prefix=/opt/x/y
  make
  make install DESTDIR=/some/dir
  
   I getting back to this now that my libtool problem seem to be over.
   Pondring on DESTDIR, I wonder if there is a way to set a default DESTDIR 
   at
   configure time so one does have to remember/type DESTDIR=.. at every make
 
  No, but you can just `export DESTDIR' in your environment.
 
 Yeah, but that isn't going to work in here, too easy to get wrong. I image
 I could add something to configure.ac that will allow me to set it at 
 configure
 time? Not sure what would work though, any ideas?

Well you can
  AC_ARG_VAR([DESTDIR], [perform staged installation using DESTDIR])

but it will require your users to either specify it at configure time
already, or, if they want to specify it at `make install' time only,
use GNU make.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath

[Roumen Petrov]

Ralf Wildenhues wrote:

* Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 08:04:27AM CET:

Ralf Wildenhues wrote on 10/12/2009 06:16:40:

* Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 12:50:14AM CET:

Ralf Wildenhues wrote on 08/12/2009 20:13:13:

   ./configure --prefix=/opt/x/y
   make
   make install DESTDIR=/some/dir


I getting back to this now that my libtool problem seem to be over.
Pondring on DESTDIR, I wonder if there is a way to set a default DESTDIR at
configure time so one does have to remember/type DESTDIR=.. at every make


No, but you can just `export DESTDIR' in your environment.


Yeah, but that isn't going to work in here, too easy to get wrong. I image
I could add something to configure.ac that will allow me to set it at configure
time? Not sure what would work though, any ideas?


Well you can
   AC_ARG_VAR([DESTDIR], [perform staged installation using DESTDIR])


This  require makefiles generated by configure script to contain line 
like this one:

destd...@destdir@
otherwise it is useless 

I won't like to discuss more what happen if user forget DESTDIR as it is 
not required at every make.  DESTDIR is usefull only if user would 
like to create distribution archive and for every package DESTDIR is 
good to point to clean directory tree.
Other point is that on unix(linux) user work under unprivileged account 
and only for install is required a  privileged account(root).




but it will require your users to either specify it at configure time
already, or, if they want to specify it at `make install' time only,
use GNU make.

Cheers,
Ralf



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath

[Ralf Wildenhues]

Hi Roumen,

* Roumen Petrov wrote on Fri, Dec 11, 2009 at 09:36:54PM CET:
 Ralf Wildenhues wrote:
AC_ARG_VAR([DESTDIR], [perform staged installation using DESTDIR])
 
 This  require makefiles generated by configure script to contain
 line like this one:
 destd...@destdir@

Right.  If you wouldn't use Automake, you'd have to add that line
yourself.

Thanks,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath

[Joakim Tjernlund]

Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 08/12/2009 20:13:13:

 From: Ralf Wildenhues ralf.wildenh...@gmx.de
 To: Joakim Tjernlund joakim.tjernl...@transmode.se
 Cc: libtool@gnu.org
 Date: 08/12/2009 20:14
 Subject: Re: rpath

 Hello Joakim,

 * Joakim Tjernlund wrote on Tue, Dec 08, 2009 at 09:44:57AM CET:
 
  rpath gets set to /usr/local/lib but this is wrong for me.
  I am crosscompiling and point builddir to /some/dir and install
  into /some/dir/opt/x/y so I want rpath to point to /opt/x/y
  What controls rpath in libtool?

   ./configure --prefix=/opt/x/y
   make
   make install DESTDIR=/some/dir

I getting back to this now that my libtool problem seem to be over.
Pondring on DESTDIR, I wonder if there is a way to set a default DESTDIR at
configure time so one does have to remember/type DESTDIR=.. at every make



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath

[Ralf Wildenhues]

* Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 12:50:14AM CET:
 Ralf Wildenhues wrote on 08/12/2009 20:13:13:
./configure --prefix=/opt/x/y
make
make install DESTDIR=/some/dir
 
 I getting back to this now that my libtool problem seem to be over.
 Pondring on DESTDIR, I wonder if there is a way to set a default DESTDIR at
 configure time so one does have to remember/type DESTDIR=.. at every make

No, but you can just `export DESTDIR' in your environment.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath

[Joakim Tjernlund]

Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 10/12/2009 06:16:40:

 From: Ralf Wildenhues ralf.wildenh...@gmx.de
 To: Joakim Tjernlund joakim.tjernl...@transmode.se
 Cc: libtool@gnu.org
 Date: 10/12/2009 06:16
 Subject: Re: rpath

 * Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 12:50:14AM CET:
  Ralf Wildenhues wrote on 08/12/2009 20:13:13:
 ./configure --prefix=/opt/x/y
 make
 make install DESTDIR=/some/dir
 
  I getting back to this now that my libtool problem seem to be over.
  Pondring on DESTDIR, I wonder if there is a way to set a default DESTDIR at
  configure time so one does have to remember/type DESTDIR=.. at every make

 No, but you can just `export DESTDIR' in your environment.

Yeah, but that isn't going to work in here, too easy to get wrong. I image
I could add something to configure.ac that will allow me to set it at configure
time? Not sure what would work though, any ideas?




___
http://lists.gnu.org/mailman/listinfo/libtool

rpath

[Joakim Tjernlund]

rpath gets set to /usr/local/lib but this is wrong for me.
I am crosscompiling and point builddir to /some/dir and install
into /some/dir/opt/x/y so I want rpath to point to /opt/x/y
What controls rpath in libtool?



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath

[Mike Frysinger]

On Tuesday 08 December 2009 03:44:57 Joakim Tjernlund wrote:
 rpath gets set to /usr/local/lib but this is wrong for me.
 I am crosscompiling and point builddir to /some/dir and install
 into /some/dir/opt/x/y so I want rpath to point to /opt/x/y
 What controls rpath in libtool?

what did you set your libdir/prefix/etc... to ?
-mike


signature.asc
Description: This is a digitally signed message part.
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath

[Ralf Wildenhues]

Hello Joakim,

* Joakim Tjernlund wrote on Tue, Dec 08, 2009 at 09:44:57AM CET:
 
 rpath gets set to /usr/local/lib but this is wrong for me.
 I am crosscompiling and point builddir to /some/dir and install
 into /some/dir/opt/x/y so I want rpath to point to /opt/x/y
 What controls rpath in libtool?

  ./configure --prefix=/opt/x/y
  make
  make install DESTDIR=/some/dir

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: problem with rpath on OpenBSD

[Vincent Torri]

On Sun, 8 Nov 2009, Bob Friesenhahn wrote:


On Sat, 7 Nov 2009, Vincent Torri wrote:

The link command is:

/bin/sh ../../../libtool --tag=CC --mode=link gcc -o emotion.la -rpath 
-module -avoid-version emotion.lo ../../../src/lib/libethumb.la 
-L/usr/local/lib -L/usr/X11R6/lib -levas -leet -lgnutls -lfribidi 
-lfontconfig -lexpat -lfreetype -lz -leina -L/usr/local/lib -leina 
-L/usr/local/lib -L/usr/X11R6/lib -lemotion -levas -leet -lgnutls -lfribidi 
-lfontconfig -lexpat -lfreetype -lz -leina -L/usr/local/lib -lecore 
-lglib-2.0 -lintl -liconv -leina -L/usr/local/lib -L/usr/local//lib 
-L/usr/X11R6/lib -ledje -lecore_imf_evas -lecore_imf -llua -lm -lembryo 
-lecore_job -lecore -lglib-2.0 -lintl -liconv -levas -lfribidi -lfontconfig 
-lexpat -lfreetype -lz -leet -lgnutls -leina


The error is

libtool: link: only absolute run-paths are allowed

it seems that no value is passed to rpath (what is after it is -module)


Ok, I slept last night and am looking at this again.  It seems pretty clear 
that since no argument was supplied to -rpath that the bug is related to 
whatever is invoking libtool (probably a Makefile) rather than libtool 
itself.


I also think that it is a problem with a Makefile. I'll investigate more.

thank you

Vincent Torri


___
http://lists.gnu.org/mailman/listinfo/libtool

problem with rpath on OpenBSD

[Vincent Torri]

Hey,

a guy is trying to compile one of our libraries on OpenBSD 4.6. He is 
using libtool 1.5.26


The link command is:

/bin/sh ../../../libtool --tag=CC --mode=link gcc -o emotion.la -rpath 
-module -avoid-version emotion.lo ../../../src/lib/libethumb.la 
-L/usr/local/lib -L/usr/X11R6/lib -levas -leet -lgnutls -lfribidi 
-lfontconfig -lexpat -lfreetype -lz -leina -L/usr/local/lib -leina 
-L/usr/local/lib -L/usr/X11R6/lib -lemotion -levas -leet -lgnutls 
-lfribidi -lfontconfig -lexpat -lfreetype -lz -leina -L/usr/local/lib 
-lecore -lglib-2.0 -lintl -liconv -leina -L/usr/local/lib 
-L/usr/local//lib -L/usr/X11R6/lib -ledje -lecore_imf_evas -lecore_imf 
-llua -lm -lembryo -lecore_job -lecore -lglib-2.0 -lintl -liconv -levas 
-lfribidi -lfontconfig -lexpat -lfreetype -lz -leet -lgnutls -leina


The error is

libtool: link: only absolute run-paths are allowed

it seems that no value is passed to rpath (what is after it is -module)

I don't know which information or file i should provide to give more hints 
about the problem.


does someone have an idea ?

thank you

Vincent Torri


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath in later versions of libtool

[Ralf Wildenhues]

Hello John,

* John R. Cary wrote on Fri, Aug 07, 2009 at 11:49:39PM CEST:
 I am trying to use libtool to make a static executable:
 
 /bin/sh ../libtool --tag=CXX   --mode=link g++  -g -O2 -pipe -Wall
 -Wno-unused-static  -o uecxxst  ../uebase/uedge.o libuecxxst.la
 ../uestat/.libs/libuestat.a ../uebase/libuebase.a
 ../vshdf5/.libs/libvshdf5.a
 -L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib -lsidl
 -lsidlstub_cxx -lsidlstub_f90
 -L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -rpath
 /usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes
 -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1
 -llapack -lblas -lmpiuni
 /usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a
 /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a
 /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a
 /usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a  -llapack
 /usr/lib64/libblas.so -lgfortranbegin -lgfortran -lm  -lz -rpath
 /usr/lib/gcc/x86_64-redhat-linux/4.4.0 -ldl
 
 but it ends up not finding some libraries:
 
 iter.cary$ ldd uecxxst
linux-vdso.so.1 =  (0x7fffad9ff000)
libblas.so.3 = /usr/lib64/libblas.so.3 (0x7fb6a5685000)
libpetscts.so = not found
libpetscsnes.so = not found
libpetscksp.so = not found
libpetscdm.so = not found
libpetscmat.so = not found
libpetscvec.so = not found
libpetsc.so = not found
liblapack.so.3 = /usr/lib64/atlas/liblapack.so.3

 On the libtool line I had both '-static' and '-rpath
 /usr/local/contrib/petsc-3.0.0-p7-ser/lib'
 with the latter being where the libs are found:



 iter.cary$ \ls /usr/local/contrib/petsc-3.0.0-p7-ser/lib
 libmpiuni.a libpetscdm.so   libpetscsnes.a   libpetscvec.a
[...]
 One can see that the -rpath on the link line is not generating anything
 like '-Wl,-rpath,...' on the g++ link line.

Try using -R $path instead of -rpath $path.

If that fixes it, it seems we have a regression to take care of.

Cheers,
Ralf



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath in later versions of libtool (fwd)

[John R. Cary]

I forgot to cc the listJohn Cary

--
Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303
c...@txcorp.com, p 303-448-0727, f 303-448-7756

-- Forwarded message --
Date: Sat, 08 Aug 2009 15:14:54 -0600
From: John R. Cary c...@txcorp.com
To: Bob Friesenhahn bfrie...@simple.dallas.tx.us
Subject: Re: rpath in later versions of libtool

Bob Friesenhahn wrote:

 On Fri, 7 Aug 2009, John R. Cary wrote:
 
  I am trying to use libtool to make a static executable:
 
  /bin/sh ../libtool --tag=CXX   --mode=link g++  -g -O2 -pipe -Wall 
  -Wno-unused-static  -o uecxxst  ../uebase/uedge.o libuecxxst.la 
  ../uestat/.libs/libuestat.a ../uebase/libuebase.a 
  ../vshdf5/.libs/libvshdf5.a 
  -L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib -lsidl -lsidlstub_cxx 
  -lsidlstub_f90  -L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -rpath 
  /usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes -lpetscksp 
  -lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1 -llapack -lblas 
  -lmpiuni/usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a 
  /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a 
  /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a 
  /usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a  -llapack 
  /usr/lib64/libblas.so -lgfortranbegin -lgfortran -lm  -lz -rpath 
  /usr/lib/gcc/x86_64-redhat-linux/4.4.0 -ldl
 
  but it ends up not finding some libraries:

libatlas.so.3 = /usr/lib64/atlas/libatlas.so.3 (0x7fb6a3f01000)
 
  One can see that the -rpath on the link line is not generating anything

  like '-Wl,-rpath,...' on the g++ link line.

 Actually, we can't see that since you omitted the useful libtool output
 where it prints what it actually invoked.


Argh.  Here it is:

libtool: link: g++ -g -O2 -pipe -Wall -Wno-unused -o uecxxst ../uebase/uedge.o 
/usr/lib64/libblas.so  ./.libs/libuecxxst.a ../uestat/.libs/libuestat.a 
../uebase/libuebase.a ../vshdf5/.libs/libvshdf5.a 
-L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib 
/contrib/babel-1.4.0-r6662p1-static/lib/libsidlstub_cxx.a 
/contrib/babel-1.4.0-r6662p1-static/lib/libsidlstub_f90.a 
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.0 
/contrib/babel-1.4.0-r6662p1-static/lib/libsidl.a 
/contrib/babel-1.4.0-r6662p1-static/lib/libchasmlite.a 
-L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes -lpetscksp 
-lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1 -lblas -lmpiuni 
/usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a 
/usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a 
/usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a 
/usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a -llapack 
-lgfortranbegin -lgfortran -lm -lz -ldl -pthread






  what am I doing wrong?

 My first guess is that there is a problem with supplying -rpath multiple
 times on the command line.  If this is the problem, perhaps libtool's output
 about what it is doing would include only
 -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.4.0 since that is the last
 -rpath option supplied.

 The other possibility is that the problem libraries have not been registered
 with the system using 'ldconfig' and perhaps Linux needs that.


Thanks for your suggestions.  I see no -Wl,-rpath anywhere above.  As for 
ldconfig,
it that registration were necessary, I guess that would obviate the need for 
rpath?


ThxJohn Cary


--
Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303
c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572




___
http://lists.gnu.org/mailman/listinfo/libtool

rpath in later versions of libtool

[John R. Cary]

I am running:

iter.cary$ autoconf --version; automake --version; libtool --version
autoconf (GNU Autoconf) 2.63
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
http://gnu.org/licenses/old-licenses/gpl-2.0.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
automake (GNU automake) 1.11
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later 
http://gnu.org/licenses/gpl-2.0.html

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey tro...@redhat.com
  and Alexandre Duret-Lutz a...@gnu.org.
iter.cary$ libtool --version
ltmain.sh (GNU libtool) 2.2.4
Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996

I am trying to use libtool to make a static executable:

/bin/sh ../libtool --tag=CXX   --mode=link g++  -g -O2 -pipe -Wall 
-Wno-unused-static  -o uecxxst  ../uebase/uedge.o libuecxxst.la 
../uestat/.libs/libuestat.a ../uebase/libuebase.a 
../vshdf5/.libs/libvshdf5.a 
-L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib -lsidl 
-lsidlstub_cxx -lsidlstub_f90  
-L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -rpath 
/usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes 
-lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1 
-llapack -lblas -lmpiuni
/usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a  
/usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a 
/usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a  
/usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a  -llapack 
/usr/lib64/libblas.so -lgfortranbegin -lgfortran -lm  -lz -rpath 
/usr/lib/gcc/x86_64-redhat-linux/4.4.0 -ldl


but it ends up not finding some libraries:

iter.cary$ ldd uecxxst
   linux-vdso.so.1 =  (0x7fffad9ff000)
   libblas.so.3 = /usr/lib64/libblas.so.3 (0x7fb6a5685000)
   libpetscts.so = not found
   libpetscsnes.so = not found
   libpetscksp.so = not found
   libpetscdm.so = not found
   libpetscmat.so = not found
   libpetscvec.so = not found
   libpetsc.so = not found
   liblapack.so.3 = /usr/lib64/atlas/liblapack.so.3 
(0x7fb6a4ee7000)

   libgfortran.so.3 = /usr/lib64/libgfortran.so.3 (0x7fb6a4bfd000)
   libz.so.1 = /lib64/libz.so.1 (0x00393460)
   libdl.so.2 = /lib64/libdl.so.2 (0x003933a0)
   libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x00393920)
   libm.so.6 = /lib64/libm.so.6 (0x003933e0)
   libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x00393820)
   libpthread.so.0 = /lib64/libpthread.so.0 (0x00393420)
   libc.so.6 = /lib64/libc.so.6 (0x00393360)
   libf77blas.so.3 = /usr/lib64/atlas/libf77blas.so.3 
(0x7fb6a49dc000)

   libcblas.so.3 = /usr/lib64/atlas/libcblas.so.3 (0x7fb6a47bc000)
   /lib64/ld-linux-x86-64.so.2 (0x00393320)
   libatlas.so.3 = /usr/lib64/atlas/libatlas.so.3 (0x7fb6a3f01000)

On the libtool line I had both '-static' and '-rpath 
/usr/local/contrib/petsc-3.0.0-p7-ser/lib'

with the latter being where the libs are found:

iter.cary$ \ls /usr/local/contrib/petsc-3.0.0-p7-ser/lib
libmpiuni.a libpetscdm.so   libpetscsnes.a   libpetscvec.a
libpetsc.a  libpetscksp.a   libpetscsnes.so  libpetscvec.so
libpetsccontrib.a   libpetscksp.so  libpetsc.so  libsuperlu_3.1.a
libpetsccontrib.so  libpetscmat.a   libpetscts.a shared
libpetscdm.alibpetscmat.so  libpetscts.so

One can see that the -rpath on the link line is not generating anything
like '-Wl,-rpath,...' on the g++ link line.

what am I doing wrong?

This on

iter.cary$ uname -a
Linux iter.txcorp.com 2.6.29.4-167.fc11.x86_64 #1 SMP Wed May 27 
17:27:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux


Thanks...John Cary







___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath in later versions of libtool

[Bob Friesenhahn]

On Fri, 7 Aug 2009, John R. Cary wrote:


I am trying to use libtool to make a static executable:

/bin/sh ../libtool --tag=CXX   --mode=link g++  -g -O2 -pipe -Wall 
-Wno-unused-static  -o uecxxst  ../uebase/uedge.o libuecxxst.la 
../uestat/.libs/libuestat.a ../uebase/libuebase.a ../vshdf5/.libs/libvshdf5.a 
-L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib -lsidl -lsidlstub_cxx 
-lsidlstub_f90  -L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -rpath 
/usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes -lpetscksp 
-lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1 -llapack -lblas 
-lmpiuni/usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a 
/usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a 
/usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a 
/usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a  -llapack 
/usr/lib64/libblas.so -lgfortranbegin -lgfortran -lm  -lz -rpath 
/usr/lib/gcc/x86_64-redhat-linux/4.4.0 -ldl


but it ends up not finding some libraries:
  libatlas.so.3 = /usr/lib64/atlas/libatlas.so.3 (0x7fb6a3f01000)

One can see that the -rpath on the link line is not generating anything
like '-Wl,-rpath,...' on the g++ link line.


Actually, we can't see that since you omitted the useful libtool 
output where it prints what it actually invoked.



what am I doing wrong?


My first guess is that there is a problem with supplying -rpath 
multiple times on the command line.  If this is the problem, perhaps 
libtool's output about what it is doing would include only 
-Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.4.0 since that is the 
last -rpath option supplied.


The other possibility is that the problem libraries have not been 
registered with the system using 'ldconfig' and perhaps Linux needs 
that.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Problems creating convenience libraries on IRIX 6.5 if -rpath linker option used

[Ralf Wildenhues]

Hello Tuomas,

* Tuomas Jormola wrote on Fri, Jun 13, 2008 at 01:23:24PM CEST:
 I'm trying to compile glib 2.16.3 on IRIX 6.5 using SGI's MipsPro 7.4.3m
 compiler toolchain. I'm using the custom prefix /opt/local for the stuff
 I'm compiling. I want to setup run-time linker search path for the
 binaries to the prefix so I'm using the following flags are used when
 configuring:
 
 CC=cc -64 -mips4 -c99 \
   CPPFLAGS=-I/opt/local/include \
   LDFLAGS=-rpath /opt/local/lib -L/opt/local/lib
   ./configure --prefix=/opt/local ...

When using libtool, you should not use '-rpath' to add to the run path.
To libtool that means that, when you're creating a library, that it's to
be shared and it will eventually be installed in LIBDIR.  Only for
programs does -rpath do what you want (but -R does the same).

Actually, for the programs generated by libtool that link against
libraries installed into /opt/local/lib, libtool will add run paths to
/opt/local/lib anyway.  For the rest, you can use -R (which, on IRIX,
will be translated by libtool into -rpath; and on other systems into
their appropriate flag).

Hope that helps.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Problems creating convenience libraries on IRIX 6.5 if -rpath linker option used

[Tuomas Jormola]

Hi,

I'm trying to compile glib 2.16.3 on IRIX 6.5 using SGI's MipsPro 7.4.3m
compiler toolchain. I'm using the custom prefix /opt/local for the stuff
I'm compiling. I want to setup run-time linker search path for the
binaries to the prefix so I'm using the following flags are used when
configuring:

CC=cc -64 -mips4 -c99 \
CPPFLAGS=-I/opt/local/include \
LDFLAGS=-rpath /opt/local/lib -L/opt/local/lib
./configure --prefix=/opt/local ...

Glib has auxiliary library called libcharset, which is defined not to be
installed, snippet from glib/libcharset/Makefile.am:

noinst_LTLIBRARIES = libcharset.la

However, when I compiled libcharset, libtool does not produce static
libcharset.a as it's supposed to do but a shared library
libcharset.so.1.0 is linked instead.

I configured the same glib version on a Linux system with similar
configure options, but adapted for gcc/binutils. I looked at the
generated .la files on both systems and the libtool script the glib
configure script produced (it's using libtool version 1.5.24). I noticed
that on the SGI system, the line

libdir='/opt/local/lib'

is added to libcharset.la. On a Linux system the corresponding line is

libdir=''

Investigating the libtool script reveals that a library is considered
a convenience library only if the value of the libdir variable is empty.
On the SGI system this is not the case, and the library gets linked as
a shared library, and all the libraries that depend on the library (e.g.
libglib-2.0.la), are linked against the shared library. However, when
installing the package to the configured prefix, this auxiliary library
is not installed, resulting broken libglib-2.0.so.1 installation as the
needed libcharset.so.1.0 is nowhere to be found.

So how does this erroneous libdir variable is placed in the .la file of
a convenience library on the SGI system? It's because of this piece of
code in libtool:

set dummy $rpath
if test $# -gt 2; then
  $echo $modename: warning: ignoring multiple \`-rpath's for a libtool 
library 12
fi
install_libdir=$2

Value of the rpath variable is the argument to -rpath argument in
LDFLAGS, and it's value is assigned to variable install_libdir, which is
eventually written to the .la file. If I omit the -rpath argument in
LDFLAGS, the convenience library is linked statically, and
libglib-2.0.so.1 is linked bautifully against it.

So my question is what is this piece of code supposed to do in the first
place? Why setting the install directory for a library is based on the
possible rpath linker option, potentially hosing the whole
convenience library mechanism in place? How should this be fixed so that
one can use -rpath in LDFLAGS while linking would work like it should
be?

Regards,

-- 
Tuomas Jormola [EMAIL PROTECTED]


signature.asc
Description: Digital signature
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: ld --rpath problem using libtool

[Richard Hacker]

Hi Ralf,

On Wednesday 09 January 2008 07:48, Ralf Wildenhues wrote:
 I think the issue is this:  libtool doesn't add a run path to
 /opt/etherlab/lib because it thinks the runtime linker will already
 search that by default.  Your --config output shows that it is listed
 ...
 I'm wondering, if it's listed there (could you please confirm that?),
 why doesn't the runtime linker find it then in your case?
I'm most impressed how quickly you put the finger on the wound :). That was 
the mistake! Before discovering how libtool helps me with the work, I used 
ld.so.conf - and it has been lying there ever since.

Thanks a lot
- Richard


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: ld --rpath problem using libtool

[Richard Hacker]

Hi Ralf,

Attached are the two logs that you have requested. I hope this helps you 
further. At least my assumption that libtool should get a library's path 
information from libx.la is not wrong. ;)

Sorry for sending the logs unzipped previously.

Many thanks for your help.

- Richard


config.log.gz
Description: GNU Zip compressed data


relink.log.gz
Description: GNU Zip compressed data
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: ld --rpath problem using libtool

[Ralf Wildenhues]

Hello Richard,

* Richard Hacker wrote on Wed, Jan 09, 2008 at 07:40:57AM CET:
 
 Attached are the two logs that you have requested. I hope this helps you 
 further. At least my assumption that libtool should get a library's path 
 information from libx.la is not wrong. ;)
 
 Sorry for sending the logs unzipped previously.

Thanks for the resend.

I think the issue is this:  libtool doesn't add a run path to
/opt/etherlab/lib because it thinks the runtime linker will already
search that by default.  Your --config output shows that it is listed
as such:

| # Run-time system search path for libraries
| sys_lib_dlsearch_path_spec=/lib /usr/lib /usr/X11R6/lib/Xaw3d /usr/X11R6/lib 
/usr/lib/Xaw3d /usr/i386-suse-linux/lib /usr/local/lib /opt/kde3/lib 
/opt/gnome/lib /opt/etherlab/lib 

This typically happens on GNU/Linux if the path is listed in
/etc/ld.so.conf* (the Libtool configure macros try to parse that).

I'm wondering, if it's listed there (could you please confirm that?),
why doesn't the runtime linker find it then in your case?

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

ld --rpath problem using libtool

[Richard Hacker]

Hi all,

I'm experiencing some trouble using libtool inside the GNU autotools 
collection. My compiled objects do not find their shared libraries that are 
installed in non-standard library paths.

I wrote a C++ library, called rtcom for argument's sake, and used SWIG to make 
it available as a Python module, rtcom.py. Now SWIG generates some glue C++ 
code which should be compiled as _rtcom.so. This shared object must lie 
somewhere in Python's search path. _rtcom.so obviously needs to link at 
runtime to rtcom.so, the original C++ library. 

For various reasons, however, I do not want to install rtcom.so in the 
standard library directories. This generally is not a problem, as linking an 
object using ld --rpath LibraryPath, it is possible to tell the dynamic 
linker where to find a shared library.

As I understand it, this is a typical libtool task. I used the following 
Makefile.am to generate the tools:

## Makefile.am #
BUILT_SOURCES = rtcom_wrap.cpp rtcom_wrap.h
SWIG_SOURCES = rtcom.i

pkgpython_PYTHON = rtcom.py
pkgpyexec_LTLIBRARIES = _rtcom.la
_rtcom_la_SOURCES = $(BUILT_SOURCES) $(SWIG_SOURCES)
_rtcom_la_CPPFLAGS = $(SWIG_PYTHON_CPPFLAGS) -I$(top_srcdir)
_rtcom_la_LDFLAGS = -module
_rtcom_la_LIBADD = ../librtcom.la

-include $(DEPDIR)/rtcom_wrap.d
rtcom_wrap.cpp: $(SWIG_SOURCES)
$(SWIG) $(SWIG_PYTHON_OPT) -I$(top_srcdir) \
-MMD -MF $(DEPDIR)/rtcom_wrap.d -o $@ $

rtcom_wrap.h: $(SWIG_SOURCES)
$(SWIG) $(SWIG_PYTHON_OPT) -I$(top_srcdir) \
-MMD -MF $(DEPDIR)/rtcom_wrap.d -oh $@ $
##

make install calls:
../libtool --mode=install /usr/bin/install -c  '_rtcom.la' \
'/opt/etherlab/lib/python2.5/site-packages/rtcom/_rtcom.la'
which in turn calls:
/bin/sh ../libtool  --tag=CXX --mode=relink g++ -g -O2 \
-o _rtcom.la \
-rpath /opt/etherlab/lib/python2.5/site-packages/rtcom \
-module _rtcom_la-rtcom_wrap.lo ../librtcom.la -lexpat
The relink calls g++, however _without_ the necessary 
-Wl,--rpath -Wl,/opt/etherlab/lib options to g++

The complete install log is attached.

It is then no surprise that loading the module under Python fails:
---
 import sys
 sys.path.append('/opt/etherlab/lib/python2.5/site-packages/rtcom')
 import rtcom
Traceback (most recent call last):
  File stdin, line 1, in module
  File /opt/etherlab/lib/python2.5/site-packages/rtcom/rtcom.py, line 5, in 
module
import _rtcom
ImportError: librtcom.so.2: cannot open shared object file: No such file or 
directory
---


As a workaround, I replace _rtcom_la_LDFLAGS in Makefile.am with:
_rtcom_la_LDFLAGS = -module -Wl,--rpath -Wl,$(libdir)
Then it works.

As I understand it, this should be libtool's task. All the necessary 
information about where rtcom.so is installed is contained in the rtcom.la 
file. What am I missing out on here?

My autotools configuration is:
autoconf-2.60-21
automake-1.9.6-35
libtool-1.5.22-34

I am also using ac_pkg_swig.m4  ac_python_devel.m4  swig_enable_cxx.m4  
swig_python.m4 downloaded from http://autoconf-archive.cryp.to/

Many thanks in advance for any help.

- Richard
make  install-am
make[1]: Entering directory `/home/rich/msr-gate/rtcom/pyext'
make[2]: Entering directory `/home/rich/msr-gate/rtcom/pyext'
test -z /opt/etherlab/lib/python2.5/site-packages/rtcom || mkdir -p -- /opt/etherlab/lib/python2.5/site-packages/rtcom
 /bin/sh ../libtool --mode=install /usr/bin/install -c  '_rtcom.la' '/opt/etherlab/lib/python2.5/site-packages/rtcom/_rtcom.la'
libtool: install: warning: relinking `_rtcom.la'
(cd /home/rich/msr-gate/rtcom/pyext; /bin/sh ../libtool  --tag=CXX --mode=relink g++ -g -O2 -o _rtcom.la -rpath /opt/etherlab/lib/python2.5/site-packages/rtcom -module _rtcom_la-rtcom_wrap.lo ../librtcom.la -lexpat )
g++ -shared -nostdlib /usr/lib/gcc/i586-suse-linux/4.1.2/../../../crti.o /usr/lib/gcc/i586-suse-linux/4.1.2/crtbeginS.o  .libs/_rtcom_la-rtcom_wrap.o  -L/opt/etherlab/lib -lrtcom -lexpat -L/usr/lib/gcc/i586-suse-linux/4.1.2 -L/usr/lib/gcc/i586-suse-linux/4.1.2/../../../../i586-suse-linux/lib -L/usr/lib/gcc/i586-suse-linux/4.1.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i586-suse-linux/4.1.2/crtendS.o /usr/lib/gcc/i586-suse-linux/4.1.2/../../../crtn.o  -Wl,-soname -Wl,_rtcom.so.0 -o .libs/_rtcom.so.0.0.0
/usr/bin/install -c .libs/_rtcom.so.0.0.0T /opt/etherlab/lib/python2.5/site-packages/rtcom/_rtcom.so.0.0.0
(cd /opt/etherlab/lib/python2.5/site-packages/rtcom  { ln -s -f _rtcom.so.0.0.0 _rtcom.so.0 || { rm -f _rtcom.so.0  ln -s _rtcom.so.0.0.0 _rtcom.so.0; }; })
(cd /opt/etherlab/lib/python2.5/site-packages/rtcom  { ln -s -f _rtcom.so.0.0.0 _rtcom.so || { rm -f _rtcom.so  ln -s _rtcom.so.0.0.0 _rtcom.so; }; })
/usr/bin/install -c .libs/_rtcom.lai /opt/etherlab/lib/python2.5/site-packages/rtcom/_rtcom.la
/usr/bin/install -c .libs/_rtcom.a

Re: ld --rpath problem using libtool

[Ralf Wildenhues]

Hello Richard,

I agree with your analysis that libtool should add the rpath, from what
I can tell.

* Richard Hacker wrote on Mon, Jan 07, 2008 at 08:59:37AM CET:
 
  /bin/sh ../libtool --mode=install /usr/bin/install -c  '_rtcom.la' 
 '/opt/etherlab/lib/python2.5/site-packages/rtcom/_rtcom.la'
 libtool: install: warning: relinking `_rtcom.la'
 (cd /home/rich/msr-gate/rtcom/pyext; /bin/sh ../libtool --tag=CXX 
 --mode=relink g++ -g -O2 -o _rtcom.la -rpath 
 /opt/etherlab/lib/python2.5/site-packages/rtcom -module 
 _rtcom_la-rtcom_wrap.lo ../librtcom.la -lexpat )

Could you please post the output of
  /bin/sh ../libtool --tag=CXX --config

as well as the debug output of the relink command, i.e. of this (both
stdout and stderr):

(cd /home/rich/msr-gate/rtcom/pyext; /bin/sh ../libtool --debug --tag=CXX 
--mode=relink g++ -g -O2 -o _rtcom.la -rpath 
/opt/etherlab/lib/python2.5/site-packages/rtcom -module _rtcom_la-rtcom_wrap.lo 
../librtcom.la -lexpat )

You can gzip large files.

Thanks,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: removing rpath from libtool

[Russ Allbery]

BRIAND, Michel M [EMAIL PROTECTED] writes:

 I would like to know why LD_LIBRARY_PATH is evil.

There are many reasons, but one of the biggest ones is that it's a giant
hammer that affects every binary that you run with it set.  Even if you
only set it in a wrapper script, it affects every program run by that
program.  So you end up having it affect programs that you don't expect,
which as soon as you have multiple copies of libraries installed in
different places can cause serious problems.

It's very common for people using LD_LIBRARY_PATH with some libraries
installed in one of those paths (such as new SSL libraries) to have
system-provided binaries start failing in weird ways because
LD_LIBRARY_PATH overrides the default search path for those binaries as
well and points them at shared libraries that you aren't expecting.

rpath is specific to one executable or library, and hence is much more
targetted and doesn't have the same far-reaching effect.

LD_LIBRARY_PATH can be used safely and many large installations do use it
safely, but it's dangerous and tricky.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool doesn't set -rpath automatically when needed?

[Ralf Wildenhues]

Hello Benoit,

* Benoit SIGOURE wrote on Fri, Nov 02, 2007 at 10:34:13PM CET:
 On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4  
 (1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under /usr/ 
 local/lib (pre-built binaries: http://www.tsunanet.net/~tsuna/ 
 boost_1_34_1-i486-linux-gcc41.tar.gz) and when I link with `- 
 lboost_thread-gcc41-mt-1_34_1 -pthread' I can't run the executable  
 without manually setting LD_LIBRARY_PATH.  Shouldn't libtool do  
 something about this?  I know that Boost doesn't come with .la files  
[...]

Libtool doesn't add run paths to installed libraries without .la files.
(How should it know that it should not only add /usr/local/lib, but also
/opt/foo/lib because that is needed as well?  OK, this question is moot
on GNU/Linux, but not on other systems.)

You can use -R/usr/local/lib to make libtool add one.

 but since /usr/local/lib isn't in sys_lib_search_path_spec, shouldn't  
 it use -rpath and friends when available/required?
 What would be the best solution to handle this issue?  Write my own  
 check to see how to set the rpath (-rpath/-Wl,-rpath/-R/etc.) and  
 check if linking against -lboost_thread* requires a -rpath or not,  
 and if it does, automagically add it to BOOST_THREADS_LDFLAGS?  That  
 sounds tedious.  And how is it going to work on, say, OSX, where  
 there is no -rpath/-R?

OS X is not so much a problem because it remembers the location of the
library that was linked against at link edit time.

 Moreover, I don't see how to do such a check  
 while preserving cross-compilation capabilities (since checking  
 whether -rpath works or not requires to run the binary somehow,  
 doesn't it?

You don't need to, AC_PROG_LIBTOOL does that for you.

 Or maybe analyzing the output of `ldd'?

AC_PROG_LIBTOOL does that for you, too, on GNU/Linux.  Query by
  eval `${LIBTOOL} --config | grep ^sys_lib_search_path_spec=`

 But it surely  isn't something standard, for instance on OSX it's
 `otool -L' and it  requires the package odcctools...).

Hmm, I don't think we do that, but what would it be good for?

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool doesn't set -rpath automatically when needed?

[Benoit SIGOURE]

On Nov 3, 2007, at 9:53 AM, Ralf Wildenhues wrote:


Hello Benoit,

* Benoit SIGOURE wrote on Fri, Nov 02, 2007 at 10:34:13PM CET:

On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4
(1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under / 
usr/

local/lib (pre-built binaries: http://www.tsunanet.net/~tsuna/
boost_1_34_1-i486-linux-gcc41.tar.gz) and when I link with `-
lboost_thread-gcc41-mt-1_34_1 -pthread' I can't run the executable
without manually setting LD_LIBRARY_PATH.  Shouldn't libtool do
something about this?  I know that Boost doesn't come with .la files

[...]

Libtool doesn't add run paths to installed libraries without .la  
files.
(How should it know that it should not only add /usr/local/lib, but  
also
/opt/foo/lib because that is needed as well?  OK, this question is  
moot

on GNU/Linux, but not on other systems.)

You can use -R/usr/local/lib to make libtool add one.


I don't want libtool to add run paths to already installed libraries  
(this is obviously impossible, simply because it would require root  
privileges to change /usr/local/lib/libboost_*), I'd like libtool to  
add a run path to my own library/program so that I can run them  
without having to deal with LD_LIBRARY_PATH issues.



Moreover, I don't see how to do such a check
while preserving cross-compilation capabilities (since checking
whether -rpath works or not requires to run the binary somehow,
doesn't it?


You don't need to, AC_PROG_LIBTOOL does that for you.


OK great so maybe I can copy/paste the part of AC_PROG_LIBTOOL that  
does this in my own macro so I can portably figure out the -rpath/-R/ 
etc. options needed and then add them to BOOST_THREADS_LDFLAGS,  
right?  I don't think it'd be a good idea to add AC_REQUIRE 
([AC_PROG_LIBTOOL]) to my BOOST_THREADS macros...

How does that sound?

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory




PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool doesn't set -rpath automatically when needed?

[Ralf Wildenhues]

* Benoit SIGOURE wrote on Sat, Nov 03, 2007 at 11:44:15AM CET:
 On Nov 3, 2007, at 9:53 AM, Ralf Wildenhues wrote:
 
 Libtool doesn't add run paths to installed libraries without .la  
 files.  (How should it know that it should not only add
 /usr/local/lib, but  also /opt/foo/lib because that is needed as
 well?  OK, this question is  moot on GNU/Linux, but not on other
 systems.)
 
 You can use -R/usr/local/lib to make libtool add one.
 
 I don't want libtool to add run paths to already installed libraries  
 (this is obviously impossible, simply because it would require root  
 privileges to change /usr/local/lib/libboost_*),

That's a misunderstanding (and upon rereading my previous post, I see
why I was unclear), so again:

If you link a library or program against an installed non-libtool
library, then libtool will not add a run path entry pointing to that
library's directory.

You can do so yourself however by passing -R... to libtool.

 I'd like libtool to  
 add a run path to my own library/program so that I can run them  
 without having to deal with LD_LIBRARY_PATH issues.

Yes.

 Moreover, I don't see how to do such a check
 while preserving cross-compilation capabilities (since checking
 whether -rpath works or not requires to run the binary somehow,
 doesn't it?
 
 You don't need to, AC_PROG_LIBTOOL does that for you.
 
 OK great so maybe I can copy/paste the part of AC_PROG_LIBTOOL that  
 does this in my own macro so I can portably figure out the -rpath/-R/ 
 etc. options needed and then add them to BOOST_THREADS_LDFLAGS,  
 right?  I don't think it'd be a good idea to add AC_REQUIRE 
 ([AC_PROG_LIBTOOL]) to my BOOST_THREADS macros...
 How does that sound?

You don't *need* to find out how -rpath/-R works.  Just pass -R to
libtool, it will translate that into -Wl,-rpath or whatever else.

You *only* need to find out how -rpath/-R works in case the users of
your macro may not want to use Libtool at all.  In that case, be advised
to use the gnulib module havelib, because it does exactly what you need.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool doesn't set -rpath automatically when needed?

[Benoit SIGOURE]

On Nov 3, 2007, at 12:57 PM, Ralf Wildenhues wrote:


* Benoit SIGOURE wrote on Sat, Nov 03, 2007 at 11:44:15AM CET:

OK great so maybe I can copy/paste the part of AC_PROG_LIBTOOL that
does this in my own macro so I can portably figure out the -rpath/-R/
etc. options needed and then add them to BOOST_THREADS_LDFLAGS,
right?  I don't think it'd be a good idea to add AC_REQUIRE
([AC_PROG_LIBTOOL]) to my BOOST_THREADS macros...
How does that sound?


You don't *need* to find out how -rpath/-R works.  Just pass -R to
libtool, it will translate that into -Wl,-rpath or whatever else.

You *only* need to find out how -rpath/-R works in case the users of
your macro may not want to use Libtool at all.  In that case, be  
advised
to use the gnulib module havelib, because it does exactly what you  
need.


Oh I see.  Great.  All in all, I think I do better document that  
libtool is required because it does solve all sorts of problems.   
What's the recommended way of doing this?  Simply stating the  
dependency in the documentation and trust the users to Do The Right  
Thing?  AC_REQUIRE([AC_PROG_LIBTOOL])?  Doing some m4-check to ensure  
that something m4_define'd by AC_PROG_LIBTOOL is indeed defined when  
my macro is invoked?  Or doing a runtime check to check that one of  
libtool's variables is properly set and bailing out with an  
AC_MSG_ERROR if not?


--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory




PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool