Re: Accounting for -rpath when libtool isn't helping
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
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
Re: Accounting for -rpath when libtool isn't helping
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
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
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
