FYI: On HP-UX 11.x, link with cc, not ld (sync with HEAD)
Hi Albert, * Albert Chin wrote on Sat, Nov 12, 2005 at 04:14:25PM CET: Updated patch attached. Thank you. I have applied that to branch-1-5. Cheers, Ralf
FYI: ksh88 quote.test fix (was: branch-1-5 UnixWare fixes)
Hi Tim,
* Tim Rice wrote on Sun, Nov 13, 2005 at 12:23:54AM CET:
On Sat, 12 Nov 2005, Ralf Wildenhues wrote:
Does the test pass even with ksh88, after this patch is applied
(CVS HEAD)?
Tests pass on both ksh and ksh88.
Good work.
Thanks for confirmation. Applied to HEAD and branch-1-5, the latter
shown below.
Cheers,
Ralf
* tests/quote.test: Do not fail on harmless shell bug present
in some ksh88 versions.
Reported by Tim Rice [EMAIL PROTECTED] and others.
Index: tests/quote.test
===
RCS file: /cvsroot/libtool/libtool/tests/quote.test,v
retrieving revision 1.6.2.2
diff -u -r1.6.2.2 quote.test
--- tests/quote.test3 Feb 2005 10:03:51 - 1.6.2.2
+++ tests/quote.test13 Nov 2005 15:13:28 -
@@ -114,9 +114,13 @@
$echo = trying: \\$mchar quoting
result=`$libtool -n --mode=$mode $preargs
${preflag}${flag}${mchar}test${mchar} $postargs` || status=1
match=${match_preflag}${flag}\\${mchar}test\\${mchar}
+alt_match=${match_preflag}\${flag}\\${mchar}test\\${mchar}\
case $result in
*$match*)
$echo = passed: $result
+ ;;
+*$alt_match*)
+ $echo = passed (harmless ksh bug): $result
;;
*)
$echo = failed: $result
FYI: branch-1-5: SCO/bugfix patch 7 of 10: Improve SCO platform support
Hi Kean,
* Kean Johnston wrote on Sat, Nov 12, 2005 at 07:15:24PM CET:
Since this is really for a dying libtool branch, what the heck, repost
as above. At least it would match your usage pattern with
-absolute-soname, too.
Ok attached please find the revised patch. I was unable to
avoid the test in the setting of hardcode_libdir_flag_spec
but I think you'll agree this looks a great deal cleaner.
OK, thanks. Yes, that's better. I had thought to avoid the extra
quoting `\$SCOABSPATH' so that it would be invisible to the user from
the libtool output, but the way that is now is ok with me. However,
it's a good idea not to carry this into CVS HEAD for another reason:
Sometime after 2.0 I may want to reform the quoting stuff a bit, both
to allow file names with spaces and possibly for efficiency. Above
may not work any more then.
I went over the patch once, and installed it after a few small
modifications:
- use `test' instead of `[ ]'
- reformat comments a bit, fix typo execurity - security
- fixed quoting of allow_undefined_flag (use single quotes so the
expansion occurs in libtool, not in configure).
A couple of open questions remain:
- was the quoting for allow_undefined_flag different on purpose
(i.e., because of some bug in ltmain)?
- the archive_cmds and archive_expsyms_cmds do not make use of
allow_undefined_flag at all (they used to do so before),
that makes its setting ineffective.
Could you be bothered to post a followup patch to fix this
(including ChangeLog entry, if possible)?
Here's what I installed. In a followup patch, I'll remove the
now-unnecessary cruft from AC_LIBTOOL_LANG_C_CONFIG. :)
Cheers, and thank you,
Ralf
2005-11-13 Kean Johnston [EMAIL PROTECTED],
Tim Rice [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER)
(AC_DEPLIBS_CHECK_METHOD, AC_LIBTOOL_LANG_C_CONFIG)
(AC_LIBTOOL_LANG_CXX_CONFIG, AC_LIBTOOL_PROG_COMPILER_PIC)
(AC_LIBTOOL_PROG_LD_SHLIBS)
[ sco3.2v5, sysv4, sysv4.3, sysv5, sco3.2v5, sco5v6, unixware,
OpenUNIX, sysv4*uw2 ]: Complete overhaul of SCO support.
* THANKS: Updated.
Index: THANKS
===
RCS file: /cvsroot/libtool/libtool/THANKS,v
retrieving revision 1.34.2.12
diff -u -r1.34.2.12 THANKS
--- THANKS 4 Nov 2005 16:46:54 - 1.34.2.12
+++ THANKS 13 Nov 2005 17:32:59 -
@@ -59,6 +59,7 @@
Noah Jeffrey Misch [EMAIL PROTECTED] 2004-07-05
Thorsten Glaser [EMAIL PROTECTED]
2004-10-11
Peter Ekberg [EMAIL PROTECTED] 2005-04-12
+ Tim Rice [EMAIL PROTECTED] 2005-11-10
* The following additional people made especially gracious contributions of
@@ -105,7 +106,6 @@
Steven M. Schultz[EMAIL PROTECTED]
Sven Verdoolaege [EMAIL PROTECTED]
Tim Mooney [EMAIL PROTECTED]
- Tim Rice [EMAIL PROTECTED]
Todd Vierling[EMAIL PROTECTED]
Tom Tromey [EMAIL PROTECTED]
Tor Lillqvist[EMAIL PROTECTED]
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.132
diff -u -r1.314.2.132 libtool.m4
--- libtool.m4 13 Nov 2005 15:09:27 - 1.314.2.132
+++ libtool.m4 13 Nov 2005 17:21:14 -
@@ -1657,13 +1657,6 @@
sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
;;
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
solaris*)
version_type=linux
need_lib_prefix=no
@@ -1689,7 +1682,7 @@
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3*)
+sysv4 | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -1722,17 +1715,27 @@
fi
;;
-sysv5*)
- version_type=linux
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
need_lib_prefix=no
need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext} $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=yes
hardcode_into_libs=yes
- sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
- sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
+ if test
FYI: HEAD: SCO/bugfix patch 7 of 10: Improve SCO platform support
Hi Tim, Kean,
* Tim Rice wrote on Thu, Nov 10, 2005 at 07:59:52PM CET:
On Thu, 10 Nov 2005, Ralf Wildenhues wrote:
Could you or Tim resubmit the patch like this for branch-1-5?
Then, when you forward-port to CVS HEAD, leave out the SCOABSPATH part;
Here is the forward port without the SCOABSPATH bits.
Thanks. Similar to the branch-1-5 patch, I installed this after these
small modifications:
- reformat comments a bit, fix typo execurity - security
- fixed quoting of allow_undefined_flag (use single quotes so the
expansion occurs in libtool, not in configure).
Accordingly, these questions remain here as well:
- was the quoting for allow_undefined_flag different on purpose
(i.e., because of some bug in ltmain)?
- the archive_cmds and archive_expsyms_cmds do not make use of
allow_undefined_flag at all; that makes its setting ineffective.
Could you be bothered to post a followup patch to fix this
(including ChangeLog entry, if possible)?
Installed patch below.
Cheers, and thanks again,
Ralf
2005-11-13 Kean Johnston [EMAIL PROTECTED],
Tim Rice [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER)
(_LT_CHECK_MAGIC_METHOD, _LT_COMPILER_PIC, _LT_LINKER_SHLIBS)
(_LT_LANG_C_CONFIG, _LT_LANG_CXX_CONFIG)
[ sco3.2v5, sysv4, sysv4.3, sysv5, sco3.2v5, sco5v6, unixware,
OpenUNIX, sysv4*uw2 ]: Complete overhaul of SCO support.
* THANKS: Updated.
Index: THANKS
===
RCS file: /cvsroot/libtool/libtool/THANKS,v
retrieving revision 1.49
diff -u -r1.49 THANKS
--- THANKS 4 Nov 2005 16:45:52 - 1.49
+++ THANKS 13 Nov 2005 18:55:59 -
@@ -59,6 +59,7 @@
Noah Jeffrey Misch [EMAIL PROTECTED] 2004-07-05
Thorsten Glaser [EMAIL PROTECTED]
2004-10-11
Peter Ekberg [EMAIL PROTECTED] 2005-04-12
+ Tim Rice [EMAIL PROTECTED] 2005-11-10
* The following additional people made especially gracious contributions of
@@ -105,7 +106,6 @@
Steven M. Schultz[EMAIL PROTECTED]
Sven Verdoolaege [EMAIL PROTECTED]
Tim Mooney [EMAIL PROTECTED]
- Tim Rice [EMAIL PROTECTED]
Todd Vierling[EMAIL PROTECTED]
Tom Tromey [EMAIL PROTECTED]
Tor Lillqvist[EMAIL PROTECTED]
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.43
diff -u -r1.43 libtool.m4
--- libltdl/m4/libtool.m4 12 Nov 2005 11:54:13 - 1.43
+++ libltdl/m4/libtool.m4 13 Nov 2005 17:20:53 -
@@ -2373,13 +2373,6 @@
sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
;;
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
solaris*)
version_type=linux
need_lib_prefix=no
@@ -2405,7 +2398,7 @@
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -2437,6 +2430,28 @@
fi
;;
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext} $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ if test $with_gnu_ld = yes; then
+sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib
/usr/lib /lib'
+ else
+sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+case $host_os in
+ sco3.2v5*)
+sys_lib_search_path_spec=$sys_lib_search_path_spec /lib
+ ;;
+esac
+ fi
+ sys_lib_dlsearch_path_spec='/usr/lib'
+ ;;
+
tpf*)
# TPF is a cross-target only. Preferred cross-host = GNU/Linux.
version_type=linux
@@ -2867,19 +2882,15 @@
lt_cv_deplibs_check_method=pass_all
;;
-sco3.2v5*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
solaris*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]*)
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
case $host_vendor in
motorola)
lt_cv_deplibs_check_method='file_magic
Re: FYI: branch-1-5: SCO/bugfix patch 7 of 10: Improve SCO platform support
* Ralf Wildenhues wrote on Sun, Nov 13, 2005 at 08:06:42PM CET: * Kean Johnston wrote on Sat, Nov 12, 2005 at 07:15:24PM CET: Ok attached please find the revised patch. A couple of open questions remain: - was the quoting for allow_undefined_flag different on purpose (i.e., because of some bug in ltmain)? - the archive_cmds and archive_expsyms_cmds do not make use of allow_undefined_flag at all (they used to do so before), that makes its setting ineffective. Could you be bothered to post a followup patch to fix this (including ChangeLog entry, if possible)? Another one (sorry, I thought I had it listed): - You change shlibpath_overrides_runpath depending on the linker. This makes little sense, as this is a rtld feature, not a ld one. Is there a rationale to this? Cheers, Ralf
FYI: remove lt_prog_cc_shlib cruft
Now that the last use of lt_prog_cc_shlib is gone, we can kill another bit of junk. :) Applied to HEAD and branch-1-5. Cheers, Ralf HEAD: * libltdl/m4/libtool.m4 (_LT_LANG_C_CONFIG): Removed `lt_prog_cc_shlib' cruft, not needed any more. Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.44 diff -u -r1.44 libtool.m4 --- libltdl/m4/libtool.m4 13 Nov 2005 19:04:42 - 1.44 +++ libltdl/m4/libtool.m4 13 Nov 2005 19:32:52 - @@ -4900,20 +4900,6 @@ _LT_COMPILER_BOILERPLATE _LT_LINKER_BOILERPLATE -# -# Check for any special shared library compilation flags. -# -_LT_TAGVAR(lt_prog_cc_shlib, $1)= -if test -n $_LT_TAGVAR(lt_prog_cc_shlib, $1); then - AC_MSG_WARN([`$CC' requires `$_LT_TAGVAR(lt_prog_cc_shlib, $1)' to build shared libraries]) - if $ECHO $old_CC $old_CFLAGS | $GREP [[ ]]$_LT_TAGVAR(lt_prog_cc_shlib, $1)[[ ]] /dev/null; then : - else -AC_MSG_WARN([add `$_LT_TAGVAR(lt_prog_cc_shlib, $1)' to the CC or CFLAGS env variable and reconfigure]) -_LT_TAGVAR(lt_cv_prog_cc_can_build_shared, $1)=no - fi -fi - - ## CAVEAT EMPTOR: ## There is no encapsulation within the following macros, do not change ## the running order or otherwise move them around unless you know exactly branch-1-5: * libtool.m4 (AC_LIBTOOL_LANG_C_CONFIG): Removed `lt_prog_cc_shlib' cruft, not needed any more. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.133 diff -u -r1.314.2.133 libtool.m4 --- libtool.m4 13 Nov 2005 19:06:14 - 1.314.2.133 +++ libtool.m4 13 Nov 2005 19:33:44 - @@ -2634,20 +2634,6 @@ _LT_COMPILER_BOILERPLATE _LT_LINKER_BOILERPLATE -# -# Check for any special shared library compilation flags. -# -_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)= -if test -n $_LT_AC_TAGVAR(lt_prog_cc_shlib, $1); then - AC_MSG_WARN([`$CC' requires `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to build shared libraries]) - if echo $old_CC $old_CFLAGS | grep [[ ]]$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)[[]] /dev/null; then : - else -AC_MSG_WARN([add `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to the CC or CFLAGS env variable and reconfigure]) -_LT_AC_TAGVAR(lt_cv_prog_cc_can_build_shared, $1)=no - fi -fi - - ## CAVEAT EMPTOR: ## There is no encapsulation within the following macros, do not change ## the running order or otherwise move them around unless you know exactly
Re: FYI: branch-1-5: SCO/bugfix patch 7 of 10: Improve SCO platform support
OK, thanks. Yes, that's better. I had thought to avoid the extra quoting `\$SCOABSPATH' so that it would be invisible to the user from the libtool output, but the way that is now is ok with me. However, it's a good idea not to carry this into CVS HEAD for another reason: Sometime after 2.0 I may want to reform the quoting stuff a bit, both to allow file names with spaces and possibly for efficiency. Above may not work any more then. Right, ans I'm sure we will craft an entirely different mechanism for supporting absolute pathnames. A couple of open questions remain: - was the quoting for allow_undefined_flag different on purpose (i.e., because of some bug in ltmain)? Almost certainly not. Most likely just habbit. I'll check to make sure though. - the archive_cmds and archive_expsyms_cmds do not make use of allow_undefined_flag at all (they used to do so before), that makes its setting ineffective. Could you be bothered to post a followup patch to fix this (including ChangeLog entry, if possible)? Absolutely. I think it was an oversight, but I will test and make sure and ocrrect it. Here's what I installed. In a followup patch, I'll remove the Most excelent, thank you Ralf. Kean
Re: FYI: branch-1-5: SCO/bugfix patch 7 of 10: Improve SCO platform support
- You change shlibpath_overrides_runpath depending on the linker. This makes little sense, as this is a rtld feature, not a ld one. Is there a rationale to this? Yes indeed :) And the interpretation of LD_LIBRARY_PATH is an RTLD feature, but both the SVR4 and GNU ld use it during actual library creation. See the man page Tim pointed you at, and the code in binutils/ld/emultempl/elf32.em. The reason it changes based on link editor is that the SVR4/OSR5 ld looks at LD_LIBRARY_PATH first, then at any DT_RUNPATH or DT_RPATH entries its found along the way. In GNU ld, that order is reversed, hence with GNU ld, setting LD_LIBRARY_PATH really doesn't override DT_RUNPATH whereas on OSR5/SVR4, it really does. Without this, two tests, I believe the rebuild ones, fail, and tell you to set shlibpath_overrides_runpath to no (when using GNU ld). Kean
Re: SCO/buffix patch 6 of 10: AC_PROG_NM fixes
Hi Tim, Kean,
Regarding the AC_PROG_NM issue:
* Ralf Wildenhues wrote on Sat, Nov 05, 2005 at 08:54:26AM CET:
Then AFAICS there's only the /usr/ccs/bin/elf path issue left, and the
$ac_tool_prefix one. Regarding the latter, I should add that CVS
Autoconf has the following description for AC_CHECK_TOOL:
*snip*
It may be a good idea for libtool as well not to use the unprefixed name
in the cross-compiling case (or, more appropriately: document that such
a change will happen eventually).
Here's a proposed (not much tested yet) patch for this, shown without
changing the indentation of the inner loop, so that the actual code
changes are easily visible. Could you check that this works for you?
Thanks,
Ralf
* libtool.m4 (AC_PROG_NM): Also look in /usr/ccs/bin/elf,
for SCO. If we are not cross-compiling, but $ac_tool_prefix is
set, also try an un-prefixed `nm'.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.134
diff -u -r1.314.2.134 libtool.m4
--- libtool.m4 13 Nov 2005 19:36:34 - 1.314.2.134
+++ libtool.m4 13 Nov 2005 19:47:14 -
@@ -2412,11 +2412,16 @@
# Let the user override the test.
lt_cv_path_NM=$NM
else
+ lt_nm_to_check=${ac_tool_prefix}nm
+ if test -n $ac_tool_prefix test $build = $host; then
+lt_nm_to_check=$lt_nm_to_check nm
+ fi
+ for lt_tmp_nm in $lt_nm_to_check; do
lt_save_ifs=$IFS; IFS=$PATH_SEPARATOR
- for ac_dir in $PATH /usr/ccs/bin /usr/ucb /bin; do
+ for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do
IFS=$lt_save_ifs
test -z $ac_dir ac_dir=.
-tmp_nm=$ac_dir/${ac_tool_prefix}nm
+tmp_nm=$ac_dir/$lt_tmp_nm
if test -f $tmp_nm || test -f $tmp_nm$ac_exeext ; then
# Check to see if the nm accepts a BSD-compat flag.
# Adding the `sed 1q' prevents false positives on HP-UX, which says:
@@ -2443,6 +2448,7 @@
fi
done
IFS=$lt_save_ifs
+ done
test -z $lt_cv_path_NM lt_cv_path_NM=nm
fi])
NM=$lt_cv_path_NM
FYI: dlinterface breakage (was: cygwin dlopening backends)
Hi Eric,
Factoring out some of the fallout now:
* Eric Blake wrote on Sun, Nov 13, 2005 at 05:50:31AM CET:
This made me realize that there is another problem with
lt_dlinterface_register:
2005-10-26 Eric Blake [EMAIL PROTECTED]
* libltdl/ltdl.c (lt_dlinterface_register): Fail if lt__strdup did.
I have applied this patch to HEAD.
Cheers,
Ralf
2005-11-13 Eric Blake [EMAIL PROTECTED]
* libltdl/ltdl.c (lt_dlhandle_iterate): Fix endless loop.
(lt_dlinterface_register): Fail if lt__strdup did.
Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.236
diff -u -r1.236 ltdl.c
--- libltdl/ltdl.c 26 Oct 2005 10:26:48 - 1.236
+++ libltdl/ltdl.c 13 Nov 2005 21:57:59 -
@@ -2027,7 +2027,10 @@
if (interface_id)
{
interface_id-id_string = lt__strdup (id_string);
- interface_id-iface = iface;
+ if (!interface_id-id_string)
+ FREE (interface_id);
+ else
+ interface_id-iface = iface;
}
return (lt_dlinterface_id) interface_id;
@@ -2125,6 +2128,8 @@
if (!handle)
handle = (lt__handle *) handles;
+ else
+handle = handle-next;
/* advance while the interface check fails */
while (handle iterator-iface
Re: cygwin dlopening backends
Hi Eric,
First, let me thank you for excellent and quick review!
* Eric Blake wrote on Sun, Nov 13, 2005 at 05:50:31AM CET:
Ralf Wildenhues Ralf.Wildenhues at gmx.de writes:
I'm not so sure whether we should register/free the thing in loadlibrary
every time instead of once at the start: those memory checker users
always go nuts when they find a small, constant-amount of allocated
memory not freed before exit().
I'm fine with your approach of creating it just once, because you maintain a
handle to it. If you are really worried about a memory leak, use an atexit()
function to clean up after yourself.
I'll do anything like that only when pushed to. :)
But thanks for mentioning.
Also, I wasn't sure whether paths on w32 (all incarnations) can be bound
by MAX_PATH.
Yes, the cygwin_conv* functions are bounded by MAX_PATH. I would much rather
have an interface that does not have an implicit, arbitrary length (preferring
either the user passes in the max length of a pre-allocated buffer, or the
function itself does the malloc), but that was not done in this case.
ACK.
Currently, MAX_PATH on cygwin is 256 (okay by strict POSIX but not by XSI
standards) because of corresponding limits in the ASCII versions of Windows
syscalls. There is talk (but just that, because it would be a huge patch,
particularly while maintaining backward compatibility) of switching cygwin to
use the Unicode version of Windows syscalls on NT machines (with suitable
fallbacks for the 9x family which only supports ASCII), at which point
MAX_PATH
would be increased to a more reasonable 32k on NT.
Ah, thanks for explaining this. Surely it's a good idea not to waste
lots of stack then. We're not time-critical anyway, malloc is fine.
*snip*
Regarding your review:
+loadlibrary__module_interface (lt_dlhandle handle, const char *id_string)
+{
+ /* we _need_ to look at every module, so pretend all belong to us */
+ return 0;
+}
Hmm, you are actually registering a no-op function, even though
lt_dlhandle_iterate behaves the same (although slightly faster) had you
registered a NULL pointer instead as in my original version of the patch.
But I
guess that is okay, in case we ever change lt_dlinterface_register to require
a
non-NULL function.
Good point. Changed: loadlibrary.c is internal, so we do not need to
rely on public interface specs.
+ char wpath[MAX_PATH];
If cygwin ever increases MAX_PATH beyond 256, self_name_buf and wpath together
would become a huge burden on the stack.
Fixed.
+ if (LT_STRLEN (filename) = MAX_PATH)
Should you cache the length here?...
*snip*
+ {
+ /* Append a `.' to stop Windows from adding an
+implicit `.dll' extension. */
+ searchname = MALLOC (char, 2+ LT_STRLEN (wpath));
...to avoid recalculating it here?
Yes, in some cases. The actual semantics are a bit tricky: when we
want to append the dot, and we have done the cygwin path conversion,
we do need to recalculate the length. See below.
+ if (searchname)
+ sprintf (searchname, %s., wpath);
And since you are already limited by MAX_PATH, and already have wpath that
large, do you really need to malloc searchname, or could you just reuse wpath?
Reusing wpath seems fine, as does not using sprintf. :)
Updated, completely untested patch, except for a quick cross-compile
below (I'll do another w32 round in a couple of days, probably).
Beside addressing your comments, the patch now also sets the errors when
file names are too long, and the check is a bit stricter, too.
Cheers,
Ralf
2005-11-13 Eric Blake [EMAIL PROTECTED],
Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/ltdl.h, libltdl/ltdl.c (lt_dlinterface_free): New
function.
* doc/libtool.texi (User defined module data): Document it.
* libltdl/loaders/loadlibrary.c (iface_id): New variable.
(get_vtable): Get an `iface_id' from `lt_dlinterface_register'.
(get_vtable): Rewrite to catch up with lt_dlhandle_iterate
interface change. Append dot only after w32 path conversion
so it works on cygwin managed mounts.
Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.204
diff -u -r1.204 libtool.texi
--- doc/libtool.texi7 Nov 2005 14:35:35 - 1.204
+++ doc/libtool.texi13 Nov 2005 22:01:26 -
@@ -3848,6 +3848,10 @@
returned by the iteration functions below.
@end deftypefun
[EMAIL PROTECTED] void lt_dlinterface_free (@w{lt_dlinterface_id @var{iface}})
+Release the data associated with @var{iface}.
[EMAIL PROTECTED] deftypefun
+
@deftypefun int lt_dlhandle_map (@w{lt_dlinterface_id @var{iface}}, @w{int
([EMAIL PROTECTED]) (lt_dlhandle @var{handle}, void * @var{data})}, @w{void *
@var{data}})
For each module that matches @var{iface}, call the function
Re: cygwin dlopening backends
Ralf Wildenhues wrote: Hi Charles, That just leaves Eric's comments, and Ralf's point (4). I wonder if it would be a good idea to add --enable/--disable configure flags for every loader...with the default set of loaders determined on a per-platform basis. That's the most flexible (and wouldn't be a cygwin-specific hack), but it seems like it could be really complicated. I postponed that part on purpose. The ever-increasing number of configure switches is frightening. OTOH, choice is good in this case, IMVHO. Maybe we can get away with one switch for all of them. Like this: --disable-ltdl-loaders=LOADER[,...] that sounds good. Have no idea how it should be implemented tho. But there actually is another point I forgot to mention: (3a) if both dlopen and LoadLibrary are used on cygwin, the former _must_ be tried first by ltdl. I believe you mentioned that this is not the case ATM (haven't checked yet). No, I think the wrong-order problem was because of my (now abandoned) patch when packaging libtool for the cygwin distribution. I *believe* the current impl, when both loaders are compiled in, calls dlopen first. But I'll check... I would really like to fix them in order, i.e., fix (4) last. Sure. -- Chuck
Re: cygwin dlopening backends
Charles Wilson wrote:
No, I think the wrong-order problem was because of my (now abandoned)
patch when packaging libtool for the cygwin distribution. I *believe*
the current impl, when both loaders are compiled in, calls dlopen first.
But I'll check...
Hmm.
The behavior I see is odd. It seems that the dlopen loader is loaded
first using dlpreopen. Then, the system tries to use the dlopen loader
to load the loadlibrary loader (and that fails). Next, it tries to load
the loadlibrary loader using dlpreopen -- which succeeds.
From that point on, the order (of loaders used to load other,
non-loader, modules), is:
dlpreopen (which fails)
loadlibrary (which succeeds)
dlopen is never used again. This is odd because I can't see any
*single* list structure that would allow this behavior: if new loaders
are prependend to the internal list, shouldn't they always be tried
before preopen? If new loaders are APPended, shouldn't dlopen always
precede loadlibrary?
Unless there are two lists: one that has the dlpreopen loader (e.g.
always try this first) and the other that has the dynamically-loaded
loaders. In which case, we still have a problem, because in the
ordinary course of events on cygwin we want dlopen to take precedence
over loadlibrary, and right now the opposite is happening.
FYI, I'm using the attached brute force patch to ltdl.c to investigate
this behavior. Here's the results, from running
./mdemo.exe ./foo1.la ./libfoo2.la
Welcome to GNU libtool mdemo!
loader name (dlopen.a): lt_preopen (success)
loader name (loadlibrary.a): lt_dlopen (failure)
loader name (loadlibrary.a): lt_preopen (success)
loader name (libsub.a): lt_preopen (failure)
loader name (libsub.a): lt_loadlibrary (failure)
loader name
(/usr/src/libtool/cvs/libtool-HEAD/_build/tests/mdemo/.libs/cygsub-0.dll):
lt_preopen (failure)
loader name
(/usr/src/libtool/cvs/libtool-HEAD/_build/tests/mdemo/.libs/cygsub-0.dll):
lt_loadlibrary (success)
loader name (foo1.a): lt_preopen (failure)
loader name (foo1.a): lt_loadlibrary (failure)
loader name (./.libs/foo1.dll): lt_preopen (failure)
loader name (./.libs/foo1.dll): lt_loadlibrary (success)
module name: foo1
module filename: ./.libs/foo1.dll
module reference count: 1
** This is foolib 1 **
hello returned: 57616
hello is ok!
cos (0.0) = 1
sub() called
foo1 is ok!
loader name (libsub.a): lt_preopen (failure)
loader name (libsub.a): lt_loadlibrary (failure)
loader name
(/usr/src/libtool/cvs/libtool-HEAD/_build/tests/mdemo/.libs/cygsub-0.dll):
lt_preopen (failure)
loader name
(/usr/src/libtool/cvs/libtool-HEAD/_build/tests/mdemo/.libs/cygsub-0.dll):
lt_loadlibrary (success)
loader name (libfoo2.a): lt_preopen (failure)
loader name (libfoo2.a): lt_loadlibrary (failure)
loader name (./.libs/cygfoo2-0.dll): lt_preopen (failure)
loader name (./.libs/cygfoo2-0.dll): lt_loadlibrary (success)
module name: libfoo2
module filename: ./.libs/cygfoo2-0.dll
module reference count: 1
** This is foolib 2 **
hello returned: 57616
hello is ok!
sin (0.0) = 0
sub() called
foo2 is ok!
loader name ((null)): lt_preopen (success)
myfunc returned: 57616
myfunc is ok!
--
Chuck
Index: ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.236
diff -u -r1.236 ltdl.c
--- ltdl.c 26 Oct 2005 10:26:48 - 1.236
+++ ltdl.c 14 Nov 2005 05:19:35 -
@@ -367,13 +367,16 @@
while ((loader = lt_dlloader_next (loader)))
{
vtable = lt_dlloader_get (loader);
+fprintf(stderr, loader name (%s): %s (, filename, vtable-name);
handle-module = (*vtable-module_open) (vtable-dlloader_data,
filename);
if (handle-module != 0)
{
+fprintf(stderr, success)\n);
break;
}
+fprintf(stderr, failure)\n);
}
if (!loader)
