FYI: Remove duplicate settion of archive_expsym_cmds=yes on AIX
Hi Albert,
* Albert Chin wrote on Mon, Oct 31, 2005 at 07:18:40AM CET:
always_export_symbols is set before the if statement enclosing the
code below so remove duplicates.
Patch against branch-1-5.
Thanks. Applied, and also the following to HEAD.
Cheers,
Ralf
2005-10-31 Albert Chin-A-Young [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG)
[ aix ]: Remove duplicate always_export_symbols=yes for AIX.
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.27
diff -u -r1.27 libtool.m4
--- libltdl/m4/libtool.m4 13 Oct 2005 13:22:55 - 1.27
+++ libltdl/m4/libtool.m4 31 Oct 2005 08:36:33 -
@@ -4165,8 +4165,6 @@
# -berok will link without error, but may produce a broken library.
_LT_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
_LT_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
_LT_TAGVAR(archive_cmds_need_lc, $1)=yes
@@ -5161,8 +5159,6 @@
# -berok will link without error, but may produce a broken library.
_LT_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
_LT_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
_LT_TAGVAR(archive_cmds_need_lc, $1)=yes
Re: SCO/bugfix patch 1 of 10: AC_LIBTOOL_SYS_MAX_CMD_LEN
Hi Kean, This time including useful content (sorry!). * Kean Johnston wrote on Mon, Oct 31, 2005 at 02:02:28AM CET: 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. So I guess we don't want to see the read failure error from grep, since we deal with it. This slightly simpler patch should work as well, with sed being greedy. OK? Cheers, Ralf 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.116 diff -u -r1.314.2.116 libtool.m4 --- libtool.m4 31 Oct 2005 08:38:50 - 1.314.2.116 +++ libtool.m4 31 Oct 2005 09:09:16 - @@ -738,6 +738,17 @@ esac fi ;; + sco3.2v5*) +lt_cv_sys_max_cmd_len=102400 +;; + sysv5* | sco5v6* | sysv4.2uw2*) +kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2/dev/null` +if test -n $kargmax; then + lt_cv_sys_max_cmd_len=`echo $kargmax | sed '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
FYI: SCO/bugfix patch 2 of 10: ltmain.in dlopen_deplibs
Hi Kean, * Kean Johnston wrote on Mon, Oct 31, 2005 at 02:03:26AM CET: Patch 2 of 10 attached ... Rationale: All SCO platforms open dependency libraries when you dlopen a module. OK. Applied to branch-1-5 and HEAD (shown below), although I exchanged your proposed ChangeLog entry with the description above, which I think is much better. :) FYI: in order to conform to our ChangeLog entry format, I'll add this: [ sysv5*, sco3.2v5*, sco5v6*, unixware*, OpenUNIX*, sysv4*uw2* ] Patches for various bug fixes, small improvements and updating the SCO platform support. at the top of the last commit, and also add the THANKS entry which will remove Gary from the second place in the list. :- Cheers, Ralf 2005-10-31 Kean Johnston [EMAIL PROTECTED] * libltdl/m4/ltdl.m4 (LT_SYS_DLOPEN_DEPLIBS): All SCO platforms open dependency libraries when you dlopen a module. Index: libltdl/m4/ltdl.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v retrieving revision 1.15 diff -u -r1.15 ltdl.m4 --- libltdl/m4/ltdl.m4 14 Oct 2005 15:43:08 - 1.15 +++ libltdl/m4/ltdl.m4 31 Oct 2005 09:41:15 - @@ -361,6 +361,9 @@ solaris*) lt_cv_sys_dlopen_deplibs=yes ;; + sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*) +libltdl_cv_sys_dlopen_deplibs=yes +;; esac ]) if test $lt_cv_sys_dlopen_deplibs != yes; then
Re: SCO/bugfix patch 3 of 10: AC_LIBTOOL_DLOPEN_SELF
Hi Kean,
* Kean Johnston wrote on Mon, Oct 31, 2005 at 02:04:01AM CET:
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.
OMG, flawed it truly is. Good catch!
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.
Your fix isn't correct, as there needs to be one more expansion level,
so that the compiler won't see ${wl}, but its variable expansion. Also,
I'd like to avoid cluttering namespace.
we use $lt_prog_compiler_static wrongly in one more place. Also, while
looking at this I happened to stumble over a couple of wrong variables
that presumably used to be used instead of ${wl} (?).
My current version of this patch is shown below. Not checking it in
yet; it affects all systems and needs a bit more testing (for example,
on my GNU/Linux system the test will fail), and checking that $wl does
not need to be set/expanded in more places.
Cheers,
Ralf
2005-10-31 Kean Johnston [EMAIL PROTECTED],
Ralf Wildenhues [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_DLOPEN_SELF): Use
`lt_prog_compile_static', not `link_static_flag'. Expand `$wl'
so expansion of `export_dynamic_flag_spec' works.
(AC_LIBTOOL_PROG_LD_SHLIBS) [ aix3 ]: Likewise.
(AC_LIBTOOL_PROG_COMPILER_PIC) [ hpux* ]: Use `${wl}'.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.117
diff -u -r1.314.2.117 libtool.m4
--- libtool.m4 31 Oct 2005 09:59:15 - 1.314.2.117
+++ libtool.m4 31 Oct 2005 11:32:45 -
@@ -949,7 +949,7 @@
])
if test x$lt_cv_dlopen_self = xyes; then
- LDFLAGS=$LDFLAGS $link_static_flag
+ LDFLAGS=$LDFLAGS\ `wl=$lt_prog_compiler_wl eval echo
$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(
@@ -4850,14 +4850,14 @@
case $cc_basename in
CC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)=${ac_cv_prog_cc_wl}-a
${ac_cv_prog_cc_wl}archive
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
if test $host_cpu != ia64; then
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
fi
;;
aCC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)=${ac_cv_prog_cc_wl}-a
${ac_cv_prog_cc_wl}archive
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
case $host_cpu in
hppa*64*|ia64*)
# +Z the default
@@ -5516,7 +5516,7 @@
# Note: this linker hardcodes the directories in LIBPATH if there
# are no directories specified by -L.
_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
- if test $GCC = yes test -z $link_static_flag; then
+ if test $GCC = yes test -z $lt_prog_compiler_static; then
# Neither direct hardcoding nor static linking is supported with a
# broken collect2.
_LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
Re: 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. I don't expect this patch to get accepted because there's already a patch from Keith Packard which addresses this issue: http://lists.gnu.org/archive/html/libtool/2005-07/msg00093.html -- Greetings, Christoph 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse für Mail, Message, More +++
Re: SCO/bugfix patch 10 of 10: --version-info improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kean Johnston wrote: | | 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. Hi, Well, you expected some resistance... :) I think that this would encourage developers to do the wrong thing. I can see people doing 0:0:0:libfoo.1.so, which is not portable! You rationale says to me remove the unnecessary symlink and make the real library's name match its soname (which is not likely to happen until post 2.0). Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQ2YqR7iDAg3OZTLPAQIdMgP/cEEeyp3QtEoKK14p+QkGz+DeNytTS2sE F11XhDbN5bHQFVtpK4hsCZuPlLdzi2VWgEgm4dVE0l/yDpnHp7t/BujkDDkD6nFG HscZl9tk3lS8aGUk6RhBr8AUmZYCCbv5i3GrbyCtrt51M6IIX4BDCeTswmK24Wq9 4NWWQ3EF1mY= =qbJD -END PGP SIGNATURE-
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kean Johnston wrote: | | -sco3.2v5*) | - version_type=osf I haven't looked closely yet, but I worry about changing the version_type, as it will result in startlingly different output on these platforms for different versions of libtool. Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQ2YtHriDAg3OZTLPAQI7pQP/QDhNqLqpsP3Ra8/OdhnLktnAOOKF94nY YPTVEkwjuwBM1fQOvKj5v+lNNBWPdeoM2qbPjcuoGqzD1YiRcEEgyVybfRO49P82 vdrKmMrbcbxoM9KD7vjSXzC7hVfSyWFbTGVD20G4KAD59U6pD/GbcnUEWWm1xK+r wMFGCmwxuKs= =d4Tj -END PGP SIGNATURE-
Re: SCO/bugfix patch 4 of 10: ltmain.in rpath variable
Aren't you looking for install_libdir? Aha! Yes indeed. Should I resubmit the sco patch to take this into account? Kean
Re: SCO/bugfix patch 3 of 10: AC_LIBTOOL_DLOPEN_SELF
Ralf Wildenhues wrote: It's even worse, plain `echo' might not like the hyphen as first character. Next try: For the sake of legibility, how about: sflag=`wl=$lt_prog_compiler_wl eval echo $lt_prog_compiler_static ` LDFLAGS=$LDFLAGS $sflag This way you avoid the escaping of the quotes and the not-so-obvious concatenation of strings in the LDFLAGS assignment. 'sflag' intentionally kept to a short name so that Thunderbird doesnt wrap the lines above. Kean
Re: About the use of ${wl} ...
* Kean Johnston wrote on Mon, Oct 31, 2005 at 05:00:40PM CET:
If you find youself having to make changes to things that
use ${wl}, consider consolidating the arguments. It makes some
long lines a bit shorter, and can read better. -Wl takes any
number of comma-separated arguments and expands them out
correctly when invoking the link editor. So instead of:
some_variable=${wl}-h ${wl}$soname
you can use:
some_variable=${wl}-h,$soname
Are you speaking of arguments given to `libtool' or given to `$CC'?
If the latter: AFAIK not every compiler allows aggregation of arguments
after its variant of $wl. `libtool' OTOH copes fine with
./libtool --mode=link gcc -Wl,-foo,-bar,-baz ...
Although there are no cases I have seen thus far that would be
affected, this is also a bit safer, as it guarantees that the
correct arguments travel with the correct options. At least at
one point in its lifetime, libtool would rewrite command lines
and if you happen to split along the incorrect boundary you
could land in a world of trouble.
Ok, so you are speaking about `libtool'. Well, please report any
cases where you see this.
OTOH, some compiler drivers reorder as well. Last bug report entered
bug-libtool a few hours ago.
Like I said, its just cosmetic, but then my brain was compiled
with -pedantic :)
Pedantic is necessary for libtool, if you want to keep it from breaking.
Cheers,
Ralf
Re: SCO/bugfix patch 3 of 10: AC_LIBTOOL_DLOPEN_SELF
* Kean Johnston wrote on Mon, Oct 31, 2005 at 05:20:20PM CET: For the sake of legibility, how about: sflag=`wl=$lt_prog_compiler_wl eval echo $lt_prog_compiler_static ` LDFLAGS=$LDFLAGS $sflag This way you avoid the escaping of the quotes and the not-so-obvious concatenation of strings in the LDFLAGS assignment. You have to escape the quotes. Your example above won't work always: lt_prog_compiler_static may begin with `-n': lt_prog_compiler_static=-non-shared `echo' may interpret `-n'. Boom. Prepending `echo's first argument with a space fixes that. 'sflag' intentionally kept to a short name so that Thunderbird doesnt wrap the lines above. Yeah, I guess a helper variable would be ok. Cheers, Ralf
Re: About the use of ${wl} ...
Are you speaking of arguments given to `libtool' or given to `$CC'? $CC If the latter: AFAIK not every compiler allows aggregation of arguments after its variant of $wl. Ah. I thought it was pretty universal. If not then just ignore the suggestion. But I checked Irix, Solaris, HP-UX 10, HP-UX 11, Tru64 (and OSF/1), and of course any OS that uses GCC as its compiler. Also checked icc. They all do agregation. If even *IRIX* does it ... :) Kean
Re: SCO/bugfix patch 3 of 10: AC_LIBTOOL_DLOPEN_SELF
You have to escape the quotes. Your example above won't work always:
lt_prog_compiler_static may begin with `-n':
lt_prog_compiler_static=-non-shared
`echo' may interpret `-n'. Boom. Prepending `echo's first argument
with a space fixes that.
Aha. Right you are.
Actually, you just need to escape the quotes, there's no need
to actually add a space. This shell script worked on all of
ksh, bourne shell (real one, not bash masquerading as one),
zsh and bash:
compiler_wl='-Wl,'
static='-n ${wl}-foo,bar ${wl}baz'
flags=`wl=$compiler_wl eval echo \$static\`
echo $flags
Not that the extra spacing matters, but I'm doing that pedantic
thing again :)
So getting back to an actual bit of libtool code, we could have:
sflag=`wl=$lt_prog_compiler_wl eval echo \$lt_prog_compiler_static\`
LDFLAGS=$LDFLAGS $sflag
Again using a short variable for the sake of my mailer. In actual
code I'd use something like 'tmpstaticflag' to its obviously a
temporary variable.
Kean
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
Kean Johnston wrote:
Patch 7 of 10 attached ...
Here's a re-submission using install_libdir instead of the
'instrpath' hack I invented.
Kean
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'
-
Re: SCO/bugfix patch 1 of 10: AC_LIBTOOL_SYS_MAX_CMD_LEN
On Mon, 31 Oct 2005, Ralf Wildenhues wrote: Hi Kean, [snip] So I guess we don't want to see the read failure error from grep, since we deal with it. This slightly simpler patch should work as well, with sed being greedy. OK? Tests fine here. Cheers, Ralf 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.116 diff -u -r1.314.2.116 libtool.m4 --- libtool.m431 Oct 2005 08:38:50 - 1.314.2.116 +++ libtool.m431 Oct 2005 09:09:16 - @@ -738,6 +738,17 @@ esac fi ;; + sco3.2v5*) +lt_cv_sys_max_cmd_len=102400 +;; + sysv5* | sco5v6* | sysv4.2uw2*) +kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2/dev/null` +if test -n $kargmax; then + lt_cv_sys_max_cmd_len=`echo $kargmax | sed '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 -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
FYI: SCO/bugfix patch 1 of 10: AC_LIBTOOL_SYS_MAX_CMD_LEN
Hi Kean, Tim, * Kean Johnston wrote on Mon, Oct 31, 2005 at 04:28:11PM CET: Yes your simplified sed looks fine. Thanks! * Tim Rice wrote on Mon, Oct 31, 2005 at 07:14:27PM CET: On Mon, 31 Oct 2005, Ralf Wildenhues wrote: [snip] So I guess we don't want to see the read failure error from grep, since we deal with it. This slightly simpler patch should work as well, with sed being greedy. OK? Tests fine here. Thanks. Applied to branch-1-5 as shown, and CVS HEAD as below. Cheers, Ralf 2005-10-31 Kean Johnston [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): Set correctly for SCO. Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.29 diff -u -r1.29 libtool.m4 --- libltdl/m4/libtool.m4 31 Oct 2005 09:58:38 - 1.29 +++ libltdl/m4/libtool.m4 31 Oct 2005 18:52:38 - @@ -1378,6 +1378,17 @@ esac fi ;; + sco3.2v5*) +lt_cv_sys_max_cmd_len=102400 +;; + sysv5* | sco5v6* | sysv4.2uw2*) +kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2/dev/null` +if test -n $kargmax; then + lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[[ ]]//'` +else + lt_cv_sys_max_cmd_len=32768 +fi +;; *) # Make teststring a little bigger before we do anything with it. # a 1K string should be a reasonable start.
Re: About the use of ${wl} ...
Hi Kean, * Kean Johnston wrote on Mon, Oct 31, 2005 at 06:03:06PM CET: Are you speaking of arguments given to `libtool' or given to `$CC'? $CC OK. If the latter: AFAIK not every compiler allows aggregation of arguments after its variant of $wl. Ah. I thought it was pretty universal. If not then just ignore the suggestion. But I checked Irix, Solaris, HP-UX 10, HP-UX 11, Tru64 (and OSF/1), and of course any OS that uses GCC as its compiler. Also checked icc. They all do agregation. If even *IRIX* does it ... :) Well, we might consider changing that, if we find no compiler that disobeys this rule; I don't *know* offhand of a counter example, to be honest. We'd just need to check all Fortran, C, C++, compilers, gcj, Portland, IBM. Besides the OSes you mentioned, all w32 are missing; since a msvc update is pending, that one should work as well, also windres. Also a couple of rarer used ones, plus of course a bit older releases. So, do you still think this holds everywhere? Cheers, Ralf
Re: [1/3] 304-gary-add-libtool-macro-file-serial-tags.diff
Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 31, 2005 at 05:11:01PM CET: libltdl/m4/argz.m4 |2 +- libltdl/m4/ltoptions.m4 |2 +- libltdl/m4/ltsugar.m4 |2 +- libltdl/m4/ltversion.in |2 +- 4 files changed, 4 insertions(+), 4 deletions(-) Index: libtool--devo--1.0/ChangeLog from Gary V. Vaughan [EMAIL PROTECTED] * libltdl/m4/argz.m4, libltdl/m4/ltoptions.m4, libltdl/ltsugar.m4, libltdl/m4/ltversion.in: Add serial number tags, and bump serial number. Well, the patch doesn't have any obvious flaws, but on its own, it doesn't have too much of a point, either, right? :-) Cheers, Ralf
Re: SCO/bugfix patch 10 of 10: --version-info improvement
Hi Kean, * Kean Johnston wrote on Mon, Oct 31, 2005 at 02:08:33AM CET: 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. Yes. Very retarded. Please file bugs with them. 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. *snip* I can only agree with Christoph here, that this overlaps with Keith Packard's proposed patch. If you have (too) much spare energy, ;) you can try to get his latest version working decently on w32 systems, AIX (or at least degrade gracefully), and there'll be a good chance of it going in right after 2.0. Oh, and for modules it may be nice, too (optionally). ;-) Cheers, Ralf 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. *snip*
glibc and dlopen self static (was: SCO/bugfix patch 3 of 10: AC_LIBTOOL_DLOPEN_SELF)
* Kean Johnston wrote on Mon, Oct 31, 2005 at 06:14:27PM CET:
So getting back to an actual bit of libtool code, we could have:
sflag=`wl=$lt_prog_compiler_wl eval echo \$lt_prog_compiler_static\`
LDFLAGS=$LDFLAGS $sflag
Let's just go a different, simpler route:
wl=$lt_prog_compiler_wl eval LDFLAGS=\\$LDFLAGS $lt_prog_compiler_static\
Similarly to a few lines above the offending snippet.
I have a completely different set of questions now: Why in the world is
that test executable (changed as below) giving me
| /opt/intel_cc_80/lib/: cannot read file data: Is a directory
when I try to dlopen(0, ..), whereas dlopen(./conftest, ..) gives me
| ./conftest: cannot dynamically load executable
on GNU/Linux, glibc-2.3.2 (Debian sarge)? Hmm, when I unset
LD_LIBRARY_PATH, the former becomes
| /lib/: cannot read file data: Is a directory
instead. Bug in dlopen/dlerror?
Cheers,
Ralf
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.118
diff -u -r1.314.2.118 libtool.m4
--- libtool.m4 31 Oct 2005 18:54:20 - 1.314.2.118
+++ libtool.m4 1 Nov 2005 04:21:09 -
@@ -854,6 +854,8 @@
else if (dlsym( self,_fnord)) status = $lt_dlneed_uscore;
/* dlclose (self); */
}
+ else
+puts (dlerror ());
exit (status);
}]
@@ -960,7 +962,7 @@
])
if test x$lt_cv_dlopen_self = xyes; then
- LDFLAGS=$LDFLAGS $link_static_flag
+ wl=$lt_prog_compiler_wl eval 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(
@@ -4861,14 +4857,14 @@
case $cc_basename in
CC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)=${ac_cv_prog_cc_wl}-a
${ac_cv_prog_cc_wl}archive
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
if test $host_cpu != ia64; then
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
fi
;;
aCC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)=${ac_cv_prog_cc_wl}-a
${ac_cv_prog_cc_wl}archive
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
case $host_cpu in
hppa*64*|ia64*)
# +Z the default
@@ -5527,7 +5523,7 @@
# Note: this linker hardcodes the directories in LIBPATH if there
# are no directories specified by -L.
_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
- if test $GCC = yes test -z $link_static_flag; then
+ if test $GCC = yes test -z $lt_prog_compiler_static; then
# Neither direct hardcoding nor static linking is supported with a
# broken collect2.
_LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
more macro cleanup: AC_LIBTOOL_DLOPEN_SELF
While working on Kean's third patch, I noticed more (harmless) bogosity: AC_LIBTOOL_DLOPEN_SELF need only be called once, for C, not once per tag. Similarly with current AC_LIBTOOL_SYS_LIB_STRIP. OK to apply to branch-1-5 and forward-port (HEAD has only the STRIP_LIB part missing, I believe)? Cheers, Ralf * libtool.m4 (AC_LIBTOOL_LANG_C_CONFIG) (AC_LIBTOOL_LANG_CXX_CONFIG, AC_LIBTOOL_LANG_F77_CONFIG) (AC_LIBTOOL_LANG_GCJ_CONFIG): Only call AC_LIBTOOL_SYS_LIB_STRIP and AC_LIBTOOL_DLOPEN_SELF in the C case, and without the tag argument. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.118 diff -u -r1.314.2.118 libtool.m4 --- libtool.m4 31 Oct 2005 18:54:20 - 1.314.2.118 +++ libtool.m4 31 Oct 2005 21:09:22 - @@ -2650,7 +2650,7 @@ AC_LIBTOOL_SYS_DYNAMIC_LINKER($1) AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1) AC_LIBTOOL_SYS_LIB_STRIP -AC_LIBTOOL_DLOPEN_SELF($1) +AC_LIBTOOL_DLOPEN_SELF # Report which librarie types wil actually be built AC_MSG_CHECKING([if libtool supports shared libraries]) @@ -3654,8 +3654,6 @@ AC_LIBTOOL_PROG_LD_SHLIBS($1) AC_LIBTOOL_SYS_DYNAMIC_LINKER($1) AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1) -AC_LIBTOOL_SYS_LIB_STRIP -AC_LIBTOOL_DLOPEN_SELF($1) AC_LIBTOOL_CONFIG($1) @@ -3920,8 +3918,6 @@ AC_LIBTOOL_PROG_LD_SHLIBS($1) AC_LIBTOOL_SYS_DYNAMIC_LINKER($1) AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1) -AC_LIBTOOL_SYS_LIB_STRIP - AC_LIBTOOL_CONFIG($1) @@ -3982,8 +3978,6 @@ AC_LIBTOOL_PROG_LD_SHLIBS($1) AC_LIBTOOL_SYS_DYNAMIC_LINKER($1) AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1) -AC_LIBTOOL_SYS_LIB_STRIP -AC_LIBTOOL_DLOPEN_SELF($1) AC_LIBTOOL_CONFIG($1)
Re: SCO/buffix patch 6 of 10: AC_PROG_NM fixes
Hi Kean,
* Kean Johnston wrote on Mon, Oct 31, 2005 at 02:06:10AM CET:
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.
Erm, are you using --host when configuring? If so, why (are you cross
compiling)? If not, $ac_tool_prefix should be empty. In any case,
while a search for a nm without the prefix is ok (since that's what
AC_CHECK_TOOL does as well), I'm a bit uneasy about the search order: it
should check for prefixed nm everywhere first, and unprefixed
afterwards.
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.
I assume this change is ok. (Searching the net for the string
/usr/ccs/bin/elf hasn't turned up much :)
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.
I'm pretty sure your change breaks the intended workaround for HPUX.
OTOH, I have absolutely no idea about its relevance today; it dates from
1997/11/28, and I don't have any more information about this available
(and no access to HP-UX).
In any case, I believe you got the logic wrong there: /dev/null being
present in the output is taken as a _positive_ sign, ie. that nm
understands -B, iff present in the first line. What does
nm -B /dev/null
on SCO output, by the way? Maybe we can adjust the old scheme to that?
Furthermore, I really don't like that you changed a shell pattern match
to a slow grep; also, please note that grep regexes are different from
shell patterns in that they aren't anchored, so you don't need all those
`.*'.
I'm wondering whether it's easiest to just create an object file first.
Will be most expensive, but most reliable, too..
Cheers,
Ralf
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.m49 Oct 2005 06:26:21 - 1.314.2.115
+++ libtool.m430 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
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
Hi Kean, * Kean Johnston wrote on Mon, Oct 31, 2005 at 06:43:03PM CET: Patch 7 of 10 attached ... Here's a re-submission using install_libdir instead of the 'instrpath' hack I invented. Rationale: I like it when things work on my platform :) Ugh. It's really difficult to judge over this huge patch -- would have been much easier without the SCOABSPATH part. Also, I haven't checked closely yet (other eyes appreciated!), so I'll only give a few suggestions: - the SCOABSPATH stuff should likely be replaced by a generic libtool option to achieve the same thing, or dropped. Failing that, libtool should to things on SCO the way it does on other platforms, ie. hardcode the stuff that's not found by default. (New features are post 2.0, by the way.) - You may and should use `~' as command separator in *_cmds, together with newlines. For example: foo_cmds='ls~echo~cat baz~ if $foo; then bar; fi' - Ideally, C++ support should be tested with CVS HEADs template library tests first.. but that is optional. - the `-belf' setting (sco3.2v5*) vanished completely: | - sco3.2v5*) | -_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)='-belf' Oversight? If not: it's the only cruft that uses lt_prog_cc_shlib at all, so the whole bag of that can go as well. - the ChangeLog entry is, umm, a bit terse. But granted, it's not needed until the rest is in good shape. By the way, is there good online documentation for these systems' ld and dynamic loader? Cheers, Ralf 2005-10-24 Kean Johnston [EMAIL PROTECTED] * libtool.m4: Complete overhaul of SCO support.
inherited_linker_flags repetition
We need to do something about repeated inherited_linker_flags. Happens with CVS HEAD but not branch-1-5, obviously. It's not *quite* as trivial as it looks like, when flags with arguments come into play. Any takers? Cheers, Ralf /bin/sh ../../../../libtool --tag=CC --mode=link gcc -O3 -DNDEBUG -fno-strict-aliasing -pthread -module -avoid-version -export-dynamic -o mca_coll_self.la -rpath /tmp/install/lib/openmpi coll_self_allgather.lo coll_self_allgatherv.lo coll_self_allreduce.lo coll_self_alltoall.lo coll_self_alltoallv.lo coll_self_alltoallw.lo coll_self_barrier.lo coll_self_bcast.lo coll_self_component.lo coll_self_gather.lo coll_self_gatherv.lo coll_self_module.lo coll_self_reduce.lo coll_self_reduce_scatter.lo coll_self_scan.lo coll_self_exscan.lo coll_self_scatter.lo coll_self_scatterv.lo /tmp/build/ompi/libmpi.la /tmp/build/orte/liborte.la /tmp/build/opal/libopal.la -lm -lutil -lnsl libtool: link: rm -f -r .libs/mca_coll_self.la .libs/mca_coll_self.lai .libs/mca_coll_self.so libtool: link: gcc -shared .libs/coll_self_allgather.o .libs/coll_self_allgatherv.o .libs/coll_self_allreduce.o .libs/coll_self_alltoall.o .libs/coll_self_alltoallv.o .libs/coll_self_alltoallw.o .libs/coll_self_barrier.o .libs/coll_self_bcast.o .libs/coll_self_component.o .libs/coll_self_gather.o .libs/coll_self_gatherv.o .libs/coll_self_module.o .libs/coll_self_reduce.o .libs/coll_self_reduce_scatter.o .libs/coll_self_scan.o .libs/coll_self_exscan.o .libs/coll_self_scatter.o .libs/coll_self_scatterv.o -Wl,-rpath -Wl,/tmp/build/ompi/.libs -Wl,-rpath -Wl,/tmp/build/orte/.libs -Wl,-rpath -Wl,/tmp/build/opal/.libs -Wl,-rpath -Wl,/tmp/install/lib /tmp/build/ompi/.libs/libmpi.so -L/tmp/build/orte/.libs -L/tmp/build/opal/.libs /tmp/build/orte/.libs/liborte.so /tmp/build/opal/.libs/libopal.so -ldl -lm -lutil -lnsl -pthread -pthread -pthread -pthread -pthread -pthread -pthread -Wl,-soname -Wl,mca_coll_self.so -o .libs/mca_coll_self.so
Re: glibc and dlopen self static
I have a completely different set of questions now: Why in the world is that test executable (changed as below) giving me | /opt/intel_cc_80/lib/: cannot read file data: Is a directory when I try to dlopen(0, ..), whereas dlopen(./conftest, ..) gives me | ./conftest: cannot dynamically load executable on GNU/Linux, glibc-2.3.2 (Debian sarge)? Hmm, when I unset LD_LIBRARY_PATH, the former becomes | /lib/: cannot read file data: Is a directory instead. Bug in dlopen/dlerror? Yes I suspect it must be. I guess in a sense it shows how obscure the case of testing for being able todlopen yourself if you are linked statically is :) So perhaps a more pertinent question is, why is libtool checking for it and does it matter any more? I can't speak for how the glibc RTLD works, but System V derived ones, like the SCO platforms, Solaris, and I believe AIX (but dont quote me on the latter) dont actually provide *any* of the dynamic functions for statically linked executables. In fact, the functions don't even appear in libc.a, so the reason the test fails (on SCO at any rate) is that the program doesn't even link. If glibc doesn't behave similarly, I am quite surprised. However, since it obviously did link for you, it means they at least have the functions visible in libc.a, but of course all of the plumbing doesn't exist, becuase there is no RTLD. I grant you the error message is misleading, but the test should actually be working. You cannot dlopen a static executable :) Kean
Re: glibc and dlopen self static
Hi Kean, * Kean Johnston wrote on Tue, Nov 01, 2005 at 08:06:35AM CET: instead. Bug in dlopen/dlerror? Yes I suspect it must be. I guess in a sense it shows how obscure the case of testing for being able todlopen yourself if you are linked statically is :) So perhaps a more pertinent question is, why is libtool checking for it and does it matter any more? Good question. I can't speak for how the glibc RTLD works, but System V derived ones, like the SCO platforms, Solaris, and I believe AIX (but dont quote me on the latter) dont actually provide *any* of the dynamic functions for statically linked executables. In fact, the functions don't even appear in libc.a, so the reason the test fails (on SCO at any rate) is that the program doesn't even link. If glibc doesn't behave similarly, I am quite surprised. Darn, I should've added the link warning, too, for clarity, sorry: | configure:10487: checking whether a statically linked program can dlopen itself | configure:10561: gcc -o conftest -g -O2 -DHAVE_DLFCN_H -Wl,--export-dynamic -static conftest.c -ldl 5 | /tmp/ccHoR1Xi.o(.text+0x32): In function `main': | /tmp/libtool-1.5/build/configure:10548: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking | configure:10564: $? = 0 However, since it obviously did link for you, it means they at least have the functions visible in libc.a, but of course all of the plumbing doesn't exist, becuase there is no RTLD. I grant you the error message is misleading, but the test should actually be working. You cannot dlopen a static executable :) Actually, I believe at one time this used to work, and the link warning suggests so, too. But then again, I'm not sure, I don't have much experience in this area. Cheers, Ralf
Re: SCO/buffix patch 6 of 10: AC_PROG_NM fixes
Hi Kean,
* Kean Johnston wrote on Tue, Nov 01, 2005 at 08:34:00AM CET:
Erm, are you using --host when configuring? If so, why (are you cross
compiling)? If not, $ac_tool_prefix should be empty. In any case,
It is my habbit to configure everything with:
--host=blah --build=blah --target=blah
Don't do that. You don't want cross_compiling turned to `maybe' if you
in fact aren't. (Surely, for multi-ABI, there is a point, but then not
all blah's above might be the same. :)
while a search for a nm without the prefix is ok (since that's what
AC_CHECK_TOOL does as well), I'm a bit uneasy about the search order: it
should check for prefixed nm everywhere first, and unprefixed
afterwards.
I guess the whole thing could be wrapped in something like:
nm_to_check=${ac_tool_prefix}nm
[ -n $ac_tool_prefix] nm_to_check=$nm_to_check nm
Space missing before ]: ^
Also, you should always use `test' in m4 macros, to avoid needing to
m4-quote the brackets.
for nmfile in $nm_to_check; do
... the current stuff we have
done
Yes, that looks good.
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.
I'm pretty sure your change breaks the intended workaround for HPUX.
OTOH, I have absolutely no idea about its relevance today; it dates from
1997/11/28, and I don't have any more information about this available
(and no access to HP-UX).
Does it break it? The way I read the original code, it was doing
the nm, stripping out the first line in case it contained an
unknown option -B error message, and then looking to see if
the string /dev/null appeared in the output. The change I made
still achives the same result (unless I totoally mis-implemented
it).
Wrong. The original code looked *only* at the first line.
The problem with looking at all lines was _presumably_ this:
HP-UX nm outputs
| nm: unknown option B ignored
| /dev/null: no symbols
or something similar. Also checking the second line would mean, that we
falsely think this nm accepts -B, because we found the string
`/dev/null'. Got it now?
*snip*
So I think you misunderstood the logic :)
Try again. :)
nm -B /dev/null
on SCO output, by the way? Maybe we can adjust the old scheme to that?
A usage message becuase it doesn't support -B, but it does
support -p.
Care to cut and paste it? Thanks. What's the return value?
Furthermore, I really don't like that you changed a shell pattern match
to a slow grep; also, please note that grep regexes are different from
shell patterns in that they aren't anchored, so you don't need all those
`.*'.
Ok :) That last part is simply finger habbit. Sorry. As for replacing
a case with a slow grep, with all due respect I just can't buy
that argument :) grep is *so* heavily used in libtool as it is,
that if it isn't in your cache, you have much bigger problems on
your hands. Almost nowhere else in the libtool code is that case
construct used (only 4 other places in the entire libtool.m4,
one of them recently added by me, and that only becuase I copied
one of the other three usages). It is best to code to the principle
of least surprise rather than blinding efficiency. I won't argue
that using case the way you suggest is quicker, becuase it is,
but it is relatively uncommon in shell scripting in general, and
specifically in libtool itself. There is something to be said
for consistency ...
Sure. configure isn't so much of a problem as ltmain. But you may
search the libtool list archives for bug reports about its slowness.
Least surprise is ok, whereever we're unsure about what works, but
on w32, even current systems can only do a few hundred fork+exec per
second, and it starts to show when script execution takes longer than
subsequent compiler execution. See, not everyone else's needs are your
needs, and libtool is to be generally usable.
I'm wondering whether it's easiest to just create an object file first.
Will be most expensive, but most reliable, too..
I wondered the same thing myself when I changed that bit of code.
I am actually surprised that it works as reliably as it does. But
it does in fact seem to work well, so, if it ain't broke ... :)
ACK.
Cheers,
Ralf
