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
Sync C++ linking on HEAD with branch-1-5
When linking C++ libraries/programs, link with the compiler, not the
linker. Syncs with branch-1-5.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
2005-11-09 Albert Chin-A-Young [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG): Sync C++
linking on HP-UX with branch-1-5. Use C++ compiler for
linking rather than ld.
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.36
diff -u -3 -p -r1.36 libtool.m4
--- libltdl/m4/libtool.m4 7 Nov 2005 18:28:25 - 1.36
+++ libltdl/m4/libtool.m4 9 Nov 2005 16:06:29 -
@@ -5429,7 +5430,7 @@ if test $_lt_caught_CXX_error != yes;
aCC*)
case $host_cpu in
hppa*64*|ia64*)
- _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib
$linker_flags $libobjs $deplibs'
+ _LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o
$lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname
${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs
$postdep_objects $compiler_flags'
@@ -5450,7 +5451,7 @@ if test $_lt_caught_CXX_error != yes;
if test $with_gnu_ld = no; then
case $host_cpu in
ia64*|hppa*64*)
- _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib
$linker_flags $libobjs $deplibs'
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC
${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects
$compiler_flags'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC
${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags'
Re: Sync C++ linking on HEAD with branch-1-5
Hi Albert, * Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET: When linking C++ libraries/programs, link with the compiler, not the linker. Syncs with branch-1-5. Erm, I can't see this in branch-1-5. It's hpux10*|hpux11*, and hppa*64*|ia64*, and aCC|g++, right? Does something fail without the patch (what)? Should I apply it to branch-1-5 as well? Cheers, Ralf
Re: CONFIG_SHELL and `./config.status --recheck'
Hi Paul,
* Paul Eggert wrote on Mon, Nov 07, 2005 at 03:11:26AM CET:
Ralf Wildenhues [EMAIL PROTECTED] writes:
One possibility would be to restart once with /bin/sh, or, if part of
the environment, with CONFIG_SHELL, or, after parsing the command line,
with CONFIG_SHELL, if that is given there. All of this is very slow
(read: dog-slow), and I'd really like to avoid another restart if at all
possible.
I didn't quite follow all that, but don't you have to restart once
anyway, on Solaris, if the user just does ./configure?
Yes.
Can't we figure out before restarting the first time, what should be
in the environment for the second time? Then we'd need only one
restart.
I believe so. In any case I am not discussing the restart that happens
upon manual configure. It's fine. It can be avoided by
CONFIG_SHELL=/good/shell /good/shell configure [...]
I assume you're trying to avoid the need for _two_ restarts, which
is understandable.
Well, yes: I am trying to avoid the need for (two) restarts upon
`./config.status --recheck'-induced reruns of configure.
Current ways only need one restart, but have a bug, as outlined.
Another possibility would be to test for an external echo program first,
I'd rather not do that; it's pretty slow.
ACK.
I believe above could work with two changes: Autoconf should recommend
passing CONFIG_SHELL as environment variable (as opposed to: as option
to configure), so it's available to the shell selection mechanism,
which runs before the argument parsing is done. Also, config.status
should set it for configure reruns. Both are done in the patch below.
Note that _AS_DETECT_BETTER_SHELL itself (which is also expanded before
the argument parsing loop) reads $CONFIG_SHELL as well. I'm not sure
whether it was deliberate that it would not see this variable upon the
recheck.
OTOH, setting CONFIG_SHELL upon `./config.status --recheck' makes a
certain assumption: that the shell does not change. Or, for example,
the PATH, should the user not have used an absolute path as in
CONFIG_SHELL=bash bash configure
I'm not so sure whether this assumption is safe to make; we might want
to discourage non-absolute names.
What do you think? The patch below appears to fix the issue on Solaris.
(Another possibility would be to recheck with /bin/sh and not set
CONFIG_STATUS, iff the user did not set this either (and we can find out
about this reliably); a bit safer.)
Cheers,
Ralf
* lib/autoconf/status.m4 (_AC_OUTPUT_CONFIG_STATUS): Pass
CONFIG_SHELL in the environment of the configure rerun.
* doc/autoconf.texi (Here-Documents, config.status Invocation):
Suggest passing CONFIG_SHELL absolute, and in the environment
rather than as option.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.932
diff -u -r1.932 autoconf.texi
--- doc/autoconf.texi 21 Oct 2005 05:46:50 - 1.932
+++ doc/autoconf.texi 9 Nov 2005 21:18:44 -
@@ -9958,8 +9960,8 @@
version M-12/28/93d, mishandles variable expansion that occurs on
1024-byte buffer boundaries within a here-document. Users can generally
fix these problems by using a faster or more reliable shell, e.g., by
-using the command @samp{bash ./configure CONFIG_SHELL=bash} rather than
-plain @samp{./configure}.
+using the command @samp{CONFIG_SHELL=/bin/bash /bin/bash ./configure} rather
+than plain @samp{./configure}.
Some shells can be extremely inefficient when there are a lot of
here-documents inside a single statement. For instance if your
@@ -14149,9 +14151,9 @@
option. It must be Bourne-compatible. The default is a shell that
supports @code{LINENO} if available, and @file{/bin/sh} otherwise.
Invoking @command{configure} by hand bypasses this setting, so you may
-need to use a command like @samp{/bin/bash ./configure
-CONFIG_SHELL=/bin/bash} to insure that the same shell is used
-everywhere.
+need to use a command like @samp{CONFIG_SHELL=/bin/bash /bin/bash ./configure}
+to insure that the same shell is used everywhere. The absolute name of the
+shell should be passed.
@end defvar
@defvar CONFIG_STATUS
Index: lib/autoconf/status.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/status.m4,v
retrieving revision 1.77
diff -u -r1.77 status.m4
--- lib/autoconf/status.m4 21 Oct 2005 07:36:32 - 1.77
+++ lib/autoconf/status.m4 8 Nov 2005 07:06:21 -
@@ -1256,8 +1261,8 @@
_ACEOF
cat $CONFIG_STATUS _ACEOF
if \$ac_cs_recheck; then
- echo running $SHELL $[0] $ac_configure_args \$ac_configure_extra_args
--no-create --no-recursion AS_MESSAGE_FD
- exec $SHELL $[0] $ac_configure_args \$ac_configure_extra_args --no-create
--no-recursion
+ echo running CONFIG_SHELL=$SHELL $SHELL $[0] $ac_configure_args
\$ac_configure_extra_args --no-create
FYI: (non)recursive mode fixups
Hi Gary, * Gary V. Vaughan wrote on Mon, Nov 07, 2005 at 04:55:16PM CET: Ralf Wildenhues wrote: First the good thing: in principle, libltdl can do fine without an AC_CONFIG_HEADER at all: *snip* Sweet! Along with a patch to libtool.texi that explains to the user how to make sure everything is setup to help the macro run properly, I think this will be a fine commit before the 2.0 alpha... Erm, what do you mean? The nice thing about the patch is that it requires _no_ adjustment by the user. Whether he uses AC_CONFIG_HEADERS or not, libltdl will build in non-subproject mode. Given that this below is fixed.. The dist target currently needs all these files to exist: libltdl/m4/lt~obsolete.m4 libltdl/aclocal.m4 libltdl/configure.ac libltdl/configure libltdl/config-h.in libltdl/Makefile.in libltdl/Makefile.am If I touch them, make distcheck passes. Can you fix this? Then, (non)recursive mode will be really usable! Hmmm. Well the easy fix would be to have libtoolize always dump all of those files into the ltdl directory as it copies things into the parent project. I think that for the sake of the alpha release, this is a good enough workaround. Yuck. Further down the line (maybe before 2.0 final if it turns out to be both easy and non-invasive), I think we need to actually break the dependency on those files. And that will possibly involve more (s)editing of Makefile.inc at libtoolize time... or else moving some of the dist rules out of libltdl/Makefile.inc and back into Makefile.am. I'd like to concentrate my limited time on the release for now... but I don't mind helping someone else write the patch. I'll eventually try this, together with (s)editing of Makefile.inc so it can be used nonrecursively with subdir names other than libltdl/. Meanwhile, I have applied the following to HEAD. Cheers, Ralf * libltdl/Makefile.inc (AM_CPPFLAGS): Do not define HAVE_CONFIG_H. * libltdl/m4/ltdl.m4 (LTDL_INIT): Do not invoke AC_CONFIG_HEADERS ourselves, we can build with or without now. Index: libltdl/Makefile.inc === RCS file: /cvsroot/libtool/libtool/libltdl/Makefile.inc,v retrieving revision 1.1 diff -u -r1.1 Makefile.inc --- libltdl/Makefile.inc26 Oct 2005 10:42:05 - 1.1 +++ libltdl/Makefile.inc9 Nov 2005 21:36:26 - @@ -26,7 +26,7 @@ # -I$(srcdir) is needed for user that built libltdl with a sub-Automake # (not as a sub-package!) using 'nostdinc': -AM_CPPFLAGS += -DHAVE_CONFIG_H -DLT_CONFIG_H='$(LT_CONFIG_H)' \ +AM_CPPFLAGS += -DLT_CONFIG_H='$(LT_CONFIG_H)' \ -DLTDL -I. -I$(srcdir) -Ilibltdl \ -I$(srcdir)/libltdl -I$(srcdir)/libltdl/libltdl AM_LDFLAGS+= -no-undefined Index: libltdl/m4/ltdl.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v retrieving revision 1.23 diff -u -r1.23 ltdl.m4 --- libltdl/m4/ltdl.m4 7 Nov 2005 14:35:35 - 1.23 +++ libltdl/m4/ltdl.m4 9 Nov 2005 21:36:31 - @@ -273,10 +273,10 @@ dnl _LTDL_MODE specific code must be evaluated at least once: _LTDL_MODE_DISPATCH -# In order that ltdl.c can compile, run AC_CONFIG_HEADERS for the user -# if they did not call it themself. This is so that ltdl.h can pick up -# the parent projects config.h file, The first file in AC_CONFIG_HEADERS -# must contain the definitions required by ltdl.c. +# In order that ltdl.c can compile, find out the first AC_CONFIG_HEADERS +# the user used. This is so that ltdl.h can pick up the parent projects +# config.h file, The first file in AC_CONFIG_HEADERS must contain the +# definitions required by ltdl.c. # FIXME: Remove use of undocumented AC_LIST_HEADERS (2.59 compatibility). AC_CONFIG_COMMANDS_PRE([dnl m4_pattern_allow([^LT_CONFIG_H$])dnl @@ -284,11 +284,7 @@ [LT_CONFIG_H=AH_HEADER], [m4_ifset([AC_LIST_HEADERS], [LT_CONFIG_H=`echo AC_LIST_HEADERS | $SED 's,^[[ ]]*,,;s,[[ :]].*$,,'`], - [LT_CONFIG_H=config.h - dnl subproject mode libltdl has its own config.h... - m4_if(_LTDL_MODE, [subproject], - [], - [AC_CONFIG_HEADERS([config.h:config-h.in])])])])]) + [])])]) AC_SUBST([LT_CONFIG_H]) AC_CHECK_HEADERS([memory.h unistd.h dl.h sys/dl.h dld.h mach-o/dyld.h],
FYI: branch-1-5: static flag check
* Ralf Wildenhues wrote on Sun, Nov 06, 2005 at 07:39:15PM CET: * libtool.m4 (AC_LIBTOOL_LANG_C_CONFIG): Move static_flag check.. (AC_LIBTOOL_PROG_COMPILER_PIC): ..here, so that both `lt_prog_compiler_static' have actually been set, and the check is applied to each tag. Applied to branch-1-5. Cheers, Ralf
Re: Sync C++ linking on HEAD with branch-1-5
On Wed, Nov 09, 2005 at 09:51:12PM +0100, Ralf Wildenhues wrote: * Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET: When linking C++ libraries/programs, link with the compiler, not the linker. Syncs with branch-1-5. Erm, I can't see this in branch-1-5. Oops. My fault. It isn't. I was looking at our patched version. It's hpux10*|hpux11*, and hppa*64*|ia64*, and aCC|g++, right? I can vouch for it on hpux11*, hppa*64*, and ia64*, for aCC and g++. We don't have hpux10* to test it on. Does something fail without the patch (what)? Should I apply it to branch-1-5 as well? The recommended way to create shared libraries on HP-UX 11.x with aCC is 'CC -b'. This is a similar change to using 'cc -b' to create shared libraries on HP-UX 11.x rather than ld. Want me to factor out hpux10 like we did for the cc case? -- albert chin ([EMAIL PROTECTED])
Re: Sync C++ linking on HEAD with branch-1-5
On Wed, Nov 09, 2005 at 08:23:05PM -0600, Albert Chin wrote: On Wed, Nov 09, 2005 at 09:51:12PM +0100, Ralf Wildenhues wrote: * Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET: It's hpux10*|hpux11*, and hppa*64*|ia64*, and aCC|g++, right? I can vouch for it on hpux11*, hppa*64*, and ia64*, for aCC and g++. We don't have hpux10* to test it on. Documentation for the old C++ compiler on HP (aCC): http://docs.hp.com/en/1314/options.htm It documents use of '-b' to create a shared library: http://docs.hp.com/en/1314/options.htm#option-b From this documentation: CAUTION: You must use the aCC command to link your HP aC++ programs and libraries. This ensures that all libraries and other files needed by the linker are available. This URL also documents using aCC to create shared libraries: http://docs.hp.com/en/1314/libs.htm#shlib Want me to factor out hpux10 like we did for the cc case? Looks like this is not needed. Actually, looking at my patch, it only changes it for hppa*64, ia64*. aCC, on these platforms, is always the correct method to link shared libraries. -- albert chin ([EMAIL PROTECTED])
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
Nit in func_win32_libid (branch-1.5)
This has been bugging me since we last looked at this piece of code
(2005-09-25) and we didn't take the opportunity to fix it then.
Should be obvious...also needed in ltmain.m4sh of HEAD.
2005-11-09 Charles Wilson [EMAIL PROTECTED]
* ltmain.in (func_win32_libid): use $SED not sed.
--
Chuck
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.94
diff -u -r1.334.2.94 ltmain.in
--- ltmain.in 7 Nov 2005 22:54:24 - 1.334.2.94
+++ ltmain.in 10 Nov 2005 02:54:19 -
@@ -157,7 +157,7 @@
if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null | \
$EGREP -e 'file format pe-i386(.*architecture: i386)?' /dev/null ; then
win32_nmres=`eval $NM -f posix -A $1 | \
- sed -n -e '1,100{/ I /{s,.*,import,;p;q;};}'`
+ $SED -n -e '1,100{/ I /{s,.*,import,;p;q;};}'`
case $win32_nmres in
import*) win32_libid_type=x86 archive import;;
*)win32_libid_type=x86 archive static;;
