Jeff Squyres wrote:
I think that any project that uses AM+LT for compiling multi-threaded
applications that uses any of those flags will fail to link properly,
right? And these flags (-pthread, -mt, etc.) are typically the
recommended method of compiling / linking multi-threaded applications.
Gary V. Vaughan wrote:
Sander, if you want to check whether a particular library is shared,
we should be able to write a macro for you to figure that out without
actually needing to roll and run an entire libtool script. Or is
there more to your problem than that?
There _is_ more to his problem
Gary V. Vaughan wrote:
So we need an LT_CHECK_LIB macro in libtool-2-0, which may be possible
by looking in .la files and the results of the other libtool configure
time tests to construct an ld based link line -- or may force us to go
back to a non-config.status generated libtool.
Either way, the
Bill Moseley wrote:
I don't really understand why libxml2 got linked in statically and not
libz. I assume that's an issue in my Makefile.am file or how we setup
libz and libxml2 in our configure script.
It's probably because libxml2 itself is installed using libtool (and
thus there is a
Alexandre Oliva wrote:
It's not exactly a bug. The problem is that libtool can't tell that
some directory needed to bring in dep libs is to be used only at build
time. We need some mechanism to tell libtool to strip certain
directories from the installable .la file, something like -option
/dir,
Makefile.am contains:
bin_PROGRAMS = src/nALFS
src_nalfs_LDFLAGS = -dlopen self
When configure is given --enable-static --disable-shared, the link of
src/nALFS produces this warning:
./libtool: line 1: src/.libs/src/nALFS.exp: No such file or directory
This comes from line 4296 of the CVS
Here's a hard one to fix:
My program has about 30 plugin modules. The Makefile.am provides
-dlopen modulepath for each one, so that if the user chooses to
disable shared libraries, the plugins will be preloaded into the
(static) program binary. This works fine.
However, the generated Makefile
libtool reexecs itself when --mode=install is used to install a
library (it runs --mode=finish automaticall). However, if the user
specified --debug and/or --silent to the --mode=install command, those
are not passed to the --mode=finish command that is run automatically.
This patch fixes
As was discussed earlier this week, I'd like to have a function that allows my
application to enumerate the modules that have been preloaded after lt_dlinit()
has been called. The patches below add a function called lt_dlopen_preloaded,
with no arguments, that just walks the preloaded symbols
As a followup to the discussion earlier this week, I'd like to suggest the patch
below. This
causes ltdl to _always_ set handler-info.name to a canonicalized library name,
instead of
only doing it for libtool-created modules. The only disadvantage that I can see to
doing this
is that when
Gary V. Vaughan wrote:
You're not supposed to call the loaders directly, just use lt_dlsym, and
it will add the prefix for you:
I _am_ calling lt_dlsym; the problem is that because the module name
as it appears in lt_preloaded_symbols does not end in .la (it's
module.a there), then lt_dlopen
Gary V. Vaughan wrote:
I've not come across needing to dynamically determine the names of
statically preopened modules with ltdl before, and there is no API
support for that, but since your Makefile.am has to know which modules
were preopened (when it passes the -dlopen flags to libtool), why
Gary V. Vaughan wrote:
In your Makefile.am:
libfoo_la_LDADD += $(LIBADD_DL)
or
program_LIBADD += $(LIBADD_DL)
This works, thanks. Although automake wants it the other way around
(LIBADD for libraries and LDADD for programs).
___
Libtool
Bob Friesenhahn wrote:
For the application I support, we use our own directory scanner to
look for modules (.la files) to load via a fully-qualified path. It
would be useful if this capability was included as part of libltdl.
You can pass a directory path to lt_dlforeachfile, which will then
I've just converted an application to use libtool and ltdl for opening
its plugin modules; part of that conversion required prefixing the
public-visible symbols in the modules with modulename_LTX_, which
ltdl strips when lt_dlsym is called. That all worked fine.
However, one of the reasons for
I've got an application that I've just converted to use the whole
autotools suite... so far things are going quite well. One problem is
that the application contains about 30 plugin modules, and even though
I am creating them using -module and -avoid-version, libtool is still
calling ldconfig
16 matches
Mail list logo
