Re: AC_LIBTOOL_DLOPEN doesn't add -ldl to any LIBS?
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 the contents of $lt_cv_dlopen_libs to LIBS, and that works, but I'm thinking that relying on the value of an internal macro variable like that is not the best solution. Any better ideas out there? In your Makefile.am: libfoo_la_LDADD += $(LIBADD_DL) or program_LIBADD += $(LIBADD_DL) -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to know what modules were dlpreopen-ed?
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; to that end, I have switched to using ltdl instead of libdl directly, so that I prepare for using dlpreopen-ed modules. Switching to ltdl has not been a problem, I can still build a shared-library version of the app and everything works fine. Now I'm trying to set up support for the preopened modules; I have added the call to LTDL_SET_PRELOADED_SYMBOLS at the appropriate place in the code. However, I cannot find any way to determine the _list_ of modules that were preopened, so that I can lt_dlsym them to get symbol addresses. I don't want to have to know this ahead of time if at all possible, but if I have to build a static list to compile into the program I can do so. I'd much rather just interate through the "real" lt_dlsymlist structure myself and determine what modules were preopened, then go from there. Is this possible? 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 not generate a header that contains the module names? Makefile.am: preopened.h: Makefile @echo "#define MODULE_NAMES \"$(MODULE_NAMES)\"" > preopened.h configure.ac: AC_MSG_CHECKING(for modules to preload) DLPREOPEN= MODULE_NAMES= default_preload='foo bar baz' AC_ARG_WITH([modules], [AC_HELP_STRING([--with-modules=MODULES], [preload MODULES])], [use_modules="$withval"], [use_modules="$default_preload"]) DLPREOPEN="-dlpreopen force" if test -z "$use_modules"; then use_modules=none elif test "$use_modules" != yes; then for module in $use_modules; do DLPREOPEN="$DLPREOPEN -dlpreopen ../modules/$module.la" MODULE_NAMES="$MODULE_NAMES $module" done fi AC_MSG_RESULT($use_modules) AC_SUBST(DLPREOPEN) AC_SUBST(MODULE_NAMES) Maybe you can persuade us that API support for this would be good, and supply us with a patch to implement it? It should just be a simple matter of walking through lt_preloaded_symbols and looking for elements with NULL addresses (these are the module names, or @SELF@ for dlpreopened self). HTH, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: modulename_LTX_ prefix not removed from preloaded symbols?
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.
However, one of the reasons for making this change to libtool was so
that the application could support being statically linked. I have
modified the makefiles to use -dlopen and -dlpreopen where required, and
now I get a static binary built with all the plugins linked in. So far
so good... however, after figuring out a way to get at the
preloaded_symbols list (see my message to this list from yesterday), I
find out that the symbols in this list _do not have the prefix removed_!
In spite of that, presym_sym (the "symbol finder" for preloaded modules)
has no concept of the symbol prefix and makes no attempt to remove it
before checking the symbol list. I now have to construct the prefix in
my code so I can add it to the symbol, but only when I found the module
in the preloaded symbols list.
Is this how this is supposed to work? It doesn't seem logical to me, at
this point I could have built the infrastructure to do this myself
(given that I don't have to support much portability beyond Linux) and
not had to deal with this. Maybe I'm just missing something, but I don't
see why the preloaded-symbols case shouldn't act _exactly_ like the
shared-library-loaded-symbols case.
You're not supposed to call the loaders directly, just use lt_dlsym, and it
will add the prefix for you:
3866/* this is a libtool module */
3867if (handle->loader->sym_prefix)
3868 {
3869strcpy(sym, handle->loader->sym_prefix);
3870strcat(sym, handle->info.name);
3871 }
3872else
3873 {
3874strcpy(sym, handle->info.name);
3875 }
3876
3877strcat(sym, "_LTX_");
3878strcat(sym, symbol);
3879
3880/* try "modulename_LTX_symbol" */
3881address = handle->loader->find_sym (data, handle->module, sym);
Cheers,
Gary.
--
())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())
/ )= GNU Hacker http://www.gnu.org/software/libtool \' `&
`(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: modulename_LTX_ prefix not removed from preloaded symbols?
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 does not think it's a libtool module, and thus never sets handle->info.name to any value. If info.name is not set, lt_dlsym does not have anything to add to the symbol name before the lookup. I'm not really sure what the right way to handle this is; obviously lt_dlopen can't set handle->info.name for all ".a" files as well, because it doesn't know what those are really called. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to know what modules were dlpreopen-ed?
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 not generate a header that contains the module names? Well, therein lies the rub, my configure script itself does not know the list of modules either. I generate Makefile.am using a bootstrap script that scans the source directories for module files, because the application is still in a state of flux and the list changes, plus the user can add their own modules if they desire by just dropping a .c file into the proper directory. So I don't actually know the list at any point where I could create a header file, although I could do so with my bootstrap script, but then I don't know if they will really be preloaded or not because the user may decide to leave --enable-shared in effect... Maybe you can persuade us that API support for this would be good, and supply us with a patch to implement it? It should just be a simple matter of walking through lt_preloaded_symbols and looking for elements with NULL addresses (these are the module names, or @SELF@ for dlpreopened self). (for onlookers, it's actually @PROGRAM@ instead of @SELF@) Yes, this is what I'm doing in my app right now; I added an "extern ... lt_preloaded_symbols[]" declaration and I scan it for NULL addresses that are not @[EMAIL PROTECTED] That gets me the names I can pass to lt_dlopen, and it seems to work fine. Most likely the ideal way to implement an API change would be to add a lt_dlpreloadforeach, that works the same way lt_dlforeach does but for preloaded symbols (it would have to call lt_dlopen internally to get lt_dlhandles for all of them first, though). I can certainly supply a patch for this if you like. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_LIBTOOL_DLOPEN doesn't add -ldl to any LIBS?
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 mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_LIBTOOL_DLOPEN doesn't add -ldl to any LIBS?
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 should know better: my memory needs a parity bit :-) -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: modulename_LTX_ prefix not removed from preloaded symbols?
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 there), then lt_dlopen does not think it's a libtool module, and thus never sets handle->info.name to any value. If info.name is not set, lt_dlsym does not have anything to add to the symbol name before the lookup. I'm not really sure what the right way to handle this is; obviously lt_dlopen can't set handle->info.name for all ".a" files as well, because it doesn't know what those are really called. 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. Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: modulename_LTX_ prefix not removed from preloaded symbols?
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 fine (essentially ignored). When --disable-shared --enable-static is in effect, only static libs are produced, and the preloaded_symbols list contains .a names, not .la names. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to know what modules were dlpreopen-ed?
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 flags to libtool), why not generate a header that contains the module names? Well, therein lies the rub, my configure script itself does not know the list of modules either. I generate Makefile.am using a bootstrap script that scans the source directories for module files, because the application is still in a state of flux and the list changes, plus the user can add their own modules if they desire by just dropping a .c file into the proper directory. So I don't actually know the list at any point where I could create a header file, although I could do so with my bootstrap script, but then I don't know if they will really be preloaded or not because the user may decide to leave --enable-shared in effect... Hmmm. Shouldn't the user add a module by installing a libtool module (.la/.so pair) into the runtime searchpath? Are you trying to support modules on platforms that have no dynamic shared objects? There was talk of putting extra information in a module .la file to allow an application to statically relink itself and exec a while ago. Maybe you would like something like that? Maybe you can persuade us that API support for this would be good, and supply us with a patch to implement it? It should just be a simple matter of walking through lt_preloaded_symbols and looking for elements with NULL addresses (these are the module names, or @SELF@ for dlpreopened self). (for onlookers, it's actually @PROGRAM@ instead of @SELF@) Thanks. Yes, this is what I'm doing in my app right now; I added an "extern ... lt_preloaded_symbols[]" declaration and I scan it for NULL addresses that are not @[EMAIL PROTECTED] That gets me the names I can pass to lt_dlopen, and it seems to work fine. Most likely the ideal way to implement an API change would be to add a lt_dlpreloadforeach, that works the same way lt_dlforeach does but for preloaded symbols (it would have to call lt_dlopen internally to get lt_dlhandles for all of them first, though). I can certainly supply a patch for this if you like. 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 can't really think of a reason why you would want to treat a preloaded module differently than a runtime loaded module, and we went to some lengths to hide the differences at the API level. Perhaps if you explained what it is you are doing with loadable modules, and why you want to identify the preloaded ones during initialisation, as opposed to just loading the .la modules in a given searchpath using lt_dlforeachfile I would be able to understand your needs... Cheers, Gary. -- ())_. Gary V. Vaughangary@(lilith.warpmail.net|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to know what modules were dlpreopen-ed?
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 call your callback function with extension-stripped filenames that it finds in that directory. Your callback function can then call lt_dlopen or lt_dlopenext, whatever is appropriate. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to know what modules were dlpreopen-ed?
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 can't really think of a reason why you would want to > treat a preloaded module differently than a runtime loaded module, and we went > to some lengths to hide the differences at the API level. I believe the default libltdl search path is quite broad. Attempting to load anything that looks like a module in the libltdl search path may lead to unexpected errors/warnings (due to loading shared libs & modules not part of the application) unless the libltdl user has carefully narrowed the search path to only look in a particular directory. 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. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [scons-users] libtool and scons
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, though not at the libtool site. See http://cvs.sourceforge.net/viewcvs.py/cppunit/cppunit/INSTALL-unix, which says: - snip - The MIPSpro compiler requires the "-LANG:std" flag to enable the standard C++ library. You must set the CC variable when you configure, as follows ./configure CC='CC -LANG:std' There is a bug in released versions of libtool prevents the -LANG flag from being properly passed during the linking stage. To check if you have this bug, examine the output of "grep 'no.*irix' libtool". If you see a line like "no/*-*-irix*)" then you suffer from the bug. [A fixed version of libtool will look like "no/*-*-irix* | /*-*-irix*)".] - snip - That note was added years and years ago. It is quite likely that libtool-1.5, released in April 2003, already has the fix. Chad, have you tried updating the app in question to libtool-1.5 to see if that solves the problem? (Yeah, I know it's a pain to update an app to newer libtools; when you do it, be sure to push the patch to the app's maintainer so nobody else has to go through it. I did it for kafee last year; you can see how I did it at http://mail.gnu.org/archive/html/libtool/2002-12/msg00080.html ) - Dan ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: CVS libtool fails under MinGW 1.0
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 environment does not provide a 'file' command so libtool shouldn't be trying to use file magic tests. It is questionable if it is really necessary to test a file with a .DLL extension to verify that what it most likely is. I assume that a recent Cygwin enhancement to be more exacting is causing MinGW builds to fail. Perhaps this stanza (around line 2109 in libtool.m4): cygwin* | mingw* | pw32*) # win32_libid is a shell function defined in ltmain.sh lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL' lt_cv_file_magic_cmd='win32_libid' ;; should be split up into separate mingw and cygwin sections. I still think it's a good idea to disallow inclusion of .a's into dlls (unless they are local convenience libs) because of the havoc that auto-EXport can wreak. And cygwin users have proven over and over to be a bit too cavalier about renaming files specifically to fool the compiler for me to be comfortable with a "test file name only" approach. (And is a given '.a' file really a static library, or the import stub of a DLL?) So, for cygwin, I think win32_libid should still be used. But mingw/MSYS is free to do whatever they like -- including providing a port of 'file'... -- Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Cross compilation, building cross-tools, canadian build
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 autoconf 2.13 than in the latest versions. And binutils, gcc use 2.13 autoconf scripts. 2 - In order to detect the build of cross tools or cross compiling or both, configure scripts do host, target, build comparison themselves. Then if the systems types are the same(in my case i686-pc-linux-gnu), I cannot trigger the right behavior without deeply dive in the configuration scripts modifying them. I wonder what is the targeted final behavior for the build, host, target options: Is this already implemented is autoconf 2.57? If so, what would involve the addition of flags and variables in order to force cross-compilation, building of cross-tools, or even the canadian way? Or, merely, do I miss something? Sylvain ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
