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

[Paul \"LeoNerd\" Evans]

On Thu, 7 Feb 2019 15:20:32 +0100
Thomas Jahns <address@hidden> 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

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

pgpGNlzYSmETp.pgp
Description: OpenPGP digital signature