Re: FYI: branch-1-5: SCO/bugfix patch 7 of 10: Improve SCO platform support
OK, thanks. Yes, that's better. I had thought to avoid the extra quoting `\$SCOABSPATH' so that it would be invisible to the user from the libtool output, but the way that is now is ok with me. However, it's a good idea not to carry this into CVS HEAD for another reason: Sometime after 2.0 I may want to reform the quoting stuff a bit, both to allow file names with spaces and possibly for efficiency. Above may not work any more then. Right, ans I'm sure we will craft an entirely different mechanism for supporting absolute pathnames. A couple of open questions remain: - was the quoting for allow_undefined_flag different on purpose (i.e., because of some bug in ltmain)? Almost certainly not. Most likely just habbit. I'll check to make sure though. - the archive_cmds and archive_expsyms_cmds do not make use of allow_undefined_flag at all (they used to do so before), that makes its setting ineffective. Could you be bothered to post a followup patch to fix this (including ChangeLog entry, if possible)? Absolutely. I think it was an oversight, but I will test and make sure and ocrrect it. Here's what I installed. In a followup patch, I'll remove the Most excelent, thank you Ralf. Kean
Re: FYI: branch-1-5: SCO/bugfix patch 7 of 10: Improve SCO platform support
- You change shlibpath_overrides_runpath depending on the linker. This makes little sense, as this is a rtld feature, not a ld one. Is there a rationale to this? Yes indeed :) And the interpretation of LD_LIBRARY_PATH is an RTLD feature, but both the SVR4 and GNU ld use it during actual library creation. See the man page Tim pointed you at, and the code in binutils/ld/emultempl/elf32.em. The reason it changes based on link editor is that the SVR4/OSR5 ld looks at LD_LIBRARY_PATH first, then at any DT_RUNPATH or DT_RPATH entries its found along the way. In GNU ld, that order is reversed, hence with GNU ld, setting LD_LIBRARY_PATH really doesn't override DT_RUNPATH whereas on OSR5/SVR4, it really does. Without this, two tests, I believe the rebuild ones, fail, and tell you to set shlibpath_overrides_runpath to no (when using GNU ld). Kean
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
Since this is really for a dying libtool branch, what the heck, repost
as above. At least it would match your usage pattern with
-absolute-soname, too.
Ok attached please find the revised patch. I was unable to
avoid the test in the setting of hardcode_libdir_flag_spec
but I think you'll agree this looks a great deal cleaner.
Kean
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.128
diff -u -3 -p -u -r1.314.2.128 libtool.m4
--- libtool.m4 10 Nov 2005 18:29:38 - 1.314.2.128
+++ libtool.m4 12 Nov 2005 18:11:51 -
@@ -1652,13 +1652,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
@@ -1684,7 +1677,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'
@@ -1717,17 +1710,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
+sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib
/usr/lib /lib'
+shlibpath_overrides_runpath=no
+ else
+sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+shlibpath_overrides_runpath=yes
+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*)
@@ -2353,15 +2356,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]]'
@@ -2388,7 +2387,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
@@ -2634,13 +2633,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 :
@@ -3488,19 +3480,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*)
@@ -3593,27 +3572,57 @@ 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
-
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
The way I understand your intentions, it should suffice if you can
decide at configure time about the absoluteness of the paths (rather
than at link time). So you could do this instead:
if test -z $SCOABSPATH; then
archive_cmds='bla bla'
archive_expsyms_cmds='bla otherbla'
else
# ...
fi
which would be at least a lot more readable.
Sure, I can do that, I'm open for compromise :) The only reason
I did it the way it currently stands is it allows me to do the
following:
./configure
make install
make clean
SCOABSPATH=1 make install DESTDIR=/whatever
with no intervening re-running of configure in between. In fact
the SCOABSPATH thing as it currently stands used to look a great
deal neater. Perhaps this would be more acceptable (I suspect it
might), so that I can preserve the above behaviour (line split
by mailer, not in script):
archive_cmds='$CC -shared
${wl},-h${SCOABSPATH:+${install_libdir}/}$soname -o $lib
$libobjs $deplibs $compiler_flags'
It has the exact same effect, but looks a *great* deal cleaner.
In fact, before I submitted the patch thats how it looked. I
changed it to the current mechanism becuase I thought it made
it more obvious what was happening. But I can see your point
about it being ugly as sin.
If even that is too ugly for you, then I guess I can live with
the pain of having to re-run configure to enable the absolute
path stuff, but I'm really hoping not :)
about moving the hack forward if that doesn't work out). At the first
occurrence of SCOABSPATH, please add a comment that this thingy will not
be supported, and that it breaks testing of uninstalled libraries.
I can certainly do that. Is there a suitable place in the doc
for platform specific quirks that I can document it more
eloquently and obviously too?
Kean
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
I believe hardcode_libdir_flag_spec should be set to
'${wl}-R,$libdir'
in any case. This has little to do with absolute sonames, but with the
dependent programs finding the library. So the SCOABSPATH hack is
mixing up different issues here.
Not at all. If you are using absolute path names you have absolutely
no need to have a DT_RUNPATH entry in the executable, and in fact,
having one there can change the runtime semantics of the program
becuase the search order for libraries will be subtly different
(for any shared libraries that do *not* have absolute path names
becuase they were constructed before the libtool patch). That has
forseeable, albeit unlikely, security implications. Here's why.
Suppose, for arguments sake, you had an a.out with a DT_RUNPATH
entry pointing to /usr/pgsql/lib. That a.out is has the following
DT_NEEDED entries:
/usr/lib/libc.so.1
/usr/pgsql/lib/libpq.so.8
libz.so.1
The /usr/pgsql directory is owned by the PostgreSQL db admin, who
in BigCorp, isn't root, just a DBA. All that DBA needs to do to
get root on that machine is put in a libz.so.1 in /usr/pgsql/lib
and wait for root to run a postgres command at voila, they have
root access.
Without the DT_RUNPATH entry, the RTLD will use the normal
LD_LIBRARY_PATH and standard system locations, which we can assume
a competant root will protect himself from.
Kean
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
Well, I believe the SCOABSPATH is not only ugly, but also broken (from a libtool perspective): if you have a package which creates two libraries, one depending on the other, your uninstalled library will link against a previous installed version, if that exists. While testing, this is wrong. I agree its ugly but its a necessary evil. All the point you raise about it being generalized are valid, and I will help out as much as I can to make that happen. But its going to take a while for 2.0 to be adopted. Meanwhile, I believe a new release of 1.5 is imminent, and people are likely to upgrade to that, and it will be around for a while. The problem is, as things currently stand, libtool will create shared libraries that expose a severe security flaw. Picture this. Someone compiles KDE for their box. It creates a bunch of shared libraries using libtool. kterm is setuid root. A user can now trivially get root on that box if they are running an older release of SCO. The intent of SCOABSPATH was admittedly a little selfish. I would *really* like it if for once, just once, I can pull down a package and do a ./configure; make and have it do the right thing. If I have to maintain my own patched libtool I have to re-autoconf the thing and on some packages, that is very painful. I would really *really* beg that you let me keep the SCOABSPATH thing in as it stands. For normal usage, it doesn't interfere with anybody or anything. Its localized to an OS that a relatively few number of people care about. Its primary user is me, who is pendantic in teh extreme about compiling packages. For example, I always compile twice: first time I do a make install, then I recompile with SCOABSPATH set and to a make install DESTDIR=/whatever for packaging and production. It is by far the safest way to fly. When the more generalized work can be done for 2.0, and more packages adopt it, maybe I wont have to do that. libtool is meant to be a tool for developers. The reality is, there are two of us at SCO that provide 90% of the open source stuff for our platform. I tend to focus on stuff that makes it in-product, and Ron Record does the stuff for our Skunkware collection of open source tools. Between the two of us, you've covered about 50% of the users of libtool on SCO platforms :) SCOABSPATH as it currently stands really helps us immensely. Also, with due respect, if you are going to reject the patch just becuase of the SCOABSPATH thing can I please ask you to reconsider? It may look unclean but in reality its really pretty simple ... insert a libtool variable into another libtool variable is an environment variable is set. There are far worse things going on in libtool :) Kean
Re: FYI: THANKS updated
Index: THANKS === RCS file: /cvsroot/libtool/libtool/THANKS,v retrieving revision 1.47 diff -u -r1.47 THANKS --- THANKS 3 Jul 2005 16:55:48 - 1.47 +++ THANKS 1 Nov 2005 15:54:51 - @@ -6,6 +6,7 @@ to Libtool that an exchange of legal papers with the FSF was warranted: Gord Matzigkeit [EMAIL PROTECTED] 1996-07-11 + James Kean McDonald Johnston [EMAIL PROTECTED] 1997-08-26 Gary V. Vaughan [EMAIL PROTECTED] 1998-11-24 Alexandre Oliva [EMAIL PROTECTED] 1999-03-26 Thomas Tanner[EMAIL PROTECTED] 1999-06-23 Ack! Could I ask you a favour please Ralf? Please just put me in there as Kean Johnston. My full name only appears on my birth certificate and legal documents, it is not how I know myself, think of myself or address myself :) Kean
Re: SCO/buffix patch 6 of 10: AC_PROG_NM fixes
nm_to_check=${ac_tool_prefix}nm
[ -n $ac_tool_prefix] nm_to_check=$nm_to_check nm
Space missing before ]: ^
Right :) I was just typing blind to make sure you were OK with
the concept.
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
*DOH* You are, of course, correct. My grep test fails.
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?
keats:~% /usr/ccs/bin/elf/nm -B /dev/null
/usr/ccs/bin/elf/nm: ERROR: Illegal option -- B
i386/usr/ccs/bin/elf/nm: Usage: i386/usr/ccs/bin/elf/nm [-?CVhnopruvx]
file(s) .
..
[-C] print decoded C++ names
[-V] print version information on stderr
[-h] suppress printing of headings
[-n] sort external symbols by name
[-o] print value and size in octal
[-p[l]] produce terse, easily parsable output
[l] modifier for -p option - produce long listing
of output
[-r] prepend the name of the object file or archive to each
output line
[-u] print only undefined symbols
[-v] sort external symbols by value
[-x] print value and size of a symbol in hex
keats:~% echo $?
1
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.
Believe me I know :)
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.
Right, I know and get that. But this was a configure-time check,
not a runtime check and I was just being consistent. Now mind
you, configure itself is pretty damned slow :) On my system
it takes, for example, 11 times as long to configure automake
as it does to make and make install. So I am all for speeding
up configure in any way we can too. When we iron out how to do
the actual test I will happily convert it back to a case
check.
As a side note, would it be worthwhile auditing libtool.m4
to see where there are *other* places we can eliminate grep
with case statements?
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.
I was thinking about this some more. Creating a small object
and checking its output could actually be quite useful, and
possibly even combine two tests. (AC_PROG_NM and
AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE). Even without combining
them, creating an object file with the compiler we will
actually be using is probably a good thing. Here's why.
Consider the multi-ABI world again, where tools may behave
differently depending on the object type (like SCO, for
example). The current check for /dev/null isn't really
an accurate refelction of what the tool can/cant or will/wont
do. So for the sake of pure correctness, creating the
object is the best way to go.
If we did that, and we carefully chose the list of symbols
that we put into the test, we could either feed the result
of the nm into AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE or else
combine the two tests. That way we save on yet another
fork/exec inside A_L_S_G_S_P for symbols we already need to
extract in AC_PROG_NM.
Oh and while I am thinking of saving forks/execs, how
universal is 'sort -u' ? Thats quicker than 'sort | uniq'.
Kean
Cheers,
Ralf
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} ...
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: 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
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 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
