AW: improve support for building DLLs on cygwin and mingw
No. __declspec(dllimport) tells the compiler that an indirection is needed. The compiler will simplify '&externvar' to '_imp__externvar'. There is one _imp__externvar per library, but all their values are the same. The "same function name, different address" problem will occur - as far as I understand it - when you don't use __declspec(dllimport) for functions. This is the case when the linker adds trampoline functions looking like: _externfunc: jmp *__imp__externfunc (This case was also a headache in the ELF/IA-64 glibc implementation.) == As far as i know this isn't really true for functions. The function trampolines get generated in the import library on windows (cl) so they are allways present, even if you don't specify dllimport, and they also get used allways if they are present at link time. Other than this is with data, where the trampolines get generated at link time in the resulting binary image. This means that for functions there is absolutely no problem exporting automatically by generating a def file for example (and importing works automatically), but with data one allways needs the __declspec(dllimport) for the trampoline to get generated (export can be done via def file too). I'm currently writing wgcc v2 which implements all this (only dllimport for data is needed anymore, all other __declspecs can be omitted, since all stuff gets generated (a def file, and some .asm code). Cheers, Markus ___ http://lists.gnu.org/mailman/listinfo/libtool
-dlopen self on AIX
Does -dlopen self work on AIX? While building epiphany-1.6.5 on this
platform, seems that not all the correct symbols are being exported.
On AIX 5.3, dlopen_self=no. If -dlopen self is specified, then the
following code is executed (from the 1.5 branch):
if test "$dlself" = yes; then
$show "generating symbol list for \`$output'"
test -z "$run" && $echo ': @PROGRAM@ ' > "$nlist"
# Add our own program objects to the symbol list.
progfiles=`$echo "X$objs$old_deplibs" | $SP2NL | $Xsed -e "$lo2o" |
$NL2SP`
for arg in $progfiles; do
$show "extracting global C symbols from \`$arg'"
$run eval "$NM $arg | $global_symbol_pipe >> '$nlist'"
done
...
First, if noinst_LTLIBRARIES *.la files are specified on the
command-line, their symbol list will not be searched because the only
files searched for symbols is "X$objs$old_deplibs". This should really
be "X$objs$libobjs$old_deplibs$old_convenience".
Running the link line and the progfiles change I get:
$ ../libtool --mode=link xlC_r -O2 -qro -qroconst -qmaxmem=-1
-qarch=com -L/opt/TWWfsw/gettext014/lib -Wl,-brtl
-o epiphany -R/opt/TWWfsw/firefox15/lib -dlopen
self epiphany-ephy-main.o libephymain.la
../src/bookmarks/libephybookmarks.la ../embed/libephyembedfactory.la
../embed/mozilla/libephymozillaembed.la ../embed/libephyembed.la
../lib/widgets/libephywidgets.la ../lib/libephymisc.la
../lib/egg/libegg.la -L/opt/TWWfsw/firefox15/lib -lgtkembedmoz
-lxpcom -lxpcom_core -lplds4 -lplc4 -lnspr4 -lpthreads -ldl ...
rm -f .libs/epiphany.nm .libs/epiphany.nmS .libs/epiphany.nmT
creating .libs/epiphanyS.c
generating symbol list for `epiphany'
extracting global C symbols from `epiphany-ephy-main.o'
extracting global C symbols from `./.libs/libephymain.a'
extracting global C symbols from `../src/bookmarks/.libs/libephybookmarks.a'
extracting global C symbols from `../embed/.libs/libephyembedfactory.a'
extracting global C symbols from
`../embed/mozilla/.libs/libephymozillaembed.a'
extracting global C symbols from `../embed/.libs/libephyembed.a'
extracting global C symbols from `../lib/widgets/.libs/libephywidgets.a'
extracting global C symbols from `../lib/.libs/libephymisc.a'
extracting global C symbols from `../lib/egg/.libs/libegg.a'
(cd .libs && xlc_r -O2 -qro -qroconst -qmaxmem=-1 -qarch=com -c "epiphanyS.c")
rm -f .libs/epiphanyS.c .libs/epiphany.nm .libs/epiphany.nmS
.libs/epiphany.nmT
xlC_r -O2 -qro -qroconst -qmaxmem=-1 -qarch=com -brtl
-o epiphany .libs/epiphanyS.o epiphany-ephy-main.o
-L/opt/TWWfsw/gettext014/lib ./.libs/libephymain.a
../src/bookmarks/.libs/libephybookmarks.a
../embed/.libs/libephyembedfactory.a
../embed/mozilla/.libs/libephymozillaembed.a
../embed/.libs/libephyembed.a ../lib/widgets/.libs/libephywidgets.a
../lib/.libs/libephymisc.a ../lib/egg/.libs/libegg.a
-L/opt/TWWfsw/firefox15/lib -lgtkembedmoz -lxpcom -lxpcom_core -lplds4
-lplc4 -lnspr4 -lpthreads -ldl ...
One of the symbols not being exported is
"language_editor_up_button_clicked_cb". So, let's check out the above:
$ grep language_editor_up_button_clicked_cb .libs/epiphanyS.c
{"language_editor_up_button_clicked_cb", (lt_ptr)
&language_editor_up_button_clicked_cb},
$ nm -BCpg .libs/epiphanyS.o | grep language_editor_up_button_clicked_cb
- U language_editor_up_button_clicked_cb
$ nm -BCpg epiphany | grep language_editor_up_button_clicked_cb
269185316 T .language_editor_up_button_clicked_cb
But what I want is the following:
$ nm -BCpg epiphany | grep language_editor_up_button_clicked_cb
269185316 T .language_editor_up_button_clicked_cb
536936672 D language_editor_up_button_clicked_cb
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Supporting -export-dynamic on AIX
On Tue, Aug 08, 2006 at 02:58:44PM -0500, Albert Chin wrote:
>
> Another version. Patch against branch-1-5 only. I've reordered where
> --export-dynamic occurs so we don't have to worry about the above.
Our use of both $export_dynamic_symbols_cmds and
$export_dynamic_flag_spec somewhat breaks the "whether a program can
dlopen itself" test:
case $lt_cv_dlopen in
dlopen)
save_CPPFLAGS="$CPPFLAGS"
test "x$ac_cv_header_dlfcn_h" = xyes && CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"
save_LDFLAGS="$LDFLAGS"
wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
...
Why? Because we set $export_dynamic_flag_spec to:
_LT_AC_TAGVAR(export_dynamic_flag_spec,
$1)="\${wl}$exp_sym_flag:\$export_symbols"
so, in the above LDFLAGS="$LDFLAGS -Wl,-bexport:". Because -bexport:
requires an argument, we get an error from the linker:
ld: 0706-015 The -b export option needs a parameter.
Option syntax: -b export:PARM
We could make this test pass by creating conftest.exp, setting
export_symbols=conftest.exp, and adding "fnord" to it:
save_LDFLAGS="$LDFLAGS"
echo fnord >conftest.exp
wl=$lt_prog_compiler_wl export_symbols=conftest.exp \
eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
Should we do this or let it continue failing?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
RE: improve support for building DLLs on cygwin and mingw
> gcc reports warnings: > > warning: 'externvar' defined locally after being referenced > with dllimport linkage > warning: 'externfunc' defined locally after being referenced > with dllimport linkage > > Once libtool is changed to not cause link errors for > self-references, there is no need any more for this warning. > gcc should remove this warning. > Thinking more about this, the whole problem goes away with -funit-at-a-time and that is turned on by default at optimization level of 1 or higher. So all that is needed is to make the warning conditional on !flag_unit_at a time (& perhaps on OPT_Wattributes?) It also goes away with C++ frontend, which looks at the whole file before emitting references. Why not just make -funit-at-a-time the default for win32 ports (for those languages that support it).? It seems that this problem is really a GCC vs MSVC compiler difference and it should be addressed in GCC rather in libtool. Danny ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: improve support for building DLLs on cygwin and mingw
Hello Ralf, > | Woe32 problem 1: Exports > [...] > | Methods 2b and 2c don't work for C++, because of the name mangling. > > Well, that assumes that you create an export list (or the asm > statements) manually. Yes, that's what I meant by "a selected set of symbols". > That does not have to be the case: you > could use a tool like `nm' or `dumpbin' to generate the lists. > In fact, I believe libtool does something similar in some cases. Yes, the user can specify a regex for the symbols. Does libtool demangle the C++ symbols so that the user can write a regex that works independently of the compiler's name mangling algorithm? > | Method 2c additionally has the drawback that it works in a single > | configuration only; a library cannot export different sets of symbols > | depending on configuration settings. > > I don't understand this paragraph. You can create an export list > in any way you like right before creating the DLL. This paragraph is about a manually selected set of symbols. Sure you can postprocess this export list right before creating the DLL. That would be a fix to the mentioned drawback; you need extra processing to eliminate this drawback. > | Woe32 problem 2: Exported variables > [...] > |4. Define a macro that expands to __declspec(dllimport) always, and > | use it in all header files of the library that define variables. > [...] > | So, why isn't method 4 in wider use? The reason is that > | > |1. the compiler signals warnings, making the developer think that he > | is on the wrong path, > |2. libtool fails to handle self-references, i.e. references to a > | symbol from within the shared library that exports the symbol lead to a > | link error. > > If I have several code references using the symbol, each of them sees a > declaration decorated with `__declspec(dllimport)', and takes the > address of that symbol, then those pointers will compare equal only for > code within the same library (or executable), right? No. __declspec(dllimport) tells the compiler that an indirection is needed. The compiler will simplify '&externvar' to '_imp__externvar'. There is one _imp__externvar per library, but all their values are the same. The "same function name, different address" problem will occur - as far as I understand it - when you don't use __declspec(dllimport) for functions. This is the case when the linker adds trampoline functions looking like: _externfunc: jmp *__imp__externfunc (This case was also a headache in the ELF/IA-64 glibc implementation.) > > But currently, libtool lacks about 20 lines of code to make this approach > > actually work. > > Well, with those 20 lines there's at least one practical issue: > > `join' isn't part of MSYS (yet), and neither listed in GCS: > http://sourceforge.net/mailarchive/message.php?msg_id=17325152 > So we can't use it easily; or at least we should push for MSYS to > include it. Yes, this would be a good idea. It's not the first time that "join" is needed to get down from O(n^2) to O(n). In the meantime one should recode that statement to use 'sort' and 'sed'/'uniq' instead. > I haven't understood yet how you think to deal with -export-symbols or > -export-symbols-regex. Will the export ordinals remain constant if we > use "the first attempt" to add the _imp__* pointers? > ... library stability ... I've no idea how GNU ld creates DLLs and what guarantees library stability there. Experts? > Next, there is existing software using method 3. Do I understand > correctly that method 4 may be modified to detect this case and still > support it? When a software uses method 3, there are no self-references. The result of the "join" command will be an empty file, and the generated exports.c file will be empty. Hence it will work in this case too. > Another point that comes to mind: mutually dependent libraries. > With manually (i.e,. non-Automake generated) rules we could add a method > to just extract the symbol lists/create the import libs, and create the > dlls afterwards... not sure how to feed that into Automake, though, > should we ever wish to support this there. Scripts for creating mutually dependent libraries should indeed, if they wish to use method 4, be prepared to filter out self-references. But this is not an issue for libtool, since libtool on woe32 requires the "-no-undefined" flag and therefore cannot be used to build mutually dependent libraries. Bruno ___ http://lists.gnu.org/mailman/listinfo/libtool
OMPI workaround (was: Problem with LT 2.1a)
On 9/6/06 11:10 AM, "Ralf Wildenhues" <[EMAIL PROTECTED]> wrote:
> First let me try to point out a workaround for your specific situation:
>
> Since mthca.so is Linux-specific, we can rely on having dlopen available
> for the workaround. Since I assume you would rather not have to modify
> the part (3), let's modify (2): Before dlopen("mthca.so") inside
> libibverbs, let ompi_plugin do an explicit dlopen("libibverbs.so",
> RTLD_GLOBAL). This should cost almost nothing (no system calls
> involved, since libibverbs.so is already opened), and should make the
> set of symbols available for the subsequent mthca.so.
>
> Do I understand correctly that since you do not use the lt_dl*search*
> functions anyway, adding this functionality to opal would be rather
> painless?
(changed the subject to differentiate this reply from the rest of the
thread)
Actually, I wouldn't put it in opal, but rather in the ompi_plugin directly,
because at least currently, it's only a problem for one specific OMPI plugin
(specifically, the OpenIB BTL plugin).
However, the problem here is that this depends on the C code knowing exactly
where the library is. This unfortunately matters for at least one important
scenario: the OFED installer (Open Fabrics Enterprise Distribution --
currently, an InfiniBand software stack installer) builds RPMs for all of
its software (including OMPI) in a temporary tree. This includes packages
that depend on each other (e.g., OMPI depends on libibverbs). Hence, the
libibverbs RPM is created and its [staging] installation tree is simply not
deleted. Other packages that depend on the libibverbs are expected to use
the [staging] installation tree.
Once all of OFED is built, all the RPM build/install trees are deleted.
Installing the RPMs then installs the software into the "real" locations
(and therefore dependencies change).
Currently, OMPI skirts this problem because OMPI is only built once the rest
of OFED is installed in their final locations. I am currently tasked with
making OMPI be able to be built when all the rest of the OFED software is
built (not after the fact, like it is now). Ralf W. and I have had
extensive discussions about this and I have not yet had time to try his
suggestion (link directly to libibverbs.la in the staging installation tree
instead of "-L/staging/install/tree -libverbs").
But the point remains here that if we go the dlopen() route, then the C code
needs to be aware of where libibverbs is -- and at least in this scenario,
it could be in one of two places (and at build time, I won't know that).
The C code could simply traverse LD_LIBRARY_PATH and look for libibverbs,
but that then subverts the ld.so mechanisms and also generally seems icky.
--
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: libraries and namespaces
Hello Ralf, > Slightly related question: are you planning on providing a means to > automatically rename gnulib functions to a library-specific namespace? > As long as there is no policy on interface stability for gnulib, I would > fear to see lots of libraries floating around that all carry some > slightly incompatible version of some rather common symbol name around; > when such issues arise, they tend to be a pain to debug. There is a problem only for documented libraries and for dependent libraries of documented libraries. Would you recommend to rename the functions at the C source code level? Through #defines or asm directives? Or are there solutions at library level? For example is it possible for a library A to export a symbol S, such that when B depends on A and C depends on B, B can use S, but C cannot? Bruno ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: AW: improve support for building DLLs on cygwin and mingw
Hello, Markus Duft wrote: > I implemented wgcc (a compiler wrapper behaving like gcc but calling > cl.exe). Since the target should be to compile sources with minimum > changes i have done lot's of work for this. That's certainly a good idea. I would consider such a tool usable only if it had no arbitrary limits, such as a maximum size of 65000 bytes for an exports list, or similar. (I saw an MSVC error message once "Too many variables in function" for a function with more than 1024 local variables, and don't want to repeat such an experience.) > (gets even better in wgcc v2, one will not need to export anymore, just > import ;o)). This works for shared, and (!!) for static libraries, since > wgcc generates some symbols. Very nice. "Just import" is also the point of the proposed libtool changes. If everyone was using either GNU ld or your wgcc, one could consider implementing this functionality in GNU ld. But there are people who use MSVC direcly or using other wrappers. > This was one of the main problems, that any executeable sources can > _never_ know which library gets linked statically or shared. Yes, I agree that adding the extra export symbols not at DLL construction time but also at .EXE construction time is even better. It allows not only to use the same macro #define DLL_VARIABLE __declspec(dllimport) for all sources that end up in shared libraries but also for any source code, regardless whether it ends up being built shared or statically. > Maybe you want to have a look at it Where are the sources to your wgcc2 ? The source of wgcc1 doesn't appear to generate exports as needed. Bruno ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with LT 2.1a
On Wed, 6 Sep 2006, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Wed, Sep 06, 2006 at 05:37:20PM CEST: On Thu, 7 Sep 2006, Peter O'Gorman wrote: On Sep 7, 2006, at 12:10 AM, Ralf Wildenhues wrote: We could add another interface lt_dlopen_flags (const char *filename, int flags); I'd prefer to be more specific - lt_dlopen_global(const char * filename) Well, the disadvantage being that whenever the next flag comes up that we would like to be able to choose, we cannot just add another #define to ltdl.h, but have to invent yet another function. (Not now, but in some years another flag may just be portable enough; or simply necessary for some reason.) Adding functions is easier than adding flags. The POSIX thread APIs I mentioned use functions to set option flags in an implementation defined opaque structure. This is a very powerful approach since the application never knows the form of the options structure so there are no ABI problems. With this approach, adding a new option is as simple as adding some more accessor functions. If the application wants to use an already installed libltdl, then it is very easy to test for supported functions using autoconf. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: improve support for building DLLs on cygwin and mingw
Danny Smith wrote: > > ... > there is no need any more for this warning. gcc should remove this > warning. > > > Are you sure about that. > > The reason that gcc emits these warnings is this: > gcc -S dllimp.c > > .file "dllimp.c" > .text > .globl _externfunc2 > .def_externfunc2; .scl2; .type 32; .endef > _externfunc2: > pushl %ebp > movl%esp, %ebp > pushl %ebx > subl$4, %esp > movl8(%ebp), %edx > movl__imp__externvar, %eax <<< imported > movl(%eax,%edx,4), %ebx > movl$0, (%esp) > movl__imp__externfunc, %eax <<< imported > call*%eax > leal(%ebx,%eax), %eax > addl$4, %esp > popl%ebx > popl%ebp > ret > .globl _externvar <<< exported > .data > .align 4 The same indirections happen on ELF systems: externfunc2: pushl %ebp movl%esp, %ebp pushl %ebx subl$4, %esp call__i686.get_pc_thunk.bx addl$_GLOBAL_OFFSET_TABLE_, %ebx movl$0, (%esp) call[EMAIL PROTECTED] <<< imported movl8(%ebp), %ecx movl[EMAIL PROTECTED](%ebx), %edx <<< imported addl(%edx,%ecx,4), %eax addl$4, %esp popl%ebx popl%ebp ret ... .globl externvar <<< exported .data .align 4 And it doesn't yield "ambiguities" on ELF systems. > There is dangerous ambiguity. > In the past this kind of ambiguity cause most of the dllimport-related > ICE's in GCC. I assume that GCC has enough maintainers to fix ICEs inside GCC. > Does the client really want to resolve the two symbols using dllimport > semantics? Sure. If someone makes a reference to 'externvar' from within a DLL, and it is also defined in the DLL, it's hard to imagine that he would _not_ want to use the definition from the DLL. > With unit-a-time optimizations, we delay adding the attribute until the > whole unit is processed. Nice, this allows to actually optimize away the indirection. > which is probably what the user wanted. > Maybe not. > Maybe the user really just made a [im|ex] typo. I propose to make 'dllexport' unnecessary, and to make it possible to use 'dllimport' everywhere where the users were used to write either 'dllimport' or 'dllexport', depending on the compilation pass and unit. Your counterargument is that he might wanted to see a warning which reminds him to use 'dllexport' - but this is now unnecessary. This is precisely the point of the simplification. Bruno ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with LT 2.1a
* Bob Friesenhahn wrote on Wed, Sep 06, 2006 at 05:37:20PM CEST: > On Thu, 7 Sep 2006, Peter O'Gorman wrote: > >On Sep 7, 2006, at 12:10 AM, Ralf Wildenhues wrote: > >> > >>We could add another interface > >> lt_dlopen_flags (const char *filename, int flags); > >> > >I'd prefer to be more specific - lt_dlopen_global(const char * filename) Well, the disadvantage being that whenever the next flag comes up that we would like to be able to choose, we cannot just add another #define to ltdl.h, but have to invent yet another function. (Not now, but in some years another flag may just be portable enough; or simply necessary for some reason.) And, playing devil's advocate for a minute: why should local symbols be the default? Global namespace is more like static linkage (dlpreopening if you like), so why should that not rather be the default, just as it was with Libtool-1.5.x? (I don't really think this is such a good idea, but IIRC Alexandre Oliva mentioned a similar reasoning once.) > >The docs would specify that it would attempt to open it in the global > >namespace, but may, in fact, open it locally if there is no API to open > >globally. > > This is a good idea but I think that it should refuse to load the > library/module and return an error instead since if the application > requires use of this API, it is likely broken. It is better to know > about breakage sooner than later. > > A more radical approach would be to not expose the lt_dlopen_global > interface at all if it can't be supported (using #error to report an > error message). That would cause a compile time failure so that the > person building the software can investigate possible alternative > build methods. That could be had, too, with #define's we would not expose. What I'm rather not sure of is whether we can find out for certain at configure time whether we can (or the user needs to) open a certain library with a local name space. At least it's not clear to me that on AIX this does not depend on whether the module being opened was runtime-linked or not. In any case, it seems prudent to check some of the backends for glitches like this before actually adding an interface. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
unresolved symbols with libltdl at runtime
I am having a problem with libltdl version 1.5.22 (Ubuntu 6.06) that I am not having with libltdl version 1.5.16 (Fedora Core 4), and I'm not sure why. At runtime my program runs into unresolved symbols and crashes in the middle of running because it can't find a particular symbol which exists in a plugin which is being loaded by libltdl (as far as I can tell). The weird thing is this problem doesn't occur in Fedora Core 4 but I don't know why. I'm using version 1.9 of the GNU Autotools on both systems and slightly different versions of GCC (4.0.2 vs. 4.0.3). The error I get occurs when one of the plugins makes a call into a dependent plugin. libpluginConfigFileSymbology depends on a call to libpluginSymbologyManager. /home/lowmanp/src/mpv-1.5.2+stuff.ubuntu/kernel/.libs/lt-mpv: symbol lookup error: ./pluginConfigFileSymbology/.libs/libpluginConfigFileSymbology.so.0: undefined symbol: _ZN16SymbologyManager13lookup_symbolEiR10SymbolType\ An nm on libpluginConfigFileSymbology.so.0 shows the symbol is unresolved (as I'm assuming it should be). The symbol is defined in the SymbologyManager library, I just can't figure out why it's not being found. nm .libs/libpluginConfigFileSymbology.so |grep lookup_symbol U _ZN16SymbologyManager13lookup_symbolEiR10SymbolType nm .libs/libpluginSymbologyManager.so |grep lookup_symbol 2ea8 T _ZN16SymbologyManager13lookup_symbolEiR10SymbolType I am using the LTDL_LIBRARY_PATH environment variable with a script to search for and help assist in loading all of the plugins. I'm fairly certain this isn't the problem though because if I do a "make install" I get the same runtime error running out of /usr/bin. Here are my Makefile.am's for the two plugins. I tried removing "-no-undefined" from the two plugins but it didn't help. Not sure what to try from here. pluginSymbologyManager == lib_LTLIBRARIES = libpluginSymbologyManager.la libpluginSymbologyManager_la_SOURCES = \ PluginSymbologyManager.cpp\ PluginSymbologyManager.h\ pluginWrapper.cpp\ pluginWrapper.h\ SymbologyManager.cpp\ SymbologyManager.h libpluginSymbologyManager_la_LIBADD = \ -L$(top_builddir)/common -lmpvcommon \ -lfl @CCL_LIBS@ -lpthread #DEFS += -DWIN32 INCLUDES = \ -I$(top_srcdir)/common \ -I$(top_srcdir)/pluginSymbologyBase \ -I$(top_srcdir)/pluginRenderSymbologyOSG \ @CCL_CFLAGS@ libpluginSymbologyManager_la_LDFLAGS = \ -module\ --debug\ -no-undefined pluginConfigFileSymbology == lib_LTLIBRARIES = libpluginConfigFileSymbology.la libpluginConfigFileSymbology_la_SOURCES = \ PluginConfigFileSymbology.cpp\ PluginConfigFileSymbology.h\ pluginWrapper.cpp\ pluginWrapper.h\ VrsgSymbologyParser.cpp\ VrsgSymbologyParser.h libpluginConfigFileSymbology_la_LIBADD = \ -L$(top_builddir)/common -lmpvcommon \ -lfl @CCL_LIBS@ -lpthread #DEFS += -DWIN32 INCLUDES = \ -I$(top_srcdir)/common \ -I$(top_srcdir)/pluginSymbologyBase \ -I$(top_srcdir)/pluginSymbologyManager \ @CCL_CFLAGS@ libpluginConfigFileSymbology_la_LDFLAGS = \ -module\ --debug\ -no-undefined ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with LT 2.1a
On Sep 7, 2006, at 12:37 AM, Bob Friesenhahn wrote: On Thu, 7 Sep 2006, Peter O'Gorman wrote: On Sep 7, 2006, at 12:10 AM, Ralf Wildenhues wrote: We could add another interface lt_dlopen_flags (const char *filename, int flags); I'd prefer to be more specific - lt_dlopen_global(const char * filename) The docs would specify that it would attempt to open it in the global namespace, but may, in fact, open it locally if there is no API to open globally. This is a good idea but I think that it should refuse to load the library/module and return an error instead since if the application requires use of this API, it is likely broken. It is better to know about breakage sooner than later. Indeed, you're right, the developer can try lt_dlopen_global, and fall back on lt_dlopen if the former is simply a preference. Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with LT 2.1a
On Thu, 7 Sep 2006, Peter O'Gorman wrote: On Sep 7, 2006, at 12:10 AM, Ralf Wildenhues wrote: We could add another interface lt_dlopen_flags (const char *filename, int flags); I'd prefer to be more specific - lt_dlopen_global(const char * filename) The docs would specify that it would attempt to open it in the global namespace, but may, in fact, open it locally if there is no API to open globally. This is a good idea but I think that it should refuse to load the library/module and return an error instead since if the application requires use of this API, it is likely broken. It is better to know about breakage sooner than later. A more radical approach would be to not expose the lt_dlopen_global interface at all if it can't be supported (using #error to report an error message). That would cause a compile time failure so that the person building the software can investigate possible alternative build methods. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with LT 2.1a
On Sep 7, 2006, at 12:10 AM, Ralf Wildenhues wrote: We could add another interface lt_dlopen_flags (const char *filename, int flags); I'd prefer to be more specific - lt_dlopen_global(const char * filename) The docs would specify that it would attempt to open it in the global namespace, but may, in fact, open it locally if there is no API to open globally. Allowing flags as you note would be my second choice. I do believe that an extra libltdl API is warranted here. Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with LT 2.1a
On Wed, 6 Sep 2006, Ralf Wildenhues wrote: I concur with Bob; about a handful of packages that need it one way or the other (after all, it was changed not only for cleanliness, but because some packages needed it changed). We could add another interface lt_dlopen_flags (const char *filename, int flags); and transport that information through the loader_data? Or just lt_dlopen_set_flags (int flags); but that again looks ugly from a serialization point of view (since the user would need to do the locking...). Unsure. Options should be specific to some sort of libltdl handle since multiple libraries used by the same application may make indepenent use of libltdl and their needs may be different. This exposes a design weakness in the libltdl API in that it does not provide an extensible means of supplying options. The POSIX threads API is a good example of an API which uses an extensible means of supplying options in an ABI-safe way. Options like RTLD_GLOBAL have global impact to the application so operation of independent libraries could become ambiguious. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with LT 2.1a
Hello Jeff, all,
* Jeff Squyres wrote on Wed, Sep 06, 2006 at 04:17:33PM CEST:
>
> The situation is as follows:
>
> 1. Open MPI has a plugin (call it "ompi_plugin") that is linked against a
> shared library ("libibverbs.so").
>
> 2. At run time, ompi_plugin is lt_dlopen()'ed by the OMPI core.
>
> 3. The code in libibverbs in ompi_plugin eventually dlopen()'s its own
> plugin (named "mthca.so"; this is a Linux-specific plugin, so libibverbs
> directly uses dlopen(), not lt_dlopen())
>
> 4. mthca.so requires some symbols in libibverbs, but is not linked against
> it.
First let me try to point out a workaround for your specific situation:
Since mthca.so is Linux-specific, we can rely on having dlopen available
for the workaround. Since I assume you would rather not have to modify
the part (3), let's modify (2): Before dlopen("mthca.so") inside
libibverbs, let ompi_plugin do an explicit dlopen("libibverbs.so",
RTLD_GLOBAL). This should cost almost nothing (no system calls
involved, since libibverbs.so is already opened), and should make the
set of symbols available for the subsequent mthca.so.
Do I understand correctly that since you do not use the lt_dl*search*
functions anyway, adding this functionality to opal would be rather
painless?
(I'm not suggesting that we be done with this, or that you should do
this, merely trying to take pressure off the decision in Libtool.)
> Are there any estimates of how many other applications will be hurt by this
> change to libltdl? We might be among the first of many to ask about this.
I concur with Bob; about a handful of packages that need it one way or
the other (after all, it was changed not only for cleanliness, but
because some packages needed it changed).
We could add another interface
lt_dlopen_flags (const char *filename, int flags);
and transport that information through the loader_data?
Or just
lt_dlopen_set_flags (int flags);
but that again looks ugly from a serialization point of view (since the
user would need to do the locking...). Unsure.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with LT 2.1a
On Wed, 6 Sep 2006, Jeff Squyres wrote: Greetings. I'm a longtime Libtool user; we've used both Libtool and libltdl in LAM/MPI and Open MPI (among dozens of other packages!). I've said it before, but I'll say it again -- thanks bunches for Libtool! I have no idea what we'd do without it (and for all the help that Ralf W. and others have provided us over the years). We have run into a problem with LT 2.1a, however (no worries; we realize that it's as-yet unreleased). It took a little poking around to realize what the problem really is: that LT 2.1a's libltdl is no longer lt_dlopen()'ing plugins on Linux with RTLD_GLOBAL. Short version: can libltdl be augmented to allow users to optionally specify using RTLD_GLOBAL? This would solve our problem. There was lengthy mailing list discussion before the RTLD_GLOBAL default was removed. The main reason why it was removed is because it represents non-portable behavior. Applications depending on it won't work in all libtool-supported environments. Libtool is a portability tool. The global namespace conflict issue is less significant (but exists). Making it a specific libtool option (with a strong warning in the documentation) seems reasonable. I certainly understand the desire to not use RTLD_GLOBAL for everything; separate namespaces are generally a Good Thing. I guess my appeal is to allow the caller of lt_dlopen() to optionally specify that they want to use RTLD_GLOBAL. This would solve our problem. Are there any estimates of how many other applications will be hurt by this change to libltdl? We might be among the first of many to ask about this. This is probably the second or third complaint voiced on this list. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Problem with LT 2.1a
Greetings.
I'm a longtime Libtool user; we've used both Libtool and libltdl in LAM/MPI
and Open MPI (among dozens of other packages!). I've said it before, but
I'll say it again -- thanks bunches for Libtool! I have no idea what we'd
do without it (and for all the help that Ralf W. and others have provided us
over the years).
We have run into a problem with LT 2.1a, however (no worries; we realize
that it's as-yet unreleased). It took a little poking around to realize
what the problem really is: that LT 2.1a's libltdl is no longer
lt_dlopen()'ing plugins on Linux with RTLD_GLOBAL.
Short version: can libltdl be augmented to allow users to optionally specify
using RTLD_GLOBAL? This would solve our problem.
Longer version:
The situation is as follows:
1. Open MPI has a plugin (call it "ompi_plugin") that is linked against a
shared library ("libibverbs.so").
2. At run time, ompi_plugin is lt_dlopen()'ed by the OMPI core.
3. The code in libibverbs in ompi_plugin eventually dlopen()'s its own
plugin (named "mthca.so"; this is a Linux-specific plugin, so libibverbs
directly uses dlopen(), not lt_dlopen())
4. mthca.so requires some symbols in libibverbs, but is not linked against
it.
With LT 1.5.22, this works fine. With LT 2.1a, it doesn't because LT 2.1a's
lt_dlopen() no longer uses RTLD_GLOBAL. Specifically, the dlopen() of
mthca.so fails because it can't access the symbols from libibverbs that are
already loaded in the process.
This is actually a pretty big problem for us; we do not have direct control
over the upstream libibverbs (I might be able to get it changed to link
mtcha.so against libibverbs.so, but there would be at least 2 released,
stable versions of libibverbs that would not work with Open MPI).
I certainly understand the desire to not use RTLD_GLOBAL for everything;
separate namespaces are generally a Good Thing. I guess my appeal is to
allow the caller of lt_dlopen() to optionally specify that they want to use
RTLD_GLOBAL. This would solve our problem.
Are there any estimates of how many other applications will be hurt by this
change to libltdl? We might be among the first of many to ask about this.
:-)
--
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems
___
http://lists.gnu.org/mailman/listinfo/libtool
