Re: [patch 09/19] 293-gary-default-convenience-ltdl.diff Queue
* Ralf Wildenhues wrote on Fri, Oct 28, 2005 at 10:52:22PM CEST: * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:33PM CEST: Index: libtool--devo--1.0/ChangeLog from Gary V. Vaughan [EMAIL PROTECTED] * libltdl/m4/ltdl.m4 (LTDL_INIT): Call _LT_ENABLE_INSTALL directly instead of m4_requiring it, as it relies on enable_ltdl_install and enable_ltdl_convenience to have been initialised first. This patch is ok. Mind this typo, though: | +dnl Don't require this, or it will be expanded earlier that the code s/that/than | +dnl that sets the variables it relies on: | +_LT_ENABLE_INSTALL Thanks, Ralf
Re: [patch 06/19] 289-gary-LT_WITH_LTDL-nonrecursive.diff Queue
Hi Gary,
* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 12:26:30PM CEST:
configure.ac |1
libltdl/m4/ltdl.m4 | 65
+
2 files changed, 47 insertions(+), 19 deletions(-)
Index: libtool--devo--1.0/ChangeLog
from Gary V. Vaughan [EMAIL PROTECTED]
* libltdl/m4/ltdl.m4 (LT_CONFIG_LTDL_DIR): Add LTDL-MODE
argument.
* configure.ac: Use it.
OK after addressing nits below. Thank you!
Cheers,
Ralf
Index: libtool--devo--1.0/configure.ac
===
--- libtool--devo--1.0.orig/configure.ac
+++ libtool--devo--1.0/configure.ac
@@ -27,6 +27,7 @@ dnl Oldest automake required for bootstr
AC_INIT([libtool], [2.1a], [EMAIL PROTECTED])
AC_CONFIG_HEADERS([config.h:config-h.in])
AC_CONFIG_SRCDIR([libtoolize.in])
+LT_CONFIG_LTDL_DIR([libltdl], [nonrecursive])
AC_CONFIG_AUX_DIR([libltdl/config])
AC_CONFIG_MACRO_DIR([libltdl/m4])
AC_CONFIG_LIBOBJ_DIR([libltdl])
Index: libtool--devo--1.0/libltdl/m4/ltdl.m4
===
--- libtool--devo--1.0.orig/libltdl/m4/ltdl.m4
+++ libtool--devo--1.0/libltdl/m4/ltdl.m4
@@ -7,8 +7,8 @@
# serial 9 LTDL_INIT
-# LT_CONFIG_LTDL_DIR(DIRECTORY)
-# -
+# LT_CONFIG_LTDL_DIR(DIRECTORY, [LTDL-MODE])
+# --
# DIRECTORY contains the libltdl sources. It is okay to call this
# function multiple times, as long as the same DIRECTORY is always given.
AC_DEFUN([LT_CONFIG_LTDL_DIR],
@@ -31,10 +31,16 @@ m4_case(_LTDL_DIR,
[],
[m4_fatal([multiple libltdl directories: `]_LTDL_DIR[',
`]_ARG_DIR['])])])
m4_popdef([_ARG_DIR])
-])
+dnl If not otherwise defined, default to the 1.5.x compatible subproject
mode:
+m4_if(_LTDL_MODE, [],
+ [m4_define([_LTDL_MODE], m4_default([$2], [subproject]))
+ m4_if([-1], [m4_bregexp(_LTDL_MODE, [\(subproject\|nonrecursive\)])],
+ [AC_MSG_ERROR([unknown libltdl mode: ]_LTDL_MODE)])])
Make this an m4_fatal instead of AC_MSG_ERROR, no need to defer the
error until configure time.
+])# LT_CONFIG_LTDL_DIR
# Initialise:
m4_define([_LTDL_DIR], [])
+m4_define([_LTDL_MODE], [])
# LTDL_CONVENIENCE
@@ -138,6 +144,23 @@ dnl aclocal-1.4 backwards compatibility:
dnl AC_DEFUN([AC_LIBLTDL_INSTALLABLE], [])
+# _LTDL_MODE_DISPATCH
+# ---
+m4_define([_LTDL_MODE_DISPATCH],
+[dnl If _LTDL_DIR is `.', then we are configuring libltdl itself:
+m4_if(_LTDL_DIR, [],
+ [],
+dnl if _LTDL_MODE was not set already, the default value is `subproject':
+[m4_case(m4_default(_LTDL_MODE, [subproject]),
+ [subproject], [AC_CONFIG_SUBDIRS(_LTDL_DIR)
+ _LT_SHELL_INIT([lt_dlopen_dir=$lt_ltdl_dir])],
+ [nonrecursive], [_LT_SHELL_INIT([lt_dlopen_dir=$lt_ltdl_dir])],
+ [AC_MSG_ERROR([unknown libltdl mode: ]_LTDL_MODE)])])dnl
Ditto.
+dnl Be careful not to expand twice:
+m4_define([$0], [])
+])# _LTDL_MODE_DISPATCH
+
+
# LT_WITH_LTDL([LTDL-MODE])
# -
# Clients of libltdl can use this macro to allow the installer to
@@ -195,13 +218,14 @@ fi
AC_MSG_CHECKING([whether to use included libltdl])
AC_MSG_RESULT([$with_included_ltdl])
-AC_CONFIG_SUBDIRS(_LTDL_DIR)
-
-dnl Be certain that LTDL_INIT is invoked:
-AC_PROVIDE_IFELSE([LTDL_INIT],
- [],
-[LTDL_INIT
-AC_DEFUN([LTDL_INIT], [])])
+dnl Be certain that LTDL_INIT is invoked if we are configuring libltdl
+dnl from here:
+m4_if(_LTDL_MODE, [subproject],
+ [_LTDL_MODE_DISPATCH],
+[AC_PROVIDE_IFELSE([LTDL_INIT],
+ [],
+ [LTDL_INIT
+ AC_DEFUN([LTDL_INIT], [])])])
])# LT_WITH_LTDL
# Old name:
@@ -245,6 +269,9 @@ m4_provide_if([_LT_CONFIG_LTDL_DIR],
[m4_ifval([$1], [_LT_CONFIG_LTDL_DIR([$1])])],
[_LT_CONFIG_LTDL_DIR(m4_default([$1], [libltdl]))])dnl
+dnl _LTDL_MODE specific code must be evaluated at least once:
+_LTDL_MODE_DISPATCH
+
# In order that ltdl.c can compile, run AC_CONFIG_HEADERS for the user
# if they did not call it themself. This is so that ltdl.h can pick up
# the parent projects config.h file, The first file in AC_CONFIG_HEADERS
@@ -481,7 +508,7 @@ AC_CHECK_LIB([dl], [dlopen],
[AC_DEFINE([HAVE_LIBDL], [1],
[Define if you have the libdl library or equivalent.])
LIBADD_DLOPEN=-ldl libltdl_cv_lib_dl_dlopen=yes
- LT_DLLOADERS=$LT_DLLOADERS ${lt_ltdl_dir+$lt_ltdl_dir/}dlopen.la],
+ LT_DLLOADERS=$LT_DLLOADERS ${lt_dlopen_dir+$lt_dlopen_dir/}dlopen.la],
[AC_LINK_IFELSE([AC_LANG_PROGRAM([[#if HAVE_DLFCN_H
# include dlfcn.h
#endif
@@ -489,12 +516,12 @@ AC_CHECK_LIB([dl], [dlopen],
[AC_DEFINE([HAVE_LIBDL], [1],
[Define if you have the libdl library or equivalent.])
libltdl_cv_func_dlopen=yes
-
Several patches for SCO platform support and other bugfixes
All, After this mail, I will be sending 10 discrete patches for various bug fixes, small improvements and updating the SCO platform support. These patches are all against the 1.5 branch. I figure we'll iron out any isses with these and then I'll post the ones against HEAD, which are all almost identical (modulo the various infrastructural changes between 1.5 and HEAD). These were all split out into smaller patches from a single cvs diff. Thus, the line numbers for various thunks may be off if you try to apply them in solutation, as the line numbers may have changed based on preceeding patches. Each patch has a ChangeLog entry and a rationale. I did try to subscribe to the patches mailing list but I dont know how the list is set up. I havent received confirmation email, or subscription may be moderated, so if you have any comments, please include me directory on the To: line. Many thanks go to Tim Rice for all his help with testing and fine-tuning these patches with me. PS. I am copyright-assignment friendly. I've had an assignment on file with the FSF for about 8 years now. Kean
SCO/bugfix patch 1 of 10: AC_LIBTOOL_SYS_MAX_CMD_LEN
Patch 1 of 10 attached ... Rationale: OpenServer ships by default with a command line length of 100K, but the kernel tunable files are not world-readable, so we cannot detect the dynamic value. So, for OSR5, set the value to 100K. If we don't, every time libtool is invoked, we get a kernel warning telling us that the max command line length table was exceded, and the auto-detect mechanism gets a pessimistically low value (it stops at 32K). On UnixWare and OpenServer 6, the kernel tunable file *is* world readable so we check the real value. If it wasnt tuned by the user the default is a lowly 32K. 2005-10-24 Kean Johnston [EMAIL PROTECTED] * libtool.m4(AC_LIBTOOL_SYS_MAX_CMD_LEN): Set correctly for SCO. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.115 diff -u -3 -p -r1.314.2.115 libtool.m4 --- libtool.m4 9 Oct 2005 06:26:21 - 1.314.2.115 +++ libtool.m4 30 Oct 2005 21:22:24 - @@ -738,6 +738,17 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [d esac fi ;; + sco3.2v5*) +lt_cv_sys_max_cmd_len=102400 +;; + sysv5* | sco5v6*) +kargmax=`grep ARG_MAX /etc/conf/cf.d/stune` +if test -n $kargmax; then + lt_cv_sys_max_cmd_len=`echo $kargmax|sed -e 's/.*[[ ]][[]]*//'` +else + lt_cv_sys_max_cmd_len=32768 +fi +;; *) # If test is not a shell built-in, we'll probably end up computing a # maximum length that is only half of the actual maximum length, but
SCO/bugfix patch 3 of 10: AC_LIBTOOL_DLOPEN_SELF
Patch 3 of 10 attached ... Rationale: The test for being able to dlopen yourself is flawed. It was using $link_static_flag, which is only present in the generated libtool. During autoconfiscation, the variable is called $lt_prog_compiler_static. This was causing false positives becuase -Bstatic/-static were not being passed through to the link editor, and thus we were actually testing a dynamic a.out. Since $lt_prog_compiler_static most likely uses $wl, ensure that wl is set to $lt_prog_compiler_wl before running the test, so that $lt_prog_compiler_static expands correctly. 2005-10-24 Kean Johnston [EMAIL PROTECTED] * libtool.m4(AC_LIBTOOL_DLOPEN_SELF): Set wl if its not already set so expansion of export_dynamic_flag_spec works. Use lt_prog_compile_static, not link_static_flag. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.115 diff -u -3 -p -r1.314.2.115 libtool.m4 --- libtool.m4 9 Oct 2005 06:26:21 - 1.314.2.115 +++ libtool.m4 30 Oct 2005 21:22:24 - @@ -932,6 +943,7 @@ else case $lt_cv_dlopen in dlopen) +test -z $wl wl=$lt_prog_compiler_wl save_CPPFLAGS=$CPPFLAGS test x$ac_cv_header_dlfcn_h = xyes CPPFLAGS=$CPPFLAGS -DHAVE_DLFCN_H @@ -949,7 +961,7 @@ else ]) if test x$lt_cv_dlopen_self = xyes; then - LDFLAGS=$LDFLAGS $link_static_flag + LDFLAGS=$LDFLAGS $lt_prog_compiler_static AC_CACHE_CHECK([whether a statically linked program can dlopen itself], lt_cv_dlopen_self_static, [dnl _LT_AC_TRY_DLOPEN_SELF(
SCO/bugfix patch 4 of 10: ltmain.in rpath variable
Patch 4 of 10 attached ... Rationale: On SCO platforms it is very important to be able to create shared libaries with absolute SONAME entries, and to have executables that use those hard-coded names and not rely on DT_RUNPATH. The problem is that only relatively recent versions of the OS had protection in the RTLD against using LD_LIBRARY_PATH with elevated priveliges. Being able to divert a library in a program with elevated priveliges is a huge security risk. So the SCO patch (see next mail) provides the facility to set absolute path names in shared libraries if the environment variable `SCOABSPATH' is non-empty. In order for this to work, libtool needs to know what the installation path of the shared library is going to be. This is the value of -rpath. The problem with the current mechanism is that -rpath accumulates args, and adds spaces. I don't know if specifying multiple -rpath's has meaning to any platform, so to be on the safe side, rather than making rpath be a non-accumulating variable, I introduce a new variable called 'instrpath' that is set to whatever the last -rpath argument was. This is generically useful in case other platforms want to pick up the ability to create shared libraries with absolute paths. There are other good reasons why doing that is a good idea, but it is mostly only applicable on platforms that dont have a suitably smart RTLD to deal with elevated priveliges. However, even on platforms that are suitably protected, absolute paths can still be a good idea. I can wax lyrical about why if required. As it stands, this patch affects no-one except SCO platforms. 2005-10-24 Kean Johnston [EMAIL PROTECTED] * ltmain.in: Set a non-accumulating installation rpath variable to facilitate setting absolute paths in shared libraries. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.91 diff -u -3 -p -r1.334.2.91 ltmain.in --- ltmain.in 18 Oct 2005 07:26:05 - 1.334.2.91 +++ ltmain.in 30 Oct 2005 21:22:25 - @@ -1314,7 +1314,8 @@ EOF if test $prev = rpath; then case $rpath in * $arg *) ;; - *) rpath=$rpath $arg ;; + *) instrpath=$arg + rpath=$rpath $arg ;; esac else case $xrpath in
SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
Patch 5 of 10 attached ... Rationale: On some releases of OpenServer 5, libc was poorly constructed and had static versions of __ctype. Due to a bug with copy relocations, linking a shared library with -lc would result in a shared library having one notion of __ctype, and the a.out having another. Thus, things like atoi() would behave differently inside the shared library versus the a.out. This is really bad. Also, there is no need to link in -lc, as it is always loaded by definition, as that is the RTLD and you cant have any form of dynamic ELF program without it. On OpenServer 6 and UnixWare, explicitly linking with -lc is even worse. The threads library is constructed in such a way that it provides several of the same functions that appear in libc. The version for libthread.so are the real, threads-safe versions. The versions that are in libc are stub versions that are present to allow programs to link, while still using simpler versions of things like mutexes and condition variables. In order for threads to work correctly, libc *must* be the very last library in the load order, so that those symbols that need it are resolved out of the threads library. If you explicitly link with -lc when creating a shared library, then libc is processed as a dependency when the shared library is loaded, and appears too early in the dependency chain. 2005-10-24 Kean Johnston [EMAIL PROTECTED] * ltmain.in(*-*-sco3.2v5*): Dont pass through -lc. (*-*-sysv5*): Ditto. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.91 diff -u -3 -p -r1.334.2.91 ltmain.in --- ltmain.in 18 Oct 2005 07:26:05 - 1.334.2.91 +++ ltmain.in 30 Oct 2005 21:22:25 - @@ -1494,6 +1495,15 @@ EOF # Rhapsody C and math libraries are in the System framework deplibs=$deplibs -framework System continue + ;; + *-*-sco3.2v5*) + # Causes problems with __ctype + test X$arg = X-lc continue + ;; + *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*) + # Compiler inserts libc in the correct place for threads to work + test X$arg = X-lc continue + ;; esac elif test X$arg = X-lc_r; then case $host in
SCO/buffix patch 6 of 10: AC_PROG_NM fixes
Patch 6 of 10 attached ...
Rationale:
The test for a suitable nm was too restrictive. First, it would only check
for nm with $ac_tool_prefix. But only the GNU version of nm installs itself
that way. This was thwarting finding a non-binutils nm on the path.
Second, added /usr/ccs/bin/elf to the list of paths to search, before
/usr/ccs/bin. On OpenServer, this makes sure we pick up the ELF version,
as it is a multi-ABI world, and /usr/ccs/bin/nm is a COFF/ELF schizophrenic
version that accepts slightly different arguments. This wont affect any
other systems becuase AFAIK only OSR5 has a /usr/ccs/bin/elf, and any
other system that may conceivably have it is likely to want the ELF version
of nm anyway.
Third, dont do the 'sed 1q' stuff, but grep the output returned. The
'sed 1q' was causing false negatives if there was only a single line of
output. By using grep on the entire output, we will still get the correct
result, even on HP-UX if it first ejects a warning message about unknown
options.
2005-10-24 Kean Johnston [EMAIL PROTECTED]
* libtool.m4(AC_PROG_NM): Add /usr/ccs/bin/elf to search path list.
Look for tool both with and without ac_tool_prefix. Use grep on output
results and dont delete first line of output in case output is
only one line long.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.115
diff -u -3 -p -r1.314.2.115 libtool.m4
--- libtool.m4 9 Oct 2005 06:26:21 - 1.314.2.115
+++ libtool.m4 30 Oct 2005 21:22:24 -
@@ -2375,33 +2386,37 @@ AC_DEFUN([AC_PROG_NM],
lt_cv_path_NM=$NM
else
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
-if test -f $tmp_nm || test -f $tmp_nm$ac_exeext ; then
+tmp_nm_file=$ac_dir/${ac_tool_prefix}nm
+if test -f $tmp_nm_file || test -f $tmp_nm_file$ac_exeext ; then
+ tmp_nm=$tmp_nm_file
+else
+ tmp_nm_file=$ac_dir/nm
+ if test -f $tmp_nm_file || test -f $tmp_nm_file$ac_exeext ; then
+tmp_nm=$tmp_nm_file
+ fi
+fi
+if test -n $tmp_nm ; then
# Check to see if the nm accepts a BSD-compat flag.
- # Adding the `sed 1q' prevents false positives on HP-UX, which says:
- # nm: unknown option B ignored
# Tru64's nm complains that /dev/null is an invalid object file
- case `$tmp_nm -B /dev/null 21 | sed '1q'` in
- */dev/null* | *'Invalid file or object type'*)
- lt_cv_path_NM=$tmp_nm -B
+ tmp_nm_out=`$tmp_nm -B /dev/null 21`
+ echo $tmp_nm_out | $EGREP '.*/dev/null.*|.*Invalid file or object
type.*' /dev/null 21
+ if test $? -eq 0; then
+lt_cv_path_NM=$tmp_nm -B
break
-;;
- *)
- case `$tmp_nm -p /dev/null 21 | sed '1q'` in
- */dev/null*)
+ else
+tmp_nm_out=`$tmp_nm -p /dev/null 21`
+echo $tmp_nm_out | $EGREP '.*/dev/null.*' /dev/null 21
+ if test $? -eq 0; then
lt_cv_path_NM=$tmp_nm -p
break
- ;;
- *)
+ else
lt_cv_path_NM=${lt_cv_path_NM=$tmp_nm} # keep the first match, but
continue # so that we can try to find one that supports BSD flags
- ;;
- esac
-;;
- esac
+ fi
+ fi
fi
done
IFS=$lt_save_ifs
SCO/bugfix patch 7 of 10: Improve SCO platform support
Patch 7 of 10 attached ...
Rationale:
I like it when things work on my platform :)
2005-10-24 Kean Johnston [EMAIL PROTECTED]
* libtool.m4: Complete overhaul of SCO support.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.115
diff -u -3 -p -r1.314.2.115 libtool.m4
--- libtool.m4 9 Oct 2005 06:26:21 - 1.314.2.115
+++ libtool.m4 30 Oct 2005 21:22:24 -
@@ -1623,13 +1635,6 @@ osf3* | osf4* | osf5*)
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
@@ -1655,7 +1660,7 @@ sunos4*)
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'
@@ -1688,17 +1693,27 @@ sysv4*MP*)
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 $with_gnu_ld = yes; then
+shlibpath_overrides_runpath=no
+sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib
/usr/lib /lib'
+ else
+shlibpath_overrides_runpath=yes
+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'
;;
uts4*)
@@ -2319,15 +2334,11 @@ osf3* | osf4* | osf5*)
lt_cv_deplibs_check_method=pass_all
;;
-sco3.2v5*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
solaris*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv4 | sysv4.2uw2* | sysv4.3*)
+sysv4 | sysv4.3*)
case $host_vendor in
motorola)
lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB
(shared object|dynamic lib) M[[0-9]][[0-9]]* Version [[0-9]]'
@@ -2354,7 +2365,7 @@ sysv4 | sysv4.2uw2* | sysv4.3*)
esac
;;
-unixware7* | sysv5*)
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
lt_cv_deplibs_check_method=pass_all
;;
esac
@@ -2600,13 +2615,6 @@ _LT_LINKER_BOILERPLATE
# Check for any special shared library compilation flags.
#
_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)=
-if test $GCC = no; then
- case $host_os in
- sco3.2v5*)
-_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)='-belf'
-;;
- esac
-fi
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 :
@@ -3477,19 +3485,6 @@ case $host_os in
# FIXME: insert proper C++ library support
_LT_AC_TAGVAR(ld_shlibs, $1)=no
;;
- sco*)
-_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
-case $cc_basename in
- CC*)
- # FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
- ;;
- *)
- # FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
- ;;
-esac
-;;
sunos4*)
case $cc_basename in
CC*)
@@ -3582,27 +3577,48 @@ case $host_os in
;;
esac
;;
- sysv5OpenUNIX8* | sysv5UnixWare7.[[01]].[[01]]* | sysv5uw[[78]]* |
unixware7*)
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* |
sco3.2v5.0.[024]*)
+_LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+runpath_var='LD_RUN_PATH'
+
case $cc_basename in
CC*)
- _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z ${wl}text'
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h ${wl}$soname -o $lib
$libobjs $deplibs $compiler_flags'
- _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
- runpath_var='LD_RUN_PATH'
- _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o
SCO/bugfix patch 8 of 10: ltmain.in -L handling for SCO platforms
Patch 8 of 10 attached ... Rationale: Handle older SCO systems correctly. 2005-10-24 Kean Johnston [EMAIL PROTECTED] * ltmain.in: Update SCO system support. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.91 diff -u -3 -p -r1.334.2.91 ltmain.in --- ltmain.in 18 Oct 2005 07:26:05 - 1.334.2.91 +++ ltmain.in 30 Oct 2005 21:22:25 - @@ -2559,7 +2569,11 @@ EOF if test $hardcode_direct = no; then add=$dir/$linklib case $host in - *-*-sco3.2v5* ) add_dir=-L$dir ;; + *-*-sco3.2v5.0.[024]*) add_dir=-L$dir ;; + *-*-sysv4*uw2*) add_dir=-L$dir ;; + *-*-sysv5OpenUNIX* | \ + *-*-sysv5UnixWare7.[01].[10]* | \ + *-*-unixware7*) add_dir=-L$dir ;; *-*-darwin* ) # if the lib is a module then we can not link against # it, someone is ignoring the new warnings I added
SCO/bugfix patch 9 of 10: AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE
Patch 9 of 10 attached ... Rationale: The valid symbol tags were incorrect for SCO platforms. Correct them. 2005-10-24 Kean Johnston [EMAIL PROTECTED] * libtool.m4(AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE): Set correct symcode values for the native nm on SCO platforms. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.115 diff -u -3 -p -r1.314.2.115 libtool.m4 --- libtool.m4 9 Oct 2005 06:26:21 - 1.314.2.115 +++ libtool.m4 30 Oct 2005 21:22:24 - @@ -4589,9 +4605,18 @@ irix* | nonstopux*) osf*) symcode='[[BCDEGQRST]]' ;; -solaris* | sysv5*) +solaris*) symcode='[[BDRT]]' ;; +sco3.2v5*) + symcode='[[DT]]' + ;; +sysv4.2uw2*) + symcode='[[DT]]' + ;; +sysv5* | sco5v6* | unixware* | OpenUNIX*) + symcode='[[ABDT]]' + ;; sysv4) symcode='[[DFNSTU]]' ;;
SCO/bugfix patch 10 of 10: --version-info improvement
Patch 10 of 10 attached ...
Rationale:
I expect a lot of resistance to this patch :) Let me just start of by
saying that I already know most of the objections why you dont want to
explicitly name a shared library. However, it is a very useful option
and I hope to explain why.
I have encountered at least two applications so far that do a realpath()
on a shared library, and then check the SONAME to ensure that they match
a compile-time constant. I know, the applications are retarded. But
libtool is a program that is supposed to make creating shared libraries
easier, and having the ability to actually have control over things like
the SONAME make it more generically useful, and caters for situations
that we may not have forseen. The current scheme uses soname_spec as the
sole mechanism for setting the SONAME for a shared library. This is
a calculated name based on the current library version. However, as
a programmer, I may know that even though shared library version Y
has some incompatible interfaces relative to version X, that those
chages are a pure superset of X. Thus, I want the new version Y to
also be available to old programs that linked against version X. The way
you would *want* to do this is with a simple symlink during packaging.
99.999% of the time, that will suffice. Only really stupid applications
that do crap like realpath() and checking the SONAME will fail. Its a tiny
corner case, but this patch provides a mechanism for covering it. I can't
really see a downside to this, to be honest.
2005-10-24 Kean Johnston [EMAIL PROTECTED]
* ltmain.in: Provide a mechanism for explicitly setting the value
of SONAME in a shared library using an optional 4th argument to
--version-info.
* doc/libtool.texi: Document it.
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.91
diff -u -3 -p -r1.334.2.91 ltmain.in
--- ltmain.in 18 Oct 2005 07:26:05 - 1.334.2.91
+++ ltmain.in 30 Oct 2005 21:22:25 -
@@ -3067,10 +3081,16 @@ EOF
set dummy $vinfo 0 0 0
IFS=$save_ifs
- if test -n $8; then
+ if test -n $9; then
$echo $modename: too many parameters to \`-version-info' 12
$echo $help 12
exit $EXIT_FAILURE
+ fi
+
+ if test -n $8; then
+ override_soname=$5
+ soname_spec=$override_soname
+ library_names_spec=$override_soname $library_names_spec
fi
# convert absolute version numbers to libtool ages
Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.134.2.13
diff -u -3 -p -r1.134.2.13 libtool.texi
--- doc/libtool.texi29 Aug 2005 11:11:41 - 1.134.2.13
+++ doc/libtool.texi30 Oct 2005 21:22:25 -
@@ -1318,11 +1318,13 @@ If @var{output-file} is a program, then
uninstalled shared libtool libraries. If @var{output-file} is a
library, then only create a static library.
[EMAIL PROTECTED] -version-info @var{current}[:@var{revision}[:@var{age}]]
[EMAIL PROTECTED] -version-info
@var{current}[:@var{revision}[:@var{age}[:@var{override}]]]
If @var{output-file} is a libtool library, use interface version
information @var{current}, @var{revision}, and @var{age} to build it
(@pxref{Versioning}). Do @strong{not} use this flag to specify package
-release information, rather see the @samp{-release} flag.
+release information, rather see the @samp{-release} flag. For those
+very rare cases where you absolutely @emph{must} provide an explict
+library name, you can specify an @var{override} name.
@item -version-number @var{major}[:@var{minor}[:@var{revision}]]
If @var{output-file} is a libtool library, compute interface version
Re: SCO/bugfix patch 1 of 10: AC_LIBTOOL_SYS_MAX_CMD_LEN
On Sun, 30 Oct 2005, Kean Johnston wrote: Patch 1 of 10 attached ... Minor nit. + sysv5* | sco5v6*) +kargmax=`grep ARG_MAX /etc/conf/cf.d/stune` This works for UnixWare 2.x too. Should be + sysv5* | sco5v6* | sysv4.2uw2*) -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
On Sun, 30 Oct 2005, Kean Johnston wrote:
Patch 7 of 10 attached ...
Rationale:
I like it when things work on my platform :)
2005-10-24 Kean Johnston [EMAIL PROTECTED]
* libtool.m4: Complete overhaul of SCO support.
I'm attaching a corrected patch.
.
case $host_os in
+ sco3.2v5*)
- *-*-sco3.2v5*)
sys_lib_search_path_spec=$sys_lib_search_path_spec /lib
;;
esac
Missing some square brackets.
- sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* |
sco3.2v5.0.[024]*)
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* |
sco3.2v5.0.[[024]]*)
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- libtool.m4.old 2005-10-15 13:12:08.0 -0700
+++ libtool.m4 2005-10-30 18:30:34.371040302 -0800
@@ -1623,13 +1635,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
@@ -1655,7 +1660,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'
@@ -1688,17 +1693,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 $with_gnu_ld = yes; then
+shlibpath_overrides_runpath=no
+sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib
/usr/lib /lib'
+ else
+shlibpath_overrides_runpath=yes
+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'
;;
uts4*)
@@ -2319,15 +2334,11 @@
lt_cv_deplibs_check_method=pass_all
;;
-sco3.2v5*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
solaris*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv4 | sysv4.2uw2* | sysv4.3*)
+sysv4 | sysv4.3*)
case $host_vendor in
motorola)
lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB
(shared object|dynamic lib) M[[0-9]][[0-9]]* Version [[0-9]]'
@@ -2354,7 +2365,7 @@
esac
;;
-unixware7* | sysv5*)
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
lt_cv_deplibs_check_method=pass_all
;;
esac
@@ -2600,13 +2615,6 @@
# Check for any special shared library compilation flags.
#
_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)=
-if test $GCC = no; then
- case $host_os in
- sco3.2v5*)
-_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)='-belf'
-;;
- esac
-fi
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 :
@@ -3477,19 +3485,6 @@
# FIXME: insert proper C++ library support
_LT_AC_TAGVAR(ld_shlibs, $1)=no
;;
- sco*)
-_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
-case $cc_basename in
- CC*)
- # FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
- ;;
- *)
- # FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
- ;;
-esac
-;;
sunos4*)
case $cc_basename in
CC*)
@@ -3582,27 +3577,48 @@
;;
esac
;;
- sysv5OpenUNIX8* | sysv5UnixWare7.[[01]].[[01]]* | sysv5uw[[78]]* |
unixware7*)
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* |
sco3.2v5.0.[[024]]*)
+_LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+runpath_var='LD_RUN_PATH'
+
case $cc_basename in
CC*)
- _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z ${wl}text'
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h ${wl}$soname -o $lib
$libobjs $deplibs
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
Tim Rice wrote: On Sun, 30 Oct 2005, Kean Johnston wrote: Patch 7 of 10 attached ... Rationale: I like it when things work on my platform :) 2005-10-24 Kean Johnston [EMAIL PROTECTED] * libtool.m4: Complete overhaul of SCO support. I'm attaching a corrected patch. . case $host_os in + sco3.2v5*) - *-*-sco3.2v5*) sys_lib_search_path_spec=$sys_lib_search_path_spec /lib ;; esac Ooops sorry Tim. You told me about that one and I dropped the ball. Sorry :(
Re: SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
Kean Johnston wrote: Patch 5 of 10 attached ... Tim caught a small ommission. A corrected patch is attached. Rationale: On some releases of OpenServer 5, libc was poorly constructed and had static versions of __ctype. Due to a bug with copy relocations, linking a shared library with -lc would result in a shared library having one notion of __ctype, and the a.out having another. Thus, things like atoi() would behave differently inside the shared library versus the a.out. This is really bad. Also, there is no need to link in -lc, as it is always loaded by definition, as that is the RTLD and you cant have any form of dynamic ELF program without it. On OpenServer 6 and UnixWare, explicitly linking with -lc is even worse. The threads library is constructed in such a way that it provides several of the same functions that appear in libc. The version for libthread.so are the real, threads-safe versions. The versions that are in libc are stub versions that are present to allow programs to link, while still using simpler versions of things like mutexes and condition variables. In order for threads to work correctly, libc *must* be the very last library in the load order, so that those symbols that need it are resolved out of the threads library. If you explicitly link with -lc when creating a shared library, then libc is processed as a dependency when the shared library is loaded, and appears too early in the dependency chain. 2005-10-24 Kean Johnston [EMAIL PROTECTED] * ltmain.in(*-*-sco3.2v5*): Dont pass through -lc. (*-*-sysv5*): Ditto. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.91 diff -u -3 -p -r1.334.2.91 ltmain.in --- ltmain.in 18 Oct 2005 07:26:05 - 1.334.2.91 +++ ltmain.in 30 Oct 2005 21:22:25 - @@ -1494,6 +1495,15 @@ EOF # Rhapsody C and math libraries are in the System framework deplibs=$deplibs -framework System continue + ;; + *-*-sco3.2v5* | *-*-sco5v6*) + # Causes problems with __ctype + test X$arg = X-lc continue + ;; + *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*) + # Compiler inserts libc in the correct place for threads to work + test X$arg = X-lc continue + ;; esac elif test X$arg = X-lc_r; then case $host in
Remove duplicate settion of archive_expsym_cmds=yes on AIX
always_export_symbols is set before the if statement enclosing the
code below so remove duplicates.
Patch against branch-1-5.
2005-10-30 Albert Chin-A-Young [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG,
AC_LIBTOOL_PROG_LD_SHLIBS): Remove duplicate
always_export_symbols=yes for AIX.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.115
diff -u -3 -p -r1.314.2.115 libtool.m4
--- libtool.m4 9 Oct 2005 06:26:21 - 1.314.2.115
+++ libtool.m4 31 Oct 2005 06:13:28 -
@@ -2930,8 +2930,6 @@ case $host_os in
# -berok will link without error, but may produce a broken library.
_LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_AC_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
@@ -5626,8 +5624,6 @@ EOF
# -berok will link without error, but may produce a broken library.
_LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_AC_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
Re: tagdemo test / -c -o
On Sun, 30 Oct 2005, Ralf Wildenhues wrote: Hi Tim, * Tim Rice wrote on Sun, Oct 30, 2005 at 02:34:18AM CET: On Sun, 30 Oct 2005, Ralf Wildenhues wrote: I guess you should be able to use this manually-written rule as a workaround: .cpp.$(OBJEXT): $(CXXCOMPILE) -c $ Or this patch to automake .. --- automake-1.9.6/automake.in.old 2005-06-30 14:17:13.0 -0700 +++ automake-1.9.6/automake.in 2005-10-29 18:31:51.565961323 -0700 @@ -691,7 +691,6 @@ 'compile' = '$(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)', 'compiler' = 'CXXCOMPILE', 'compile_flag' = '-c', - 'output_flag' = '-o', 'libtool_tag' = 'CXX', 'lder' = 'CXXLD', 'ld' = '$(CXX)', No. :) Above workaround works only because - we do not use subdir-objects; in fact, we do not use subdirs at all, - none of the non-libtool objects (i.e., the `.o' ones) use per-target flags It seems strange that automake's COMPILE section has no 'output_flag' = '-o', but the CXXCOMPILE does. It's really just appropriate for the tagdemo case, not for Automake in general. Cheers, Ralf -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: tagdemo test / -c -o
Hi Tim, * Tim Rice wrote on Sun, Oct 30, 2005 at 11:19:30AM CET: On Sun, 30 Oct 2005, Ralf Wildenhues wrote: * Tim Rice wrote on Sun, Oct 30, 2005 at 02:34:18AM CET: --- automake-1.9.6/automake.in.old2005-06-30 14:17:13.0 -0700 +++ automake-1.9.6/automake.in2005-10-29 18:31:51.565961323 -0700 @@ -691,7 +691,6 @@ 'compile' = '$(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)', 'compiler' = 'CXXCOMPILE', 'compile_flag' = '-c', -'output_flag' = '-o', 'libtool_tag' = 'CXX', 'lder' = 'CXXLD', 'ld' = '$(CXX)', No. :) Above workaround works only because - we do not use subdir-objects; in fact, we do not use subdirs at all, - none of the non-libtool objects (i.e., the `.o' ones) use per-target flags It seems strange that automake's COMPILE section has no 'output_flag' = '-o', but the CXXCOMPILE does. Well, Automake currently has its `compile' machinery hard-wired for C. Look where output_flag gets used, they specifically check the language for C. Also, look at automake/m4/minuso.m4 to find out that it needs adjusting for non-C as well. The `compile' script needs adjustment, too, should a solution for it use this as well. I'm not saying it can't be done; all I'm saying is it's a bit more work to solve this than above patch. Also please note that you might break things in users' configure.ac in that they might not expect $CXX to end up containing `path/to/compile $CXX'. (Most people don't expect it for C code either, though.) This really is an Automake question. If you are brave to work on this, you should send your patches to [EMAIL PROTECTED] :) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -dlopen self on AIX
On Sun, 30 Oct 2005, Albert Chin wrote: Seems the openldap folks should really use -export-dynamic, which isn't defined for AIX. We could make it -bexpall but as documented in the previous mail, it doesn't export everything. So, should we create a new variable, export_dynamic_cmds? If so, and temporary files are created by it, how do we clean up? A better approach for openldap is to have the daemon and its modules depend on a common shared library. As far as I am aware, this works ok under AIX and other systems. Designing modules so that they depend on symbols from the executable which loads them is just asking for trouble. 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: large messages
Ralf Wildenhues wrote: However, I guess some readers of this list might be annoyed by large messages as yours. First, please take my apology: we have moderation turned on for messages 100KB, still I just allowed it through while my mind was somewhere else. Second, Christian, it would be nice if you could pack attachments the next time (bzip2 or gzip are fine). Thank you. I have to apologize; I didn't realize that the mail was so large. I'll pack the attachment next time. -biesi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -dlopen self on AIX
Albert Chin wrote: On Sun, Oct 30, 2005 at 11:14:14AM -0600, Albert Chin wrote: [snip ...] This means the method libtool uses to support -dlopen self on AIX won't work (by building a list of symbols into some xxS.o file and linking it with the executable). The real solution is to -bE the symbol list. What's the cleanest way to do this? Dynamic module support in openldap-2.3.x isn't working on AIX for the above reason. Using -bexpall or -bE when linking the main binary does work though. While the main binary, slapd, doesn't dlopen itself, modules it dlopen()'s cannot resolve symbols in slapd because they weren't exported. Seems the openldap folks should really use -export-dynamic, which isn't defined for AIX. We could make it -bexpall but as documented in the previous mail, it doesn't export everything. So, should we create a new variable, export_dynamic_cmds? If so, and temporary files are created by it, how do we clean up? Wait. The fact that -bexpall doesn't export everything is A Good Thing. Symbol tables on AIX include a lot of junk that other modules simply don't need to see. The symbols they omit are generally not useful for user code anyway. (In contrast to older releases of AIX, where they really did export everything, and you'd get clashes for stupid things like __init and such that never should have been exported in the first place.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -dlopen self on AIX
Bob Friesenhahn wrote: On Sun, 30 Oct 2005, Albert Chin wrote: Seems the openldap folks should really use -export-dynamic, which isn't defined for AIX. We could make it -bexpall but as documented in the previous mail, it doesn't export everything. So, should we create a new variable, export_dynamic_cmds? If so, and temporary files are created by it, how do we clean up? A better approach for openldap is to have the daemon and its modules depend on a common shared library. As far as I am aware, this works ok under AIX and other systems. Designing modules so that they depend on symbols from the executable which loads them is just asking for trouble. We've talked about taking this approach before. Essentially all of the slapd code would become a shared library, and the main program would just be a stub that loads it. (This became an issue back in release 2.1, when the slap tools were still separate executables. Since shared modules record the name of the file that exports their symbols, a shared module linked against slapd would not work when loaded by slapadd. And this was before the AIX linker supported importing files against . and ... The solution at that time was to merge all of the slap tools into the main slapd executable, which we did in release 2.2. The same issue bit us on Windows, and the same fix worked there too.) Unfortunately the shared library-slapd approach is unmanageable because the code uses on a number of static libraries that are not usually compiled as PIC code. It would be a pretty drastic change to get that all working. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HEAD test 13
On Sun, 30 Oct 2005, Tim Rice wrote: . 13. old-m4-iface.at:34: testing ... libtoolize: linking file `./config.guess' libtoolize: linking file `./config.sub' libtoolize: linking file `./install-sh' libtoolize: linking file `./ltmain.sh' libtoolize: You should add the contents of `/opt/src/gnu/libtool-2.x/libltdl/m4/libtool.m4' to `aclocal.m4'. old-m4-iface.at:79: $AUTOCONF --force stderr: UX:ksh: ERROR: autoconf: not found stdout: old-m4-iface.at:79: exit code was 1, expected 0 13. old-m4-iface.at:34: 13. AM_PROG_LIBTOOL (old-m4-iface.at:34): FAILED (old-m4-iface.at:79) . Should test 13 fail if the system you are testing on has no autoconf? Perhaps it should pass. Same for 14, 27, 28 And aclocal in 14, 21, 22, 23, 27, 28 -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -dlopen self on AIX
On Sun, Oct 30, 2005 at 12:16:01PM -0600, Albert Chin wrote: On Sun, Oct 30, 2005 at 11:56:30AM -0600, Albert Chin wrote: On Sun, Oct 30, 2005 at 11:14:14AM -0600, Albert Chin wrote: [snip ...] This means the method libtool uses to support -dlopen self on AIX won't work (by building a list of symbols into some xxS.o file and linking it with the executable). The real solution is to -bE the symbol list. What's the cleanest way to do this? Dynamic module support in openldap-2.3.x isn't working on AIX for the above reason. Using -bexpall or -bE when linking the main binary does work though. While the main binary, slapd, doesn't dlopen itself, modules it dlopen()'s cannot resolve symbols in slapd because they weren't exported. Seems the openldap folks should really use -export-dynamic, which isn't defined for AIX. We could make it -bexpall but as documented in the previous mail, it doesn't export everything. So, should we create a new variable, export_dynamic_cmds? If so, and temporary files are created by it, how do we clean up? Related to this, if always_export_symbols=yes, shouldn't we run $export_symbols_cmds against programs as well? export_symbols_cmds=yes only on AIX but it's equally important for programs and libraries. I finished a patch for this but it's not robust. There's nothing we can do. If a program links against an archive library in the build process, the linker will pull in whatever symbols it needs from the archive library. If we export a full set of symbols from both the program and the library, we might get unresolved symbols from the linker because we've included symbols in the export list that the linker wouldn't pull in from the archive library because the program never references them. Oh well. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -dlopen self on AIX
On Sun, Oct 30, 2005 at 12:10:23PM -0800, Howard Chu wrote: Albert Chin wrote: [snip ...] Dynamic module support in openldap-2.3.x isn't working on AIX for the above reason. Using -bexpall or -bE when linking the main binary does work though. While the main binary, slapd, doesn't dlopen itself, modules it dlopen()'s cannot resolve symbols in slapd because they weren't exported. I don't recall what particular hacks we've done to libtool for this on AIX, but Symas builds everything as dynamic modules on all of our platforms, and mostly It Just Works. (Including IBM AIX and z/OS, as well as Solaris, HPUX, Linux, Windows, etc.) In general the only thing I've hacked was to prevent build directories from being embedded into the generated files, and to eliminate all relinking. I've submitted most of our changes back to this list in the past; a lot may have fallen on the floor since those were patches against libtool 1.4. I'll follow up on the OpenLDAP mailing list. I can reproduce my error with a virgin build/install of 2.3.11. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
