Inherited linker flags
I'm looking for a way to specify custom flags for the "inherited_linker_flags" setting in my .la. It seems like I need this to implement the semantics of gcc's weak references way I'd like them to work. The scenario: libx.la has a weak reference to symbol "Y". liby.la declares the symbol "Y". For a given binary P, it may be linked either with libx.la alone, or with both libx.la and liby.la. The intended behavior is that in the former case libx sees the weak reference as null, in the latter case libx resolves this symbol from liby. This works as expected when P links libx and liby as shared libraries. This breaks when P links libx and liby as static libraries. There are no strong references to Y, hence its object module does not get statically linked into P, and its reference remains unresolved. It's a catch-22. To satisfy the weak reference, I need to have a strong reference to Y, or to any symbol in Y's module, from P. If I do that, I cannot link P with libx.la alone, the strong references fail to resolve and the link fails. By doing some experimenting, I found that that everything appears to work nicely, if I put "-Wl,--undefined=Y" into liby.la's inherited_linker_flags setting. This apparently carries no impact when "sharedly" linking against liby.la. And when statically linking liby.la the undefined symbol forces the inclusion of Y's module into P, and resolving the weak reference from libx. I could, of course, do the same thing by explicitly specifying the extra linker flag in Makefile.am in P's LDFLAGS. Having this flag in a .la file has the nice effect of libtool automatically handling this. It goes without saying that the whole thing works only on platforms where gcc and binutils have weak references. Aside from manually hacking .la from a Makefile by hand, is there a documented way to put arbitrary stuff into "inherited_linker_flags"? I couldn't find anything promising in the info pages. pgpKLjgTEl4qz.pgp Description: PGP signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Bad LD_LIBRARY_PATH set in the libtool wrapper
My source tree builds two libraries, from two separate directories in the source tree. libxtls.la gets linked against libx.la in a different directory, as well as some system libraries in /usr/local/lib. Makefile.am declares thusly: libxtls_la_LIBADD=../base/libx.la libxtls_la_LDFLAGS=-version-info 1 $(GNUTLS_LIBS) $(GCRYPT_LIBS) -lpthread These macros expand to a search path that includes /usr/local/lib. In libxtls.la I end up with this (leaving out some unrelated stuff): dependency_libs="-R/usr/local/lib -L/usr/local/lib [SOURCETREEPATH]/base/libx.la" I then build an executable named "testuseragent_shared" that gets linked against libxtls.la: testuseragent_shared_SOURCES=testuseragent.C testuseragent_shared_LDADD=libxtls.la From this, libtool produces a wrapper for testuseragent_shared in the source tree, that reads as follows (linewrapped): LD_LIBRARY_PATH="[CURRENTDIR]/.libs:/usr/local/lib: [SOURCETREEPATH]/base/.libs:$LD_LIBRARY_PATH" The search path places /usr/local/lib ahead of …/base/.libs, for libx.so.1. It obviously gets it from libxtls_la_LDFLAGS. The problem here is when I already have a previously installed, older libx.so.1 build in /usr/local/lib, and I run testuseragent_shared from the source tree, it ends up loading the older libx.so.1 from /usr/local/lib, rather than the one that also gets built in the source tree. Hilarity ensues. Yes, I know about -static, and I also produce a testuseragent_static linked with -static, that works splendidly from the source tree. But I'd really like to have a dynamically-linked testuseragent_shared and run it from the source tree, with the wrapper's help, for regression testing purposes. I must be doing something fundamentally wrong here, but I can't figure it out. The more I think about it, the more I'm leaning towards thinking that libtool should always put source tree paths ahead of any system paths, in the wrapper. This is libtool 2.4. pgpj4qALO6AA6.pgp Description: PGP signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: library libltdlc.la
Gary V. Vaughan writes:
libltdlc.{a,la} is a convenience library - that is an ar(1) archive of
shared objects to be statically linked (copied) into a program directly. It
is never installed, but built from sources included in the distribution of
the parent package.
You should find that the courier main server source tree you are building
from either contains a copy of the libltdl sources already, or else has a
bootstrap (or autogen.sh) script that copies the libltdl sources into the
tree using the libtoolize script installed along with the other libltdl
files you just installed separately.
If the process isn't working properly, the maintainers of courier main
server are much better placed to help you find the right combination of
build commands, or else fix bugs in their libltdl integration.
Let's cut out the middle-man here. courier-authlib includes a copy of ltdl,
but there's nothing particularly strange about it. There's an LTDL_INIT in
configure.ac, and a fairly boring collection of _LTLIBRARIES in Makefile.am.
That's it.
I have no idea what's going wrong here. This is plain vanilla stuff. My
suspicion is that the configure stuff is there's some confusion between the
bundled and a system-installed copy of libtool.
I would suggest using --with-included-ltdl with configure, to force libtool
use the bundled copy of libtool.
___
https://lists.gnu.org/mailman/listinfo/libtool
Removing multiple copies of ltmain.sh
I have about a dozen libraries that get built with libtool. They're all convenience libraries but they can be developed individually, so they have their own configure script, as well as as all the libtool-related scripts. These libraries are included in five major projects, in various combinations. So when the major projects get packaged, the tarball gets multiple copies of ltmain.sh, one in each library subdirectory. Although gzip helps here, it's still quite a mouthful. Can anyone suggest a clean way to eliminate all those copies of ltmain.sh. I can always hack up a hook that replaces them with hardlinks, before the tarball gets created, but perhaps there's a better way. The catch here is that each component library has its own configuration needs, so it needs its own configure script, and that's where the libtool dependency comes from. It's more maintainable to have each library have its own self-contained configure script, then to try to merge, and maintain all those bits in the main project's main configure script. So, I'd like to keep all the libraries with their own self-contained configure script, which get recursively invoked by the main projects' top level configure, but optimize away the multiple copies of ltmain.sh. pgp6fZz3zmqOW.pgp Description: PGP signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Removing multiple copies of ltmain.sh
Bob Friesenhahn writes:
On Sat, 13 Jun 2009, Sam Varshavchik wrote:
Can anyone suggest a clean way to eliminate all those copies of ltmain.sh. I
can always hack up a hook that replaces them with hardlinks, before the
tarball gets created, but perhaps there's a better way. The catch here is
Libtool no longer uses a ltmain.sh file so maybe using a modern
version is the answer to this problem.
The latest version that's available for download is 2.2.6a, and I'm running
2.2.6. I built 2.2.6a and installed it in a BUILDROOT (so as to not affect
my existing 2.2.6 install).
2.2.6a installed ltmain.sh in ${datadir}/libtool/config, and running
2.2.6a's libtoolize installed a symlink to it. As far as I can tell, the
latest version of libtool still uses ltmain.sh.
Are you referring to some libtoolize option that sets up an ltmain.sh-less
version of libtool into my project?
pgpqUJFSWFMJp.pgp
Description: PGP signature
___
http://lists.gnu.org/mailman/listinfo/libtool
dlopening the C runtime library
I'm trying to come up with logic to figure out what I need to pass to
lt_dlopen(), or lt_dlopenext() in order to obtain the standard C runtime
library, for the purposes of using lt_dlsym() to find common library
functions, such as open(), connect(), etc…
I can use a prepared list of common names for the C runtime library one
might find, such as "libc", augmented by supplementary named such as
"libnsl" (a separate library you need to link with on some older platforms
where the socket functions are in a separate library that you have to link
with.
So, I can have a list of common names, such as "libc", and "libnsl", that I
can go through, use lt_dlopenext() to try to open it, then search for my
symbols.
Here's the puzzle that I'm trying to solve. On modern glibc-based platforms
(and I'm sure others too), libc.so is a symlink (or an analogous
system-based redirection mechanism) to a versioned library name. Currently,
for example, the actual library name is libc.so.6. lt_dlopenext("libc")
works only if the platform's development tools are installed. So, on a
machine configured as a development machine, dlopen-ing "libc" works, but
this breaks if I install my application on a runtime-only machine,
lt_dlopen("libc") no longer works, because the libc.so link is not present.
libc.so is not required for running applications. Applications that are
built against libc pick up "libc.so.6" from SONAME, and hence get bound
directly to "libc.so.6", and do not require the libc.so link. I am trying to
come up with something analogous that I can use with libtool's ltdl.
Running something in the configure script would work for me. Has anyone ever
did something like this? Such as, determining that lt_dlopenext() ends up
really opening "libc.so.6", so that's what I really need to open?
pgpWv8gRApxXI.pgp
Description: PGP signature
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: dlopening the C runtime library
Howard Chu writes: Running something in the configure script would work for me. Has anyone ever did something like this? Such as, determining that lt_dlopenext() ends up really opening "libc.so.6", so that's what I really need to open? None of this guesswork should be needed. Since the main program already depends on libc, you should be able to lt_dlopen(NULL) and reference the main program to find libc's symbols. My use case is intercepting a main application's calls to library functions. I set LD_PRELOAD to preload my own shared library which provides replacement symbols for socket(), connect(), etc… My wrapper needs to find the real socket() and connect(). I haven't checked this yet, but I suspect that since my shared library was loaded ahead of libc, after lt_dlopen(NULL), using lt_dlsym() will simply return a pointer to my own symbols, rather than libc's. pgp2tPrbZGJSs.pgp Description: PGP signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dlopening the C runtime library
Ralf Wildenhues writes: * Sam Varshavchik wrote on Sun, Dec 06, 2009 at 02:52:52PM CET: My use case is intercepting a main application's calls to library functions. I set LD_PRELOAD to preload my own shared library which provides replacement symbols for socket(), connect(), etc… What level of portability do you need? GNU/Linux only? ELF? Additional portability is always a plus. ELF portability would certainly be nice. My wrapper needs to find the real socket() and connect(). I haven't checked this yet, but I suspect that since my shared library was loaded ahead of libc, after lt_dlopen(NULL), using lt_dlsym() will simply return a pointer to my own symbols, rather than libc's. Yes, that sounds like it, although I must admit that I haven't fully understood the above description. Uses of -Bsymbolic may give you trouble. You want to intercept an application's calls to a selected set of the standard library's function, such as open() and close(). The classical way is to put together a shared library, and use LD_PRELOAD to force the application to resolve its external references to your own replacements, instead of the standard library's. But then, you still need to invoke the default open() and close(), from the standard library. With a platform-specific solution, you know the exact name of the standard library, which you can dlopen yourself and invoke the real open() and close(), as part of intercepting the application's function calls. I'm trying to figure out something that would have some portability to it. As I said, I can have a prepared list of library names where standard library functions may be found, such as "libc", "c", "libnsl", and just dlopen each one until I find the real open() and close(). Or, I can probe these names in my configure script, and find the exact library name. The problem is that on ELF, linking against "libc" grabs the SONAME from the ELF object, and that's what you end up loading at runtime. So, even though on a development server dlopen of "libc" works, it won't work on a runtime-only server. pgpQkPjeN2E8w.pgp Description: PGP signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dlopening the C runtime library
Simon Richter writes: Hi, On Sun, Dec 06, 2009 at 08:52:52AM -0500, Sam Varshavchik wrote: My wrapper needs to find the real socket() and connect(). I haven't checked this yet, but I suspect that since my shared library was loaded ahead of libc, after lt_dlopen(NULL), using lt_dlsym() will simply return a pointer to my own symbols, rather than libc's. Right. dlsym(RTLD_NEXT, "open") will give you the one that you shadowed; this might not be the real symbol yet as there may be other wrappers loaded, and it might not be the one from libc as applications are allowed to provide their own definitions of symbols and have them take precedence. That looks like what I'm looking for. I don't seem to find an analogous flag for lt_dlsym, in libtool's documentation, so I'll go with native dlsym, then. pgpYA9MiE57Fl.pgp Description: PGP signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Including static libraries in shared libraries with libtool.
I'm trying to do the following with libtool, and it's not quite doing exactly what I want. Can someone suggest the correct way to do the following, with libtool 1.5.6 and automake 1.8.3 on Linux: I'm building several shared libraries. These shared libraries use common code from several static libraries, which I'll refer to as component libraries. Here's an example component library: libauth_la_SOURCES=auth.h authexit.c chain.c checkpassword.c \ [ more sources go here ] libauth_la_LDFLAGS=-static libauth.la is not going to get installed by the final application. It's an internal library whose only intended purpose is to provide some common code for a bunch of shared libraries that will be installed. Here's one such shared library: libauthuserdb_la_SOURCES=authuserdb.c preauthuserdb.c \ [ more sources ] libauthuserdb_la_DEPENDENCIES=libauth.la libauthuserdb_la_LIBADD=libauth.la libauthuserdb_la_LDFLAGS=-module My intentions here are: Build the sources for libauthuserdb.la. Take their object code, and grab whatever modules from libauth.la that are references by stuff in libauthuserdb.la, and place all of that into a shared library. In other words: look up all unresolved symbols from libauthuserdb.la's sources which can be found in the libauth.la. Take whatever modules from libauth.la that libauthuserdb.la needs, and generate a .so containing libauthuserdb_la_SOURCES plus whatever the sources need that can be found in libauth.a Unfortunately, the actual results are different. There are two problem: 1. Libtool takes _all_ modules from libauth.la, and puts them into libauthuserdb.la. I only want the modules that libauthuserdb.la actually needs. 2. For some reason, only the static version of libauthuserdb.la is generated. I don't know why, but libauthuserdb.so is not created, only libauthuserdb.a is created. I am _not_ using the --disable-shared flag with the configure script. I'd like to come up with a solution to do what I want without rearchitecturing the source. Of course, I could simply take the requisite libauth_la_SOURCES, manually add them to libauthuserdb_la_SOURCES, and build a garden-variety shared library, without a dependency on a static library. However, this is not practical. I'm building several shared libraries that use different bits and pieces of the common code, and manually tracking which common source module is used by which shared library is cumbersome. I need to coerce libtool in doing this job for me. pgp8bh9cN9OJc.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Including static libraries in shared libraries with libtool.
Simon Richter writes: Hi, My intentions here are: Build the sources for libauthuserdb.la. Take their object code, and grab whatever modules from libauth.la that are references by stuff in libauthuserdb.la, and place all of that into a shared library. Not possible without reimplementing parts of the linker. Parts of static libraries cannot be linked into shared libraries, as shared libs need to be compiled as position independent code (ld.so on ix86 linux can work around that by mapping the offending library into a private mapping and relocating it, but that is a huge waste of memory and not portable). I can create a static library from PIC modules that libtool already builds. It actually turns out to be fairly easy: libshuserdb.a: libuserdb.la -rm -f $@ cd .libs && $(AR) $(ARFLAGS) ../$@ $(libuserdb_la_OBJECTS:.lo=.o) If there may be additional shared libs that may be built outside of the source tree, you may be better off making a ...-util library that is installed and linked by all of your other libraries. This is transparent to the user, but permits everyone to write their own libraries linking against the -util library. Let's explore this possibility. I have about a dozen small components (a component=library) other. Each component is in its own subdirectory. It can be built, if necessary, by itself. The components are not installed, they are just building blocks. Then, there are several installable shared libraries. Each shared library makes use of various bits and pieces from various component libraries. Your suggestion, as I understand it, is to take all the small component libraries and put them together into a single -util, that every installable shared links against. Fair enough, bit libtool doesn't seem to be able to do that. libutil_la_SOURCES=[ file listing ] libutil_la_LIBADD=subdir1/libcomponent1.la subdir2/libcomponent2.la From what I can see, libtool is not going to add libcomponent1.la and libcomponent2.la to the shared version of libutil.la, it will merely record their SONAME, and I still have to install libcomponent1.so and libcomponent2.so, in addition to libutil.so. Now on the static side, it looks like libtool will methodically unpack libcomponent1.a and libcomponent2.a; then put all of the extracted modules into libutil.a, together with libutil.a's own object modules, so libutil.a has everything. That, pretty much, is what I need to do with the shared library version as well. My component libraries are logically grouped, and each one is dedicated to a specific functionality. I'd rather not break everything up, and manually force everything into libutil.so, making for a big mess. pgpkGx0DsKG4o.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Various race condition in install mode.
I've almost tracked down the source of random link-install failures that
unexpectedly blows up a long build cycle.
I'm using libtool 1.5.6 with automake 1.8.3 on Linux. I'm building a fairly
extensive app that installs a bunch of shared libraries and executables.
And it uses a bunch of convenience libraries along the way.
The build cycle runs on an SMP box, and I use the -j option with GNU make to
build stuff in parallel. gmake's -j option causes gmake to kick off
multiple build commnds as long as, according to Makefile rules, they don't
depend on each other in any way.
I believe that I see at least one, and possibly two problems that result
from this, as well as a third issue that needs to be clarified in libtool's
documentation:
1)
One problem seems to be related to the following code fragment in the
libtool script:
if test "$mode" = relink; then
$run eval '(cd $output_objdir && $rm ${realname}U && $mv $realname
${realname}U)' || exit $?
fi
As far as I can figure this out, under certain conditions, during an install
cycle (I think), libtool temporarily renames a shared library
libname.so.a.b.c as libname.so.a.b.cU, then does something. I also see
this, elsewhere in libtool:
# Restore the uninstalled library and exit
if test "$mode" = relink; then
$run eval '(cd $output_objdir && $rm ${realname}T && $mv $realname
${realname}T && $mv "$realname"U $realname)' || exit $?
exit $EXIT_SUCCESS
fi
# Create links to the real library.
for linkname in $linknames; do
if test "$realname" != "$linkname"; then
$show "(cd $output_objdir && $rm $linkname && $LN_S $realname
$linkname)"
$run eval '(cd $output_objdir && $rm $linkname && $LN_S
$realname $linkname)' || exit $?
fi
done
So there's some switcheroo going on here, with the shared library files
bouncing back and forth.
Now, an automake-generated Makefile will have multiple targets that are
dependend on the 'make install' target (that's simplyfing things a bit, but
that's the general idea).
The bottom line is that gmake is going to kick off multiple 'install'
targets at the same time, because as far as automake knows, the install
action for various binaries and libraries don't have any dependencies on
each other. An install just copies a file, and automake-generated makefile
doesn't think that one file (be it a binary or a library) needs to have
another file installed first.
So, you're going to have multiple invocations of libtool, in install mode,
occuring at the same time. And each instance is going to monkey around with
the shared library files, renaming them back and forth. I think that the
race condition problem here should now appear to be quite obvious.
There used to be a similar problem with autoconf -- where config.status used
scratch files with fixed names, and under certain conditions an
automake-generated makefile could end up running multiple instance of
config.status at the same time, so they ended up scribbling over each
other's temporary files. autoconf eventually got fixed by embedding the
process id into temporary file names.
It looks like some form of locking is needed in install mode, so that
multiple libtool installs are not going to stomp over each other's shared
libraries.
One postscriptum to add is that I do not actually specify the -j option to
gmake explicitly, I place the -j option in the MAKEFLAGS environment
variable, so that each instance of a recursively-invoked gmake is going to
run parallel stuff.
2)
Here's an automake-generate rule that depends on the overall 'make install
target':
install-exec-am: install-pkglibLTLIBRARIES install-pkglibexecPROGRAMS \
install-pkglibexecSCRIPTS install-sbinPROGRAMS \
install-sbinSCRIPTS
As we see, there are two sub-targets here of interest:
install-pkglibLTLIBRARIES and install-pkglibexecPROGRAMS. The first one
installs the shared libraries, the second one installs binaries that
potentially link against the shared libraries. Neither target depends on
each other, they only both depend on their parent, the install-exec-am
target. Since install-pkglibexecPROGRAMS does not depend on
install-pkglibLTLIBRARIES, gmake doesn't see any reason why it can't run
these targets in parallel. Conceivably gmake could end up installing one of
the binaries before it finishes installing all the libraries.
From researching the first issue, I understand that libtool in certain
situations, will do linking during the install mode. I haven't yet
confirmed whether libtool tries to link against the libraries in their
final, installation directory that it expects to be there already, or it
will use the copy in the .libs subdirectory. If, as I suspect, it's linking
against the libraries in their final install directories, they may not be
there yet if automake ends up running the install target for one of the
binaries before it finishes running the install targets for the libraries.
The reason why I
Re: Various race condition in install mode.
Bob Friesenhahn writes:
So I was forced to read through a long (and well written) email before
the crux of the matter appeared. If make should not be running these
targets in parallel then this smells like an Automake problem to me.
No, from automake's perspective there are no dependencies between these
targets. One target copies some libraries to the install directory. The
other target copies some binaries to their install directory:
install library.so %{_libdir}
and
install binary %{_bindir}
It is a libtool-introduced dependency that now requires the library to be
installed before the binary.
This dependency does not exist when libtool is not used.
pgpyudD4Sqr3S.pgp
Description: PGP signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
