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: 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
* Ralf Wildenhues wrote on Sun, Nov 13, 2005 at 08:06:42PM CET: > * Kean Johnston wrote on Sat, Nov 12, 2005 at 07:15:24PM CET: > > > > Ok attached please find the revised patch. > > A couple of open questions remain: > - was the quoting for allow_undefined_flag different on purpose > (i.e., because of some bug in ltmain)? > - the archive_cmds and archive_expsyms_cmds do not make use of > allow_undefined_flag at all (they used to do so before), > that makes its setting ineffective. > Could you be bothered to post a followup patch to fix this > (including ChangeLog entry, if possible)? Another one (sorry, I thought I had it listed): - You change shlibpath_overrides_runpath depending on the linker. This makes little sense, as this is a rtld feature, not a ld one. Is there a rationale to this? Cheers, Ralf
clean-libs in builddir (was: SCO/bugfix patch 7 of 10: Improve SCO platform support)
* Kean Johnston wrote on Thu, Nov 10, 2005 at 11:09:31PM CET: > >I know. You could even `find . -name \*.la | xargs rm' to avoid the > >`make clean'. > Hey what a great idea :) > > $ cat > ~/bin/quickclean > #! /bin/sh > find . -name \*.la | xargs rm -f > ^D > $ chmod 755 ~/bin/quickclean > > :) I should add that this is not the Official Way[tm] of doing things. And because it does not remove the actual libs, it might cause weird failures on some systems (I think we've actually had a bug report that involved such a situation. I believe this instead should be pretty safe and quick (save for white space in file names): find . \( -name .libs -o -name _libs \) -prune -o -name \*.la -print | xargs ./libtool --mode=clean rm -f Cheers, Ralf
FYI: HEAD: SCO/bugfix patch 7 of 10: Improve SCO platform support
Hi Tim, Kean,
* Tim Rice wrote on Thu, Nov 10, 2005 at 07:59:52PM CET:
> On Thu, 10 Nov 2005, Ralf Wildenhues wrote:
> >
> > Could you or Tim resubmit the patch like this for branch-1-5?
> > Then, when you forward-port to CVS HEAD, leave out the SCOABSPATH part;
>
> Here is the forward port without the SCOABSPATH bits.
Thanks. Similar to the branch-1-5 patch, I installed this after these
small modifications:
- reformat comments a bit, fix typo execurity -> security
- fixed quoting of allow_undefined_flag (use single quotes so the
expansion occurs in libtool, not in configure).
Accordingly, these questions remain here as well:
- was the quoting for allow_undefined_flag different on purpose
(i.e., because of some bug in ltmain)?
- the archive_cmds and archive_expsyms_cmds do not make use of
allow_undefined_flag at all; that makes its setting ineffective.
Could you be bothered to post a followup patch to fix this
(including ChangeLog entry, if possible)?
Installed patch below.
Cheers, and thanks again,
Ralf
2005-11-13 Kean Johnston <[EMAIL PROTECTED]>,
Tim Rice <[EMAIL PROTECTED]>
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER)
(_LT_CHECK_MAGIC_METHOD, _LT_COMPILER_PIC, _LT_LINKER_SHLIBS)
(_LT_LANG_C_CONFIG, _LT_LANG_CXX_CONFIG)
[ sco3.2v5, sysv4, sysv4.3, sysv5, sco3.2v5, sco5v6, unixware,
OpenUNIX, sysv4*uw2 ]: Complete overhaul of SCO support.
* THANKS: Updated.
Index: THANKS
===
RCS file: /cvsroot/libtool/libtool/THANKS,v
retrieving revision 1.49
diff -u -r1.49 THANKS
--- THANKS 4 Nov 2005 16:45:52 - 1.49
+++ THANKS 13 Nov 2005 18:55:59 -
@@ -59,6 +59,7 @@
Noah Jeffrey Misch [EMAIL PROTECTED] 2004-07-05
Thorsten Glaser [EMAIL PROTECTED]
2004-10-11
Peter Ekberg [EMAIL PROTECTED] 2005-04-12
+ Tim Rice [EMAIL PROTECTED] 2005-11-10
* The following additional people made especially gracious contributions of
@@ -105,7 +106,6 @@
Steven M. Schultz[EMAIL PROTECTED]
Sven Verdoolaege [EMAIL PROTECTED]
Tim Mooney [EMAIL PROTECTED]
- Tim Rice [EMAIL PROTECTED]
Todd Vierling[EMAIL PROTECTED]
Tom Tromey [EMAIL PROTECTED]
Tor Lillqvist[EMAIL PROTECTED]
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.43
diff -u -r1.43 libtool.m4
--- libltdl/m4/libtool.m4 12 Nov 2005 11:54:13 - 1.43
+++ libltdl/m4/libtool.m4 13 Nov 2005 17:20:53 -
@@ -2373,13 +2373,6 @@
sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
;;
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
solaris*)
version_type=linux
need_lib_prefix=no
@@ -2405,7 +2398,7 @@
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -2437,6 +2430,28 @@
fi
;;
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext} $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ if test "$with_gnu_ld" = yes; then
+sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib
/usr/lib /lib'
+ else
+sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+case $host_os in
+ sco3.2v5*)
+sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
+ ;;
+esac
+ fi
+ sys_lib_dlsearch_path_spec='/usr/lib'
+ ;;
+
tpf*)
# TPF is a cross-target only. Preferred cross-host = GNU/Linux.
version_type=linux
@@ -2867,19 +2882,15 @@
lt_cv_deplibs_check_method=pass_all
;;
-sco3.2v5*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
solaris*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]*)
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
case $host_vendor in
motorola)
lt_cv_deplibs_check
FYI: branch-1-5: SCO/bugfix patch 7 of 10: Improve SCO platform support
Hi Kean,
* Kean Johnston wrote on Sat, Nov 12, 2005 at 07:15:24PM CET:
> >Since this is really for a dying libtool branch, what the heck, repost
> >as above. At least it would match your usage pattern with
> >-absolute-soname, too.
>
> Ok attached please find the revised patch. I was unable to
> avoid the test in the setting of hardcode_libdir_flag_spec
> but I think you'll agree this looks a great deal cleaner.
OK, thanks. Yes, that's better. I had thought to avoid the extra
quoting `\$SCOABSPATH' so that it would be invisible to the user from
the libtool output, but the way that is now is ok with me. However,
it's a good idea not to carry this into CVS HEAD for another reason:
Sometime after 2.0 I may want to reform the quoting stuff a bit, both
to allow file names with spaces and possibly for efficiency. Above
may not work any more then.
I went over the patch once, and installed it after a few small
modifications:
- use `test' instead of `[ ]'
- reformat comments a bit, fix typo execurity -> security
- fixed quoting of allow_undefined_flag (use single quotes so the
expansion occurs in libtool, not in configure).
A couple of open questions remain:
- was the quoting for allow_undefined_flag different on purpose
(i.e., because of some bug in ltmain)?
- the archive_cmds and archive_expsyms_cmds do not make use of
allow_undefined_flag at all (they used to do so before),
that makes its setting ineffective.
Could you be bothered to post a followup patch to fix this
(including ChangeLog entry, if possible)?
Here's what I installed. In a followup patch, I'll remove the
now-unnecessary cruft from AC_LIBTOOL_LANG_C_CONFIG. :)
Cheers, and thank you,
Ralf
2005-11-13 Kean Johnston <[EMAIL PROTECTED]>,
Tim Rice <[EMAIL PROTECTED]>
* libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER)
(AC_DEPLIBS_CHECK_METHOD, AC_LIBTOOL_LANG_C_CONFIG)
(AC_LIBTOOL_LANG_CXX_CONFIG, AC_LIBTOOL_PROG_COMPILER_PIC)
(AC_LIBTOOL_PROG_LD_SHLIBS)
[ sco3.2v5, sysv4, sysv4.3, sysv5, sco3.2v5, sco5v6, unixware,
OpenUNIX, sysv4*uw2 ]: Complete overhaul of SCO support.
* THANKS: Updated.
Index: THANKS
===
RCS file: /cvsroot/libtool/libtool/THANKS,v
retrieving revision 1.34.2.12
diff -u -r1.34.2.12 THANKS
--- THANKS 4 Nov 2005 16:46:54 - 1.34.2.12
+++ THANKS 13 Nov 2005 17:32:59 -
@@ -59,6 +59,7 @@
Noah Jeffrey Misch [EMAIL PROTECTED] 2004-07-05
Thorsten Glaser [EMAIL PROTECTED]
2004-10-11
Peter Ekberg [EMAIL PROTECTED] 2005-04-12
+ Tim Rice [EMAIL PROTECTED] 2005-11-10
* The following additional people made especially gracious contributions of
@@ -105,7 +106,6 @@
Steven M. Schultz[EMAIL PROTECTED]
Sven Verdoolaege [EMAIL PROTECTED]
Tim Mooney [EMAIL PROTECTED]
- Tim Rice [EMAIL PROTECTED]
Todd Vierling[EMAIL PROTECTED]
Tom Tromey [EMAIL PROTECTED]
Tor Lillqvist[EMAIL PROTECTED]
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.132
diff -u -r1.314.2.132 libtool.m4
--- libtool.m4 13 Nov 2005 15:09:27 - 1.314.2.132
+++ libtool.m4 13 Nov 2005 17:21:14 -
@@ -1657,13 +1657,6 @@
sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
;;
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
solaris*)
version_type=linux
need_lib_prefix=no
@@ -1689,7 +1682,7 @@
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3*)
+sysv4 | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -1722,17 +1715,27 @@
fi
;;
-sysv5*)
- version_type=linux
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
need_lib_prefix=no
need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext} $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=yes
hardcode_into_libs=yes
- sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
- sys_lib_dlsearch_path_spec="$sys_lib_search_pat
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
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
On Thu, 10 Nov 2005, Ralf Wildenhues wrote: Hi Ralf, > > And how it looks on my platforms. > > http://www.multitalents.net/head-status.html > > this is quite interesting to see, but it really would be much more > interesting to see the VERBOSE=x failures for the old suite tests, > and $top_builddir/tests/testsuite.log for the new suite tests. Done. Check it out now. Thanks for looking at this. > > Don't bother HTMLizing the output if you don't have to, and I suggest a > rerun should wait for my pending testsuite update patch; it hopefully > fixes a lot of the failures you are seeing. Testing your patch was next on my list. :-) -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
I know. You could even `find . -name \*.la | xargs rm' to avoid the `make clean'. Hey what a great idea :) $ cat > ~/bin/quickclean #! /bin/sh find . -name \*.la | xargs rm -f ^D $ chmod 755 ~/bin/quickclean :) 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. Thanks Ralf, I appreciate it :) Will craft a new patch this afternoon or evening. I had hoped doc/notes.texi (CVS HEAD) to be for platform specific questions, but: I definitely don't want to see it in there. I don't want it prominently documented; just people that find it anyway should also be able to find the comment "do not rely on this". Ok will do. Kean
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
Hi Kean,
* Kean Johnston wrote on Thu, Nov 10, 2005 at 10:35:09PM CET:
> >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
> >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
I know. You could even `find . -name \*.la | xargs rm' to avoid the
`make clean'.
> 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.
Well, this is better than your previous version. Still, innocent users
happening to compile a package see the SCOABSPATH, and this is what bugs
me (yes, I know #users <= 2).
> 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 :)
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.
> >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?
I had hoped doc/notes.texi (CVS HEAD) to be for platform specific
questions, but: I definitely don't want to see it in there. I don't
want it prominently documented; just people that find it anyway should
also be able to find the comment "do not rely on this".
Cheers,
Ralf
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
Hi Tim, * Tim Rice wrote on Thu, Nov 10, 2005 at 07:59:52PM CET: > On Thu, 10 Nov 2005, Ralf Wildenhues wrote: > > > > Could you or Tim resubmit the patch like this for branch-1-5? > > I'll let Kean work on this one. OK. > > Then, when you forward-port to CVS HEAD, leave out the SCOABSPATH part; > > Here is the forward port without the SCOABSPATH bits. Thank you. I'll probably apply it together with the branch-1-5 version, and work on any improvements later only. Sorry, I really don't have so much time. But: > And how it looks on my platforms. > http://www.multitalents.net/head-status.html this is quite interesting to see, but it really would be much more interesting to see the VERBOSE=x failures for the old suite tests, and $top_builddir/tests/testsuite.log for the new suite tests. Don't bother HTMLizing the output if you don't have to, and I suggest a rerun should wait for my pending testsuite update patch; it hopefully fixes a lot of the failures you are seeing. Cheers, Ralf
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
On Thu, 10 Nov 2005, Ralf Wildenhues wrote:
>
> Could you or Tim resubmit the patch like this for branch-1-5?
I'll let Kean work on this one.
> Then, when you forward-port to CVS HEAD, leave out the SCOABSPATH part;
Here is the forward port without the SCOABSPATH bits.
And how it looks on my platforms.
http://www.multitalents.net/head-status.html
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- libltdl/m4/libtool.m4.old 2005-11-08 12:11:19.0 -0800
+++ libltdl/m4/libtool.m4 2005-11-10 05:48:07.0 -0800
@@ -2364,13 +2364,6 @@
sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
;;
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
solaris*)
version_type=linux
need_lib_prefix=no
@@ -2396,7 +2389,7 @@
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -2428,6 +2421,28 @@
fi
;;
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext} $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ if test "$with_gnu_ld" = yes; then
+sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib
/usr/lib /lib'
+ else
+sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+case $host_os in
+ sco3.2v5*)
+sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
+ ;;
+esac
+ fi
+ sys_lib_dlsearch_path_spec='/usr/lib'
+ ;;
+
tpf*)
# TPF is a cross-target only. Preferred cross-host = GNU/Linux.
version_type=linux
@@ -2849,19 +2864,15 @@
lt_cv_deplibs_check_method=pass_all
;;
-sco3.2v5*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
solaris*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]*)
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
case $host_vendor in
motorola)
lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB
(shared object|dynamic lib) M[[0-9]][[0-9]]* Version [[0-9]]'
@@ -2882,13 +2893,12 @@
siemens)
lt_cv_deplibs_check_method=pass_all
;;
+ pc)
+lt_cv_deplibs_check_method=pass_all
+;;
esac
;;
-sysv4*uw2* | unixware7*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
tpf*)
lt_cv_deplibs_check_method=pass_all
;;
@@ -3490,15 +3500,6 @@
;;
psos*)
;;
- sco*)
- case $cc_basename in
- CC*)
- _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
- ;;
- *)
- ;;
- esac
- ;;
solaris*)
case $cc_basename in
CC*)
@@ -3530,6 +3531,15 @@
;;
esac
;;
+ sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+ case $cc_basename in
+ CC*)
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ ;;
+ esac
+ ;;
tandem*)
case $cc_basename in
NCC*)
@@ -3540,8 +3550,6 @@
;;
esac
;;
- unixware*)
- ;;
vxworks*)
;;
*)
@@ -3715,11 +3723,6 @@
_LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
;;
-sco3.2v5*)
- _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Kpic'
- _LT_TAGVAR(lt_prog_compiler_static, $1)='-dn'
- ;;
-
solaris*)
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
@@ -3737,7 +3740,7 @@
_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.2uw2* | sysv4.3*)
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
@@ -3750,6 +3753,12 @@
fi
;;
+sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ ;;
+
unicos*)
_LT_TAGVAR(lt_prog_compiler_wl, $1)='
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
Hi Kean, * Kean Johnston wrote on Wed, Nov 09, 2005 at 10:18:27AM CET: > >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. OK. I'll take the SCOABSPATH, but would rather like it a bit differently, if you agree: 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. Could you or Tim resubmit the patch like this for branch-1-5? Then, when you forward-port to CVS HEAD, leave out the SCOABSPATH part; we shall try to get -allow-absolute-soname working (and can still think 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. Would this be ok with you? Cheers, Ralf
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
Hi Kean,
* Kean Johnston wrote on Wed, Nov 09, 2005 at 10:26:11AM CET:
> >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
D'oh, I read the logic the wrong way round (i.e., I thought you added
the -R$libdir only when SCOABSPATH was set, not when it was unset).
Sorry for that confusion.
> (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.
Ah, ok. Hmm, this means though that we /may/ need to refine my
absolute-soname proposal.
- When linking against a library that has an absolute soname, we should
not add its path to rpath. This probably requires that the installed
library has a .la file present, and the absolute path setting is
recorded there, so we can know about this fact.
Now what I don't know is: Do we also need to parameterize this question?
IOW: if an absolute soname overrides whatever other paths are used for
searching, then we wouldn't have to take care of this step. OTOH, if it
could not be overridden at all at link time (as opposed to at execution
time), that would prevent DESTDIR setups, which would suck. :-/
(I don't know if such a system exists.)
With your current SCOABSPATH hack, the information would not be present
in the installed .la files, so when you finally upgrade to a working
-absolute-soname libtool, you will still have to install everything
again, or we'd have to add yet another (really gross, and
system-dependent) hack to find out whether the soname of the installed
library is absolute. Right? The change of hardcode_libdir_flag_spec
depends not on whether your currently compiled library will have
absolute soname, but whether your installations of its dependencies had
it.
Other than above thoughts: your scenario _is_ pretty artificial, don't
you think? I mean, if you either don't trust your PostgreSQL db admin,
or if you have a root admin that executes postgres commands (or any
commands at all, FWIW) without thinking, you have bigger problems than
worrying about shared library searching?! I mean, he could just add
malicious code right in libpq anyway, no need for any shared library
search order games? ;)
(But you do have a point anyway: you might want to guard against him
inadvertantly installing a different libz there.)
Cheers,
Ralf
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
On Wed, 9 Nov 2005, Ralf Wildenhues wrote: Hi Ralf, > > * Tim Rice wrote on Wed, Nov 09, 2005 at 06:57:16AM CET: > > I don't know if this is any help or not, but here are the > > before and after stats on the (sco) platforms I have running. > > http://www.multitalents.net/branch-1-5-status.html > > Thanks. It would be even better if you could show the output of the > failed test groups with VERBOSE=x set. :) > (remember you have to run the tests in groups for them to work) > > There are a few new failures. I wonder why they fail now but did not > before the patch. Maybe the verbose output of the ones that passed > would help, too. There are new failures on UnixWare 2.03 and OpenServer 5.0.4. Of all those platforms listed, those two are the ones I least care about. There are probably only a handful of UW2.03 boxes running in the entire world. And I'm probably the only one that tries to run libtool on it. Although there are more OpenServer 5.0.4 boxes running, it's likely that the number of libtool users on 5.0.4 are very small. They normally just go to SCO's skunkware site and download binaries. The platforms we care about, UnixWare 7.1.4, OpenServer 6.0.0, OpenServer 5.0.7, (and to a lesser extent) UnixWare 7.1.1 are either the same or better. (And even if they are the same test wise, what Kean has done is more correct (ignoring the SCOBASEPATH stuff)) I've attached the failures from UW711. I'll be glad to try out any ideas on how to fix the 3 failures. I suspect if we can figure out the build-relink test that will fix the build-relink2 test also. Those 2 would would put the OpenServer 5.0.4 even with before. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] uw711-build-relink-fail.gz Description: uw711-build-relink-fail.gz uw711-build-relink2-fail.gz Description: uw711-build-relink2-fail.gz uw711-link-order-fail.gz Description: uw711-link-order-fail.gz
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: 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
* Ralf Wildenhues wrote on Wed, Nov 09, 2005 at 08:55:15AM CET:
>
> So, I ask you or Kean to resubmit the patch without the SCOABSPATH
> parts, then I'll take another look again with the help of the manpages
> you pointed to.
Forgot one thing, sorry:
| + _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='`if test -z
"$SCOABSPATH";then echo ${wl}-R,$libdir;fi`'
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.
And, by the way, this does not mean that it requires recompilation
twice, only relinking upon installation. (There are ways and/or plans
to avoid this even.)
Cheers,
Ralf
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
Hi Tim, * Tim Rice wrote on Wed, Nov 09, 2005 at 06:57:16AM CET: > On Tue, 1 Nov 2005, Ralf Wildenhues wrote: > > * 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. > > > > 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: 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 like the idea of enabling absolute sonames though, but as a general Libtool option: - it's rather non-invasive to implement, - it degrades gracefully: some systems (like AIX, I believe, or any static-only system) won't need it anyway, on other systems where it doesn't work, we can just not do it and be fine, - it bears no special relation to UnixWare. So, I ask you or Kean to resubmit the patch without the SCOABSPATH parts, then I'll take another look again with the help of the manpages you pointed to. Also, I'll put adding above on the TODO list. I'll not accept it before 2.0, but I'll be glad to assist in producing a patch against any current version and/or test one, should you or Kean want or need this any earlier. I believe it could work like this: - We add an option `-absolute-soname' to the link-mode flags, and document it. - We add a (non-tagged) _LT_DECL, maybe named allow_absolute_soname. It would be `no' by default, `needless' on AIX, `yes' on GNU/Linux, UnixWare, ... (I'm not sure about the default, the encoding may be cheaper the other way round, given suitable catch-all values.). - If the flag is given, and allow_absolute_soname=yes, and we are creating a library (not a program), we make sure relinking is needed, and mangle the soname appropriately (differently for the uninstalled vs. the installed library; or maybe only for the installed one, I'm not sure). - We add a test to make sure this feature actually works. It would then be easy to update `allow_absolute_soname' for other systems as we go along. I expect the ltmain changes to be pretty small, it's just the testing of them on different systems that needs real work. We can still see about whether there should also be a configure option to enable this, or we should start reading options from an environment variable, to facilitate building a whole bunch of packages with this flag enabled. This is an (or two) orthogonal issue(s), though. If you agree with me on this plan, then all is well. If you disagree, I'd like to hear arguments. My mind is not set in stone, neither am I the only one to decide. With above, you can still have your patches against your local Libtool-1.5 if you're really dying to; both profit: we have less cruft and more general features, and you have your feature, and with time, you won't need a patches Libtool any more. Surely it'll be more work, and I just don't have the time to do the patch myself right now. > I don't know if this is any help or not, but here are the > before and after stats on the (sco) platforms I have running. > http://www.multitalents.net/branch-1-5-status.html [ corrected the obvious typo ] Thanks. It would be even better if you could show the output of the failed test groups with VERBOSE=x set. :) (remember you have to run the tests in groups for them to work) There are a few new failures. I wonder why they fail now but did not before the patch. Maybe the verbose output of the ones that passed would help, too. > > By the way, is there good online documentation for these systems' ld and > > dynamic loader? > > ld man pages are here. *snip* Thank you very much! Cheers, Ralf
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
On Tue, 1 Nov 2005, Ralf Wildenhues wrote: > 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: I don't know if this is any help or not, but here are the before and after stats on the (sco) platforms I have running. http://www.multitlents.net/branch-1-5-status.html > By the way, is there good online documentation for these systems' ld and > dynamic loader? ld man pages are here. UnixWare 7.1.1 http://docsrv.sco.com/cgi-bin/man/man?ld+1 UnixWare 7.1.4 http://uw714doc.sco.com/en/man/html.1/ld.1.html OpenServer 6.0.0 http://osr600doc.sco.com/en/man/html.CP/ld.CP.html OpenServer 5.0.7 http://osr507doc.sco.com/en/man/html.CP/ld.CP.html OpenServer 5.0.6 http://osr5doc.ca.caldera.com:457/cgi-bin/man/man?ld+CP OpenServer 5.0.5 http://osr5doc.ca.caldera.com:1997/cgi-bin/man/man?ld+CP > > Cheers, > Ralf > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
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. >
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=
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
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. Well, considering that libtool has never really worked correctly on SCO until now, and that by far the largest consumers of libtool were people that used the version that was in my on-the-media gnu tools package that was patched to have version_type=freebsd-elf, I don't think we're in trouble here. Also, the osf naming just simply didn't conform to SCOs naming "convention" and the patch does, so it would still be a good idea to change, just for consistency. But of course, SCO is as popular as a pork chop in a Synagogue these days so very few people actually care :) The main OS media ships with about 80 libraries that were created with my modified libtool, so keeping compatible with that is pretty important (the libraries in question are the ones people are most likely to want to compile, like gtk, glib, libxml2, expat, png, zlib etc etc). Kean
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 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 7 of 10: Improve SCO platform support
On Sun, 30 Oct 2005, Kean Johnston wrote:
> Patch 7 of 10 attached ...
>
> Rationale:
>
> I like it when things work on my platform :)
>
> 2005-10-24 Kean Johnston <[EMAIL PROTECTED]>
>
> * libtool.m4: Complete overhaul of SCO support.
>
I'm attaching a corrected patch.
.
case $host_os in
+ sco3.2v5*)
- *-*-sco3.2v5*)
sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
;;
esac
Missing some square brackets.
- sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* |
sco3.2v5.0.[024]*)
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* |
sco3.2v5.0.[[024]]*)
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- libtool.m4.old 2005-10-15 13:12:08.0 -0700
+++ libtool.m4 2005-10-30 18:30:34.371040302 -0800
@@ -1623,13 +1635,6 @@
sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
;;
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
solaris*)
version_type=linux
need_lib_prefix=no
@@ -1655,7 +1660,7 @@
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3*)
+sysv4 | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -1688,17 +1693,27 @@
fi
;;
-sysv5*)
- version_type=linux
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
need_lib_prefix=no
need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext} $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=yes
hardcode_into_libs=yes
- sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
- sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
+ if test "$with_gnu_ld" = yes; then
+shlibpath_overrides_runpath=no
+sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib
/usr/lib /lib'
+ else
+shlibpath_overrides_runpath=yes
+sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+case $host_os in
+ sco3.2v5*)
+sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
+ ;;
+esac
+ fi
+ sys_lib_dlsearch_path_spec='/usr/lib'
;;
uts4*)
@@ -2319,15 +2334,11 @@
lt_cv_deplibs_check_method=pass_all
;;
-sco3.2v5*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
solaris*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv4 | sysv4.2uw2* | sysv4.3*)
+sysv4 | sysv4.3*)
case $host_vendor in
motorola)
lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB
(shared object|dynamic lib) M[[0-9]][[0-9]]* Version [[0-9]]'
@@ -2354,7 +2365,7 @@
esac
;;
-unixware7* | sysv5*)
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
lt_cv_deplibs_check_method=pass_all
;;
esac
@@ -2600,13 +2615,6 @@
# Check for any special shared library compilation flags.
#
_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)=
-if test "$GCC" = no; then
- case $host_os in
- sco3.2v5*)
-_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)='-belf'
-;;
- esac
-fi
if test -n "$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)"; then
AC_MSG_WARN([`$CC' requires `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to build
shared libraries])
if echo "$old_CC $old_CFLAGS " | grep "[[
]]$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)[[]]" >/dev/null; then :
@@ -3477,19 +3485,6 @@
# FIXME: insert proper C++ library support
_LT_AC_TAGVAR(ld_shlibs, $1)=no
;;
- sco*)
-_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
-case $cc_basename in
- CC*)
- # FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
- ;;
- *)
- # FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
- ;;
-esac
-;;
sunos4*)
case $cc_basename in
CC*)
@@ -3582,27 +3577,48 @@
;;
esac
;;
- sysv5OpenUNIX8* | sysv5UnixWare7.[[01]].[[01]]* | sysv5uw[[78]]* |
unixware7*)
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* |
sco3.2v5.0.[[024]]*)
+_LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+runpath_var='LD_RUN_PATH'
+
case $cc_basename in
CC*)
- _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z ${wl}text'
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h ${wl}$soname -o $lib
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 $
