Kevin P. Fleming wrote:
My configure.ac uses AC_LIBTOOL_DLOPEN (among many other macros :-), and
this works fine. However, this macro does not seem to record its results
so that the proper dynamic loader library (if one is needed) is added to
the link commands.
As it stands today, I'm adding th
Kevin P. Fleming wrote:
I've got an application here with a number of plugin modules (about 30).
The user can pick and choose which ones they want to build at configure
time, and that all works fine.
I now want to support the user building an all-static version of the
application if they desire
Kevin P. Fleming wrote:
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.
Howeve
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 n
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 mailin
Kevin P. Fleming wrote:
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).
Indeed. My bad. From memory... I shou
Kevin P. Fleming wrote:
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
Gary V. Vaughan wrote:
Are you preopening .a modulenames? You should use the .la filenames.
Have a look at CVS m4, which preloads modules and lt_dlsym opens symbols.
My Makefile.am has
-dlopen src/handlers/alfs.la
-dlopen src/handlers/copy.la
etc.
When --enable-shared is in effect, this works
Kevin P. Fleming wrote:
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
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
cal
On Mon, 13 Oct 2003, Gary V. Vaughan wrote:
>
> lt_dlforeach already calls a user function for each loaded module, perhaps all
> that is needed is:
>
> int lt_dlispreload (lt_dlhandle handle);
>
> lt_dlforeachfile can be used to load the modules in the path (be they
> preloaded or dynamic). I
Chad Austin wrote:
On IRIX, libtool and MIPSPro CC don't get along. To compile
standard C++ code, you need the -LANG:std option, but libtool doesn't
even pass it down to the actual command line, so your code doesn't compile!
This problem and its workaround have, oddly enough, been documented,
th
Bob Friesenhahn wrote:
Libtool (probably the 1.5 release) did used to work under MinGW. A
recent libtool from CVS does not work properly under MinGW. The
symptom is that libtool checks a DLL's validity using the 'file'
command. This fails so use of the DLL library is rejected.
The MinGW MSYS en
Hi,
I wanted to use the build, host, target options to compile a "natively
cross-compiled"(namely from i686-pc-linux-gnu to i686-pc-linux-gnu)
GNU/linux distribution.
But right at the beginning with the binutils I got stuck because:
1 - The build, host, target options are handled differently in
15 matches
Mail list logo
