Re: libtool replacement in C: slibtool

[Sebastian Wiedenroth <wiedi%frubar.net@localhost>]

Hi all,

Below is a mail by midipix clarifying some things that came up here.
As he’s not subscribed to the list please keep him CCed.

He is also very responsive in #midipix on freenode.

Best regards,
Wiedi


> Am 16.05.2016 um 00:13 schrieb writeonce%midipix.org@localhost:
> 
> Just had my attention drawn to this thread. Please feel free to forward
> this message to the list, and also to cc. me in future threads
> concerning slibtool.
> 
> Following are a few answers to questions that came up in elsewhere the
> thread, and see also some notes below regarding the rpath issue:
> 
> * slibtool is a compatibility tool; semantic differences from libtool
> which stem from a misunderstanding should certainly be fixed.
> * cross-compilation and handling of build/host/target should work
> correctly out of the box; if you ever experience problems in that area
> then that's a bug which should be fixed.
> * related to the above: slibtool does not have any whitelists. there are
> several host flavors which require special handling (PE-based hosts,
> Darwin), then all other hosts are assumed to follow the default ELF
> behavior (linux, bsd, etc.).
> * the above by example:
> 
> $ slibtool --config cc
> $ slibtool --config gcc
> $ slibtool --config some-deviant-bsd-tuple-clang
> $ slibtool --config clang --host=some-random-linux-host
> $ slibtool --config clang --target=some-random-linux-target
> 
> 
>> On Thu 05 May 2016 at 21:00:04 +0200, Joerg Sonnenberger wrote:
>>> That still sounds like a pretty fundamental misunderstand of what -rpath
>>> means for libtool. It is essentially the installation directory and
>>> nothing more.
> 
> That is not entirely true, at least not on the five linux distributions
> (alpine, exherbo, ubuntu, centos, suse) where I had the following tested
> (using an explicit -static in compile mode to suppress -fpic -DPIC):
> 
> $ libtool --tag=CC --mode=compile cc -c foo.c -static
> libtool: compile:  cc -c foo.c -o foo.o
> 
> $ libtool --tag=CC --mode=link cc foo.lo -o foo -rpath /usr/local/lib
> libtool: link: cc foo.o -o foo  -Wl,-rpath -Wl,/usr/local/lib
> 
> $ libtool --mode=install install foo $HOME/tmproot/bin
> libtool: install: install foo /home/midipix/tmproot/bin/foo
> 
> $ readelf -a $HOME/tmproot/bin/foo | grep RPATH
> 0x000000000000000f (RPATH)  Library rpath: [/usr/local/lib]
> 
> 
> I should probably mention that our starting point was similar to yours,
> << essentially the installation directory and nothing more >>, however
> when building the sudo package (1.8.16) we realized that rpath was in
> fact necessary due to a dependency on libsudo_util.so.0, installed in
> /usr/libexec which the dynamic linker does not search by default.
> Looking further into this, it turned out that libtool unconditionally
> forwards the -rpath argument to the compiler driver (which then passes
> it to the linker) whenever creating an executable. Since many packages
> happen to have -rpath /usr/[local]/lib in the linker flags regardless of
> whether a library or an executable is being created, we decided to
> forward -rpath to the compiler driver only when that is actually
> required for the application to run.
> 
> To sum up: the current slibtool behavior is to *never* pass -rpath to
> the compiler/linker when creating a library (same as libtool), and to
> pass it to the compiler/linker when generating an executable _only_ when
> that appears to be necessary.
> 
> Best regards,
> midipix
> 
> 
>> I've always seen libtool as something you prefix before a compile/link
>> command. libtool(1) doesn't say anything to contradict that idea; it
>> confirms it with so many words:
> 
>> LINK-COMMAND is a command using the C compiler that you would use to
>> create a program from several object files.
> 
>> so if libtool suddenly does something completely different, then that is
>> news to me, yes.
> 
>> Back to rpath; I would hope that whatever tool is used, it would stick
>> in rpath options automatically and where needed.