lt_dlcaller_set_data interface question
I ran into the following situation when trying to enhance m4: lt_dlhandle handle = ...; if (initfn = (initfn_t) lt_dlsym(INITFN, handle)) initfn(); if (lt_dlcaller_set_data (id, handle, new_value) == 0 && (str = lt_dlerror())) error (0,0,"unable to change dlcaller data: %s", str); Unfortunately, the error() tripped any time that the module did not provide an optional initfn entry point, and the previous data value was 0 (since for lt_dlcaller_set_data the return value 0 is ambiguous between a valid previous value and an error indicator). Further analysis shows that when a symbol is not present, lt_dlsym sets lt_dlerror to "symbol not found", but lt_dlcaller_set_data does not reset this string. Then, because I followed the documentation that said to check lt_dlerror if lt_dlcaller_set_data returns NULL, and because the string was not reset, the code reports failure even though the data was correctly set. Ultimately, this boils down to an interface question of what should happen if prior errors are ignored: Is this a bug in m4, for not calling lt_dlerror to clear errors after any time lt_dlsym returns NULL? The design for m4 modules is that there are four optional entry points, and the module is acceptable if at least one of the four is provided (most modules will return NULL for lt_dlsym for at least one of the four, and thus trigger lt_dlerror). The current m4 code calls lt_dlsym in numerous places without clearing lt_dlerror when an optional symbol is not found, such as in the lt_dlinterface_id callback. Also, the documentation for lt_dlinterface_interface does not mention anything about whether the callback function is required to reset lt_dlerror, or if it can leave it in an unknown state. Or is it a bug in libtool, for not resetting all prior errors on entry to lt_dlcaller_set_data? In other words, should each libtool function start with a clean state, regardless of whether the user failed to call lt_dlerror to clear out errors from a previous lt_* call? And likewise, when libtool calls the lt_dlinterface_id callback, should it be clearing out any lt_dlerror leftovers generated during the callback? And for this particular case, there is a third option: Maybe it is worth an interface change in the case of lt_dlcaller_set_data? For example, int lt_dlcaller_set_data2(lt_dlinterface_id, lt_dlhandle, void*new_data, void**old_data); where old_data, if not NULL, is set to the prior value, and the return value is unambiguous (0 for success, nonzero for failure)? That way, regardless of whether I ignore prior errors, there is no longer an ambiguity between success and failure, so I no longer need to call lt_dlerror when I know the function succeeded. -- Eric Blake ___ http://lists.gnu.org/mailman/listinfo/libtool
i18n and lt_dlerror
Has anyone tried to use gettext to provide translations for all of the strings returned by lt_dlerror? Should all of the strings in lt_error.h be marked N_, then the program can add lt_error.h to the list in POTFILES.in to pick up the strings that need translation? Are there any strings besides lt_dlerror that would need translation? -- Eric Blake ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: multilib dirs and ld.so
Hi Peter, * Peter O'Gorman wrote on Wed, Sep 05, 2007 at 08:02:59AM CEST: > Proposed patches for branch-1-5 and HEAD. > > Okay to apply? Not quite, I'm afraid. First, please put $CPPFLAGS before $LDFLAGS, for consistency. Then, this code is used in each tag -- Fortran compilers don't like files named conftest.c, nor do they like their contents. ;-) (even if the output is not used for non-C tags, the compile still happens; I guess ac_link helps.) Here's a list of GNU/Linux systems, what it does on them, and what would be missing: Debian etch/x86 (has only /lib): before the patch and after the patch ok: /lib /usr/lib /usr/lib/atlas/sse2 /usr/lib/sse2 /usr/lib/libc5-compat /lib/libc5-compat /usr/i486-linuxlibc1/lib /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/lib/atlas (the system compiler isn't multi-ABI) Ubuntu Dapper/x86_64 (/lib64 is a symlink to /lib, /lib32 exists): before the patch: /lib /usr/lib /usr/local/lib /usr/lib /opt/lib /usr/lib/atlas after the patch: /lib64 /usr/lib64 /usr/local/lib /usr/lib /opt/lib /usr/lib/atlas same with CPPFLAGS=-m32 LDFLAGS=-m32, after the patch: /lib /usr/lib /usr/local/lib /usr/lib /opt/lib /usr/lib/atlas This is clearly wrong (though I think it was that way before as well). Ubuntu Dapper/x86: -- /lib and /lib64 exist, /lib32 does not. after the patch: /lib /usr/lib /usr/local/lib /usr/lib /opt/lib /usr/lib/atlas with -m64 and --host=x86_64-unknown-linux-gnu: /lib /usr/lib /usr/local/lib /usr/lib /opt/lib /usr/lib/atlas Sigh. Gentoo/parisc (has only /lib): -- before and after the patch: /lib /usr/lib /usr/local/lib /usr/lib/opengl/xorg-x11/lib /usr/hppa2.0-unknown-linux-gnu/lib /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.1.2 /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.1.1 /usr/lib/gcc-lib/hppa2.0-unknown-linux-gnu/3.3.6 SuSE/ppc64 (has separate /lib and /lib64, no /lib32): -- before and after the patch: /lib /usr/lib /usr/X11R6/lib64/Xaw95 /usr/X11R6/lib64/Xaw3d /usr/X11R6/lib64 /usr/X11R6/lib/Xaw95 /usr/X11R6/lib/Xaw3d /usr/X11R6/lib /usr/powerpc-suse-linux/lib /usr/ppc-suse-linux/lib64 /usr/ppc-suse-linux/lib /usr/local/lib /usr/openwin/lib /opt/kde/lib /opt/kde2/lib /opt/kde3/lib /opt/gnome/lib /opt/gnome2/lib /lib64 /lib /usr/lib64 /usr/lib /usr/local/lib64 /usr/openwin/lib64 /opt/kde/lib64 /opt/kde2/lib64 /opt/kde3/lib64 /opt/gnome/lib64 /opt/gnome2/lib64 /opt/lib [...] The /usr/lib is certainly problematic, /usr/lib contains lots of .la files. Everything after the first two entries comes from /etc/ld.so.conf. with CPPFLAGS=-m32 LDFLAGS=-m32, after the patch: /lib /usr/lib /usr/X11R6/lib64/Xaw95 /usr/X11R6/lib64/Xaw3d /usr/X11R6/lib64 /usr/X11R6/lib/Xaw95 /usr/X11R6/lib/Xaw3d /usr/X11R6/lib /usr/powerpc-suse-linux/lib /usr/ppc-suse-linux/lib64 /usr/ppc-suse-linux/lib /usr/local/lib /usr/openwin/lib /opt/kde/lib /opt/kde2/lib /opt/kde3/lib /opt/gnome/lib /opt/gnome2/lib /lib64 /lib /usr/lib64 /usr/lib /usr/local/lib64 /usr/openwin/lib64 /opt/kde/lib64 /opt/kde2/lib64 /opt/kde3/lib64 /opt/gnome/lib64 /opt/gnome2/lib64 /opt/mx/lib32/ /opt/mx/lib64/ /opt/lib [...] RHEL 3/x86_64 (/lib64 and /lib exist): - after the patch: /lib64 /usr/lib64 /usr/kerberos/lib /usr/kerberos/lib64 /usr/X11R6/lib /usr/X11R6/lib64 /usr/lib64/qt-3.1/lib with -m32: /lib /usr/lib /usr/kerberos/lib /usr/kerberos/lib64 /usr/X11R6/lib /usr/X11R6/lib64 /usr/lib64/qt-3.1/lib Further, the indiscriminate use of ldd, or absolute file names in the test of course prevents decent cross-compile results. (Not that this is much of a regression, the problem existed before.) Ideally, I would like, in a system that also uses symlinks, to see both the symlink and the real dir present in the search path. We should consider just making this whole setting overridable at configure time. Cheers, Ralf > 2007-09-05 Peter O'Gorman <[EMAIL PROTECTED]> > > * libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [linux]: Try to set > the dynamic linker search path properly for multilib case. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Making shared libraries (DLLs) on Windows: -no-undefined
On 2007-06-23, Peter O'Gorman <[EMAIL PROTECTED]> wrote: > On Sat, 2007-06-23 at 17:37 +, Olly Betts wrote: >> On 2007-05-01, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >> > Generally I think you should be able to just use it everywhere. The >> > Libtool testsuite uses it throughout and I cannot remember a test >> > failure due to it. I'm however not sure whether there was an issue with >> > C++ code some time ago (so this data point may be FUD; sorry for not >> > investigating now). >> >> I encountered problems on Mac OS X with C++ code. I don't have access >> to OS X to check, but this is what I have in configure.ac from working >> on this before: > > -no-undefined on Mac OS X should work as advertised and fail to link if > there are undefined symbols. It is a pity that you don't have the error > any longer, we might be able to find the root cause. I looked at the commit log, but that didn't shed any further light on what the problem was. But I've just stumbled across this old message written by you - I wonder if the issue I hit was related, though I'm not aware of any duplicated symbols: http://thread.gmane.org/gmane.comp.gnu.libtool.patches/7242/focus=7273 Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: multilib dirs and ld.so
On Thu, 2007-09-06 at 00:25 +0200, Ralf Wildenhues wrote: Hi Ralf, thank you for testing! > Further, the indiscriminate use of ldd, or absolute file names in the > test of course prevents decent cross-compile results. (Not that this > is much of a regression, the problem existed before.) > > Ideally, I would like, in a system that also uses symlinks, to see > both the symlink and the real dir present in the search path. > > We should consider just making this whole setting overridable at > configure time. which makes me think maybe doing the simple thing: sys_lib_dlsearch_path_spec64='/lib64 /usr/lib64' sys_lib_dlsearch_path_spec32='/lib32 /usr/lib32' sys_lib_dlsearch_path_specfoo='/lib /usr/lib' if 32bitbuild sys_lib_dlsearch_path_spec="$sys_lib_dlsearch_path_spec32 $sys_lib_dlsearch_path_specfoo $sys_lib_dlsearch_path_spec64 $lt_ld_extra" else sys_lib_dlsearch_path_spec="$sys_lib_dlsearch_path_spec64 $sys_lib_dlsearch_path_specfoo $sys_lib_dlsearch_path_spec32 $lt_ld_extra" fi all inside an AC_CACHE_VAL() (that sets and tests an lt_cv_var) so it can be overridden and so forth, is the best plan. Sigh, indeed. If you think that a 1.5.26 release is urgent, I won't insist that you wait on this. Thanks, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
