Re: [EXTERNAL] Re: Q: Forcing a -Wl,-rpath arg to static lib users
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
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
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
2022-11-17
Thread
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
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
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.
