Re: patch to correct fallout from freebsd-elf changes
[original post: https://lists.gnu.org/archive/html/libtool-patches/2017-06/msg0.html] With all the flurry of commits I'm hoping this gets included. [And gives me a chance to correct all the embarrassing typos in the body of the original message] Thanks. On Sun, 18 Jun 2017, Tim Rice wrote: > > Here is a small patch to correct builds on svr5. > When the freebsd-elf target was changed, this got missed. > > Symptoms were, building newer lib ended up with libfoo.nn a lower number > than the previous version. And building libpng-1.6.29 produced > libtool: error: CURRENT '' must be a nonnegative integer > libtool: error: '16:29:0' is not valid version information > > Patch attached and inline here. > > diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in > index bbc7643..d3ee94f 100644 > --- a/build-aux/ltmain.in > +++ b/build-aux/ltmain.in > @@ -6919,7 +6919,7 @@ func_mode_link () > age=$number_minor > revision=$number_revision > ;; > - freebsd-aout|qnx|sunos) > + freebsd-aout|qnx|sco|sunos) > current=$number_major > revision=$number_minor > age=0 > > -- Tim RiceMultitalents t...@multitalents.net diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index bbc7643..d3ee94f 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -6919,7 +6919,7 @@ func_mode_link () age=$number_minor revision=$number_revision ;; - freebsd-aout|qnx|sunos) + freebsd-aout|qnx|sco|sunos) current=$number_major revision=$number_minor age=0
Re: Passing LD_RUN_PATH through to the linker
af0 > 0x000e (SONAME) Library soname: > [/usr/local/lib/libssh2.so.1] > 0x001d (RUNPATH)Library runpath: [/usr/local/lib] > 0x0004 (HASH) 0xc0 > 0x0005 (STRTAB) 0x5498 > 0x0006 (SYMTAB) 0x1408 > 0x000a (STRSZ) 18886 (bytes) > 0x000b (SYMENT) 16 (bytes) > 0x0016 (TEXTREL)0x0 > 0x0003 (PLTGOT) 0x4ec2c > 0x0002 (PLTRELSZ) 40 (bytes) > 0x0014 (PLTREL) REL > 0x0017 (JMPREL) 0xfb18 > 0x0011 (REL)0x9e60 > 0x0012 (RELSZ) 23736 (bytes) > 0x0013 (RELENT) 8 (bytes) > 0x (NULL) 0x0 > > I'm assuming there must be something else different in the way we build. Which development system are you using? OpenServer 5.0..7 had 3 different ones available. OpenServer 5 Definitive 2018 has 4. The latest being a GCC 4.2.4 and friends. > > Regards, > Kevin R. Bulgrien > -- Tim RiceMultitalents t...@multitalents.net
Re: Passing LD_RUN_PATH through to the linker
Kevin,
On Wed, 14 Dec 2022, Kevin R. Bulgrien wrote:
> During attempts to build top-of-tree libssh2 on a dinosaur (SCO OpenServer
> 5.0.7),
> an issue with loading indirect dependencies of libssh2.so is occurring. They
> can
> be worked around by setting LD_LIBRARY_PATH at run-time, however it seems much
> simpler to depend on DT_RPATH so the run-time environment does not require
> management.
>
> The linker behaves as defined at the link following (ironically, more
> completely
> documented on this list than in the official documentation):
>
> https://lists.gnu.org/archive/html/bug-libtool/2002-08/msg00026.html
>
[snip]
>
> Can anyone offer a pointer on where to look in autotools/libtool structure
> to get DT_RPATH set in the linked binaries or comment on whether this is
> even an option with libtool? I'm finding difficulty differentiating
> between -R and -rpath for libtool versus similar switches for ld.
On OpenServer, I usually just build with the SONAME being a full path name.
I am attaching a patch to the libtool 2.4.6 generated during
a libssh2-1.8.0 build.
Once all testing is complete, I do
..
rm src/libssh2.la
SCOABSPATH=1 ; export SCOABSPATH
gmake 2>&1 | tee x.log
..
then package.
Note: the last hunk is to address a regression introduced in 2.4.6
with the freebsd reorg.
--
Tim RiceMultitalents
t...@multitalents.net
--- libtool.old 2022-12-15 13:35:00.869441000 +
+++ libtool 2022-12-15 13:38:25.699441000 +
@@ -359,8 +359,8 @@
old_archive_from_expsyms_cmds=""
# Commands used to build a shared archive.
-archive_cmds="\$CC -G \$wl-h,\$soname -o \$lib \$libobjs \$deplibs
\$compiler_flags"
-archive_expsym_cmds="\$CC -G \$wl-Bexport:\$export_symbols \$wl-h,\$soname -o
\$lib \$libobjs \$deplibs \$compiler_flags"
+archive_cmds="\$CC -G \${wl}-h,\\\${SCOABSPATH:+\${install_libdir}/}\$soname
-o \$lib \$libobjs \$deplibs \$compiler_flags"
+archive_expsym_cmds="\$CC -G \${wl}-Bexport:\$export_symbols
\${wl}-h,\\\${SCOABSPATH:+\${install_libdir}/}\$soname -o \$lib \$libobjs
\$deplibs \$compiler_flags"
# Commands used to build a loadable module if different from building
# a shared archive.
@@ -378,7 +378,7 @@
# Flag to hardcode $libdir into a binary during linking.
# This must work even if $libdir does not exist
-hardcode_libdir_flag_spec="\$wl-R,\$libdir"
+hardcode_libdir_flag_spec="\`test -z \"\$SCOABSPATH\" && echo -R\$libdir | sed
's|-R/opt/xinuos/lib | |'\`"
# Whether we need a single "-rpath" flag with a separated argument.
hardcode_libdir_separator=":"
@@ -7552,6 +7552,7 @@
;;
-module)
+ unset SCOABSPATH
module=yes
continue
;;
@@ -9314,7 +9315,7 @@
age=$number_minor
revision=$number_revision
;;
- freebsd-aout|qnx|sunos)
+ freebsd-aout|qnx|sco|sunos)
current=$number_major
revision=$number_minor
age=0
Re: [PATCH 1/3] libtool.m4: augment symcode for Solaris 11
On Mon, 19 Jul 2021, Nick Alcock wrote: > This reports common symbols like GNU nm, via a type code of 'C'. > > * m4/libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for > Solaris 11. > > Signed-off-by: Nick Alcock > --- > m4/libtool.m4 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/m4/libtool.m4 b/m4/libtool.m4 > index a3bc337b..2851b204 100644 > --- a/m4/libtool.m4 > +++ b/m4/libtool.m4 > @@ -3931,7 +3931,7 @@ osf*) >symcode='[[BCDEGQRST]]' >;; > solaris*) > - symcode='[[BDRT]]' > + symcode='[[BCDRT]]' Will this change work on previous releases of Solaris? >;; > sco3.2v5*) >symcode='[[DT]]' > -- Tim Rice t...@multitalents.net
Re: Are *.la files supposed to be executable?
Hi Jeff, On Sat, 9 Jan 2021, Jeffrey Walton wrote: > Hi Everyone, > > I'm auditing $prefix for ownership and permissions. I noticed *.la > files are executable: > > $ ls -Al /usr/local/lib/libgettextlib.la > -rwxr-xr-x 1 root root 1078 Jan 8 15:58 /usr/local/lib/libgettextlib.la [snip] > Are the *.la files supposed to be executable? Since libtool sources the .la files, they do not need to be executable. You will see a mix of executable and non-executable in various distos. My packaging scripts do a chmod 644 on them. > Jeff > -- Tim RiceMultitalents t...@multitalents.net
patch to correct fallout from freebsd-elf changes
Here is a small patch to correct builds on svr5. When the freebsd-elf target was changed, this got missed. Symptoms were, build newer lib ened up with libfo.nn a loser number than the previous version. And building libpng-1.6.29 produced libtool: error: CURRENT '' must be a nonnegative integer libtool: error: '16:29:0' is not valid version information Patch attached and inline here. diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index bbc7643..d3ee94f 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -6919,7 +6919,7 @@ func_mode_link () age=$number_minor revision=$number_revision ;; - freebsd-aout|qnx|sunos) + freebsd-aout|qnx|sco|sunos) current=$number_major revision=$number_minor age=0 -- Tim RiceMultitalents(707) 456-1146 t...@multitalents.net diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index bbc7643..d3ee94f 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -6919,7 +6919,7 @@ func_mode_link () age=$number_minor revision=$number_revision ;; - freebsd-aout|qnx|sunos) + freebsd-aout|qnx|sco|sunos) current=$number_major revision=$number_minor age=0
Re: libtool-2.4.2.418 released [alpha]
Hi Gary and Tim, On Wed, 6 Nov 2013, Gary V. Vaughan wrote: | Hi Tim, | | On 6 Nov 2013, at 11:20, Tim Mooney tim.moo...@ndsu.edu wrote: | The Libtool Team is pleased to announce the release of libtool 2.4.2.418. | | This is a preliminary alpha release to begin platform testing in | preparation for the next stable release. | | I built 2.4.2.418 on x86_64-pc-solaris2.11 (OpenIndiana 151a8) with | the Oracle Studio 12.3 toolchain. There was one unexpected failure | in the new test suite: | | 21: quote shell meta-characters in filenamesFAILED (libtool.at:120) | | Yes, I'm seeing this failure on quite a few of my test architectures too, but | haven't been able to get to the bottom of it. If you have any insight, I'd be | very happy to hear about it. Gary, in bug#15734 you sugested it was a problem with grep. On my UnixWare box, I tested with a GNU grep first in the path and #21 did not fail. Now, which part is tripping up the system grep and what to do about it, I do not know. ;-) -- Tim RiceMultitalents(707) 456-1146 t...@multitalents.net ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool, llvm-gcc, failing C++ exceptions
On Tue, 12 Jan 2010, Bob Friesenhahn wrote: On Tue, 12 Jan 2010, Ralf Wildenhues wrote: OTOH, pre-standard C++ compilers are definitely a concern for testing. I usually do pre-release testing on a couple of systems that have fairly old and non-standard C++ compilers (no namespaces etc). I don't want to see errors stemming from this. I have not encountered such a limited C++ compiler for at least 12 years, including on archaic systems. Just be aware that there are currently shipping systems based on a product first released in 1992. I'm refering to OpenServer 5.0.7. Its native C++ compiler uses an old ATT Cfront front end to the C compiler. -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net
Re: [PATCH] Enable runtime cwrapper debugging; add tests
Hi Chuck, On Tue, 15 Dec 2009, Charles Wilson wrote: On Mon, 14 Dec 2009 15:06 -0800, Tim Rice wrote: I would strongly advocate testing at least one System V based system. Non bash shells sometimes have issues. During the release process, certainly testing on as many supported platforms as possible is baked into the cake. *Perhaps*, by a reviewer or other list denizen, before a particular patch is pushed. But it's unreasonable to *require* every contributor to have access to multiple platforms. Some folks who fix HP-UX might not have (or want to install) cygwin on a win32 box. Or a mingw developer might not have any access to a Solaris machine. I have access to cygwin, mingw, and linux. I don't have access to SysV, and it would be setting WAY too high a bar for contributions to say No, thanks, we don't want your patches because you can't test them on System Foo. I did not mean to imply that it should be required. It's just a whole lot easier to keep non portable shell/awk/sed code from slipping through if tested on SysV. -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net
Re: libtool, OS X, and GNU ranlib
On Thu, 1 Oct 2009, Bob Friesenhahn wrote: Excuse this top-post. I continue to believe that this user error should be explicitly prevented (by a hard configure error) and that very few people will notice a warning message while configure is running. Warn on darwin if install will overwrite /usr/bin/libtool * configure.ac: Add warning. I would wonder why /usr/bin/libtool is writable by a user. Or why one would build software as root. I can't remember the last time I had to build a package as root. *nix has a long history of allowing someone to shoot themselves in the foot so to speak. So if it needs anything, a warning should be sufficient. -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net
Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
On Thu, 13 Aug 2009, Dave Korn wrote: Re that, BTW: can I use shell array variables portably? I'm guessing not, but it would simplify the design slightly if there was a way. No, array variables are not portable. -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net
Re: cmdline_wrap.at
[ droping libtool@ from replies ]
Hi John, Ralf
On Sun, 1 Mar 2009, John Wolfe wrote:
Hi Ralf, Tim
Here I am playing catch up again.
At first look at the patch I have one concern and that may be what is
contributing to
the failures later reported in this thread.
- In the patch, I think the $CC -r should be $LD -r
Using the C++ compiler command to do the linking does not work! It will
begin to suck in
multiple copies of C++ startup runtime routines as you loop through the
link.
I wondered about that. Switching to $LD did the trick.
.
79 tests behaved as expected.
7 tests were skipped.
.
So after the minor change to Ralf's patch here is what we end up with.
- ChangeLog -
2009-02-28 Ralf Wildenhues ralf.wildenh...@gmx.de
Fix low max_cmd_len template test on UnixWare.
* libltdl/config/ltmain.m4sh (func_mode_link): When expanding
$reload_cmds, always put objects in $reload_objs rather than
adding them to the command line, to allow more general command
lines in reload_cmds. Ensure $reload_objs contains a leading
space.
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [sysv5*,
sco3.2v5*, sco5v6*] reload_cmds: For CC, invoke prelinker
before creating reloadable object.
(_LT_CMD_RELOAD) reload_cmds, reload_flag: Declare as
_LT_TAGDECL, not _LC_DECL.
(_LT_LANG_CXX_CONFIG, _LT_LANG_F77_CONFIG, _LT_LANG_FC_CONFIG)
(_LT_LANG_GCJ_CONFIG) reload_cmds, reload_flag: Initialize
from default (C tag) value.
* THANKS: Update.
Report and analysis by Tim Rice and John Wolfe.
- Begin patch -
--- libtool-2.x/libltdl/config/ltmain.m4sh.old 2009-02-28 10:00:56.0
-0800
+++ libtool-2.x/libltdl/config/ltmain.m4sh 2009-02-28 12:30:33.696970038
-0800
@@ -6923,17 +6923,19 @@
# command to the queue.
if test $k -eq 1 ; then
# The first file doesn't have a previous command to add.
- eval concat_cmds=\$reload_cmds $objlist $last_robj\
+ reload_objs=$objlist
+ eval concat_cmds=\$reload_cmds\
else
# All subsequent reloadable object files will link in
# the last one created.
- eval concat_cmds=\\$concat_cmds~$reload_cmds $objlist
$last_robj~\$RM $last_robj\
+ reload_objs=$objlist $last_robj
+ eval concat_cmds=\\$concat_cmds~$reload_cmds~\$RM
$last_robj\
fi
last_robj=$output_objdir/$output_la-${k}.$objext
func_arith $k + 1
k=$func_arith_result
output=$output_objdir/$output_la-${k}.$objext
- objlist=$obj
+ objlist= $obj
func_len $last_robj
func_arith $len0 + $func_len_result
len=$func_arith_result
@@ -6943,7 +6945,8 @@
# reloadable object file. All subsequent reloadable object
# files will link in the last one created.
test -z $concat_cmds || concat_cmds=$concat_cmds~
- eval concat_cmds=\\${concat_cmds}$reload_cmds $objlist
$last_robj\
+ reload_objs=$objlist $last_robj
+ eval concat_cmds=\\${concat_cmds}$reload_cmds\
if test -n $last_robj; then
eval concat_cmds=\\${concat_cmds}~\$RM $last_robj\
fi
--- libtool-2.x/libltdl/m4/libtool.m4.old 2009-02-28 10:00:56.0
-0800
+++ libtool-2.x/libltdl/m4/libtool.m4 2009-03-01 13:49:53.289834138 -0800
@@ -2888,8 +2888,8 @@
fi
;;
esac
-_LT_DECL([], [reload_flag], [1], [How to create reloadable object files])dnl
-_LT_DECL([], [reload_cmds], [2])dnl
+_LT_TAGDECL([], [reload_flag], [1], [How to create reloadable object files])dnl
+_LT_TAGDECL([], [reload_cmds], [2])dnl
])# _LT_CMD_RELOAD
@@ -5314,6 +5314,8 @@
_LT_TAGVAR(module_expsym_cmds, $1)=
_LT_TAGVAR(link_all_deplibs, $1)=unknown
_LT_TAGVAR(old_archive_cmds, $1)=$old_archive_cmds
+_LT_TAGVAR(reload_flag, $1)=$reload_flag
+_LT_TAGVAR(reload_cmds, $1)=$reload_cmds
_LT_TAGVAR(no_undefined_flag, $1)=
_LT_TAGVAR(whole_archive_flag_spec, $1)=
_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=no
@@ -6221,6 +6223,7 @@
_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G
${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs
$compiler_flags'
_LT_TAGVAR(old_archive_cmds, $1)='$CC -Tprelink_objects $oldobjs~
'$_LT_TAGVAR(old_archive_cmds, $1)
+ _LT_TAGVAR(reload_cmds, $1)='$CC -Tprelink_objects $reload_objs~$LD
-r -o $output$reload_objs'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib
$libobjs
Re: cmdline_wrap.at
Hi Ralf, On Sat, 28 Feb 2009, Ralf Wildenhues wrote: [snip] Is this an optimization only, or a necessary thing? IOW, if I omit libfoo-1.0 in this CC -Tprelink_objects line, would that only pessimize link time, or could it affect the link result? I'll let John answer this Anyway, I think the patch below should implement this (and add John to THANKS). Can you try it? Thanks. The test still fails although the patch could be correct. It looks like this never makes it into the generated libtool. + _LT_TAGVAR(reload_cmds, $1)='$CC -Tprelink_objects $reload_objs~$CC -r -o $output$reload_objs' . t...@server01-unixware 132% grep Tprelink libtool old_archive_cmds=\$CC -Tprelink_objects \$oldobjs~ . In fact there is no reload_cmds= in the TAG CONFIG: CXX section . t...@server01-unixware 133% grep -n ^reload_cmds= libtool 123:reload_cmds=\$LD\$reload_flag -o \$output\$reload_objs t...@server01-unixware 134% grep -n CONFIG: CXX libtool 9097:# ### BEGIN LIBTOOL TAG CONFIG: CXX 9245:# ### END LIBTOOL TAG CONFIG: CXX . -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net
Re: cmdline_wrap.at
Hi Ralf, On Sat, 28 Feb 2009, Ralf Wildenhues wrote: [snip] Is this an optimization only, or a necessary thing? IOW, if I omit libfoo-1.0 in this CC -Tprelink_objects line, would that only pessimize link time, or could it affect the link result? I'll let John answer this Anyway, I think the patch below should implement this (and add John to THANKS). Can you try it? Thanks. The test still fails although the patch could be correct. It looks like this never makes it into the generated libtool. + _LT_TAGVAR(reload_cmds, $1)='$CC -Tprelink_objects $reload_objs~$CC -r -o $output$reload_objs' . t...@server01-unixware 132% grep Tprelink libtool old_archive_cmds=\$CC -Tprelink_objects \$oldobjs~ . In fact there is no reload_cmds= in the TAG CONFIG: CXX section . t...@server01-unixware 133% grep -n ^reload_cmds= libtool 123:reload_cmds=\$LD\$reload_flag -o \$output\$reload_objs t...@server01-unixware 134% grep -n CONFIG: CXX libtool 9097:# ### BEGIN LIBTOOL TAG CONFIG: CXX 9245:# ### END LIBTOOL TAG CONFIG: CXX . -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cmdline_wrap.at
Hi Ralf, On Wed, 25 Feb 2009, Ralf Wildenhues wrote: : Hi Tim, : : * Tim Rice wrote on Mon, Feb 23, 2009 at 10:47:49PM CET: : On Sat, 21 Feb 2009, Ralf Wildenhues wrote: : * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET: : :I'm trying to understand the cmdline_wrap.at test. :I've added this patch to fix the 2 template tests that were failing :on UnixWare 7.1.4 : : Can you post the verbose output of the test both without and with the : patch? Thanks. : gmake check-local TESTSUITEFLAGS='-k simple template test -v -d -x' : : Sure, attched as x.tst-without-patch x.tst-with-patch : I've also attached the curent patch I'm using as uw-template.patch : It's just a s/CXX/CC/ of the old one. : : How come there is no ranlib step in old_archive_cmds? Simple, there is no ranlib on UnixWare. : Otherwise, if it causes no other testsuite regressions, it looks good to : me. No other regressions. : How long is the actual command line length limit on your system? : If it is 1MB or unlimited, then this is unlikely to ever be a problem : in practice, and you can ignore the failure. But some systems have : pretty low limits. : : On my system it is 131072 but it is a kernel tunable and the default : out of the box is 32k. : : That's too low for some packages. Indeed, but it can be tuned as high as 1048576. : The output of the failing/passing of the test above may help analyze the : failure of the cmdline_wrap test. : : John Wolfe was looking at this too (using 2.2.6) and here is what : he had to say : -- : I know why test 73 (small command line) test fails on #62 (C++ : templates). : : - one of the link lines (second) linking against a .la, gets : broken up and .o's are collected in a relocatable object using. : : /bin/ld -r : : Ergo the problem, the prelink phase is skipped. It is not a : problem with the archive being built, since $AR can accumulate : object files, 1 file at a time. : So the CC -Tprelink_objects is accomplished as expected - just : before the $AR. : The prelinker command echo can be seen in the log. : : For shared objects, what is needed is to get a CC -Tprelink_objects : done on the libobjs before they are added to the relocatable object. : : Can you show how it would need to work? If libtool reloads : a.o b.o c.o - libfoo-1.o : d.o e.o f.o libfoo-1.o - libfoo-2.o : and links : g.o libfoo-2.o - libfoo.la : : then which objects does CC -Tprelink_objects need to be run on? Maybe we can get John to comment on this one. He knows the C++ compile much better than I do. : The /bin/ld cannot be replaced with $CC since the C++ compiler : driver will link in startup modules also. Soon get a multiple : defined symbol. : : Yes. : : Thanks, : Ralf -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net ___ http://lists.gnu.org/mailman/listinfo/libtool
SCOABSPATH in 2.x
I noticed that the SCOABSPATH bits are in aclocal.m4 on 2.2.6 and was wondering how they got there since the corresponding changes to libltdl/m4/libtool.m4 were intentionally not forward ported from the 1.5 branch. -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cmdline_wrap.at
Hi Ralf,
On Sat, 21 Feb 2009, Ralf Wildenhues wrote:
Hi Tim,
* Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET:
I'm trying to understand the cmdline_wrap.at test.
I've added this patch to fix the 2 template tests that were failing
on UnixWare 7.1.4
Can you post the verbose output of the test both without and with the
patch? Thanks.
gmake check-local TESTSUITEFLAGS='-k simple template test -v -d -x'
Sure, attched as x.tst-without-patch x.tst-with-patch
I've also attached the curent patch I'm using as uw-template.patch
It's just a s/CXX/CC/ of the old one.
so now the only failure is the low max_cmd_len test.
OK, cool.
I guess I don't really know what cmdline_wrap.at is trying to acomplish.
And I'm puzzled why the simple template test fails inside cmdline_wrap
but not outside of it.
Well, it tries to simulate a very long command line, so long that its
expansion by libtool will exceed the kernel command line length limit.
It does this by setting the limit very low, which libtool internally
compares against. So then the wrapping code branches are exercised,
which create intermediate libraries or objects.
How long is the actual command line length limit on your system?
If it is 1MB or unlimited, then this is unlikely to ever be a problem
in practice, and you can ignore the failure. But some systems have
pretty low limits.
On my system it is 131072 but it is a kernel tunable and the default
out of the box is 32k.
The test case tries to re-run all kinds of other tests in our testsuite
(exactly those that only exercise the $LIBTOOL script), for best
possible code coverage.
The output of the failing/passing of the test above may help analyze the
failure of the cmdline_wrap test.
John Wolfe was looking at this too (using 2.2.6) and here is what
he had to say
--
I know why test 73 (small command line) test fails on #62 (C++
templates).
- one of the link lines (second) linking against a .la, gets
broken up and .o's are collected in a relocatable object using.
/bin/ld -r
Ergo the problem, the prelink phase is skipped. It is not a
problem with the archive being built, since $AR can accumulate
object files, 1 file at a time.
So the CC -Tprelink_objects is accomplished as expected - just
before the $AR.
The prelinker command echo can be seen in the log.
For shared objects, what is needed is to get a CC -Tprelink_objects
done on the libobjs before they are added to the relocatable object.
The /bin/ld cannot be replaced with $CC since the C++ compiler
driver will link in startup modules also. Soon get a multiple
defined symbol.
--
Thanks.
Thanks!
Ralf
--
Tim RiceMultitalents(707) 887-1469
t...@multitalents.net--- libltdl/m4/libtool.m4.old 2009-02-18 18:54:38.0 -0800
+++ libltdl/m4/libtool.m4 2009-02-22 20:54:26.786787091 -0800
@@ -6219,6 +6219,8 @@
CC*)
_LT_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib
$libobjs $deplibs $compiler_flags'
_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G
${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs
$compiler_flags'
+ _LT_TAGVAR(old_archive_cmds, $1)='$CC -Tprelink_objects $oldobjs~
+ $AR $AR_FLAGS $oldlib$oldobjs$old_deplibs'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib
$libobjs $deplibs $compiler_flags'
abs_srcdir=`CDPATH=${ZSH_VERSION+.}: cd /home2/src/gnu/libtool-2.x
pwd`; cd tests; \
CONFIG_SHELL=/bin/ksh /bin/ksh $abs_srcdir/tests/testsuite \
MAKE=gmake CC=cc CFLAGS=-g CPP=cc -E CPPFLAGS= LD=/usr/bin/ld
LDFLAGS= LIBS= LN_S=ln -s NM=/usr/bin/nm -p RANLIB=: STRIP=strip
lt_INSTALL=/home2/src/gnu/libtool-2.x/libltdl/config/install-sh -c OBJEXT=o
EXEEXT= SHELL=/bin/ksh CONFIG_SHELL=/bin/ksh CXX=CC CXXFLAGS=-g
CXXCPP=CC -E F77= FFLAGS= FC= FCFLAGS= GCJ= GCJFLAGS=-g -O2
_lt_pkgdatadir=/home2/src/gnu/libtool-2.x
LIBTOOLIZE=/usr/local/src/gnu/libtool-2.x/libtoolize
LIBTOOL=/usr/local/src/gnu/libtool-2.x/libtool
tst_aclocaldir=/home2/src/gnu/libtool-2.x/libltdl/m4 -k simple template
test -v -d -x
## -- ##
## libtool 2.2.7a test suite. ##
## -- ##
73. template.at:27: testing ...
/home2/src/gnu/libtool-2.x/tests/template.at:28: { test -n $CXX test
X$CXX != Xno; } || (exit 77)
+ test -n CC
+ test XCC != Xno
/home2/src/gnu/libtool-2.x/tests/template.at:28: test X$CXX != Xg++ || (g++
-v /dev/null 21) || (exit 77)
+ test XCC != Xg++
+ cat
+ 1 aclib.h 0
+ cat
+ 1 aclib.cpp 0
+ cat
+ 1 alib.h 0
+ cat
+ 1 alib.cpp 0
+ cat
+ 1 prog.cpp 0
/home2/src/gnu/libtool-2.x/tests/template.at:79: $LIBTOOL --tag=CXX
--mode=compile $CXX -I. $CPPFLAGS $CXXFLAGS -c -o alib.lo alib.cpp
+ /usr/local/src/gnu/libtool-2.x/libtool --tag=CXX --mode=compile CC -I. -g -c
-o
Re: spaces
On Thu, 22 Jan 2009, Peter Rosin wrote: Den 2009-01-21 23:13, skrev Ralf Wildenhues: * Charles Wilson wrote on Tue, Jan 20, 2009 at 07:29:52PM CET: Bob Friesenhahn wrote: For many years I have had my editor configured to always use spaces. This ensures WYSIWYG for everyone involved. Agree 100%. I try to manually match whatever sp/tab convention is in place -- using vi if I have to -- but much prefer all spaces. OK so it seems there are more voices for spaces. Or maybe it just seems so because those that want a change are those that will speak up. I prefer tabs. If I want the text in the 25th column it's just 3 tab keys and start typing. I don't have to count out pressing the space bar 24 times and then wondering if it really was 24. I find python code really annoying because it is spaces only. But then again, maybe I don't count. After all, I'm not a large contributor to libtool. Can we agree to make the switch only after 2.2.8 though, I would like to avoid unnecessary churn ATM. I have no strong preference regarding indentation, except that if the msvc branch is to be merged soon after 2.2.8, I'd much prefer to do it before any extensive whitespace cleanup. Cheers, Peter -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net
minumum ver of m4?
Is there a miniumum version of m4 to build/test libtool-2.2.6 and later? Thanks. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Solaris 10 w/ SunStudio 11 64bit mode
Hi Ralf, On Mon, 11 Feb 2008, Ralf Wildenhues wrote: * Tim Rice wrote on Mon, Feb 11, 2008 at 06:23:59AM CET: CVS HEAD pulled Fri Feb 8 17:52:22 PST 2008 Solaris 10 w/ SunStudio 11 I'm seeing failures in 64 bit mode I don't see in 32 bit mode with compiler options that woked for me in both 32 64 on branch-1.5. testsuite.log-64.gz attached. Please try again, with making the f95 compiler generate 64bit code: FCFLAGS=-xtarget=ultra -xarch=v9 assuming those are the right options. $FFLAGS is for $F77, $FCFLAGS is for $FC, and needed in this case. (Libtool currently doesn't support having two different-language compilers do different ABIs.) I didn't expect it to work with diifferent ABIs I thought I had what I needed with FFLAGS=-xtarget=ultra -xarch=v9 Thanks for the FCFLAGS tip, that worked. Tests pass now. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: CVS HEAD test 30
On Sun, 10 Feb 2008, Ralf Wildenhues wrote: [ cutting libtool-patches ] Hi Tim, * Tim Rice wrote on Sun, Feb 10, 2008 at 12:05:33AM CET: Now only 54, 55 and of course 64 (because 54 55 fail) fail on UnixWare 7.1.4. There is still some work needed on templates on UnixWare but nothing that should hold up this release. Was that because of this rule and the compiler not understanding -c -o? No that's only a problem with UnixWare 2.x native compilers | cpp.o: | $(CXXCOMPILE) -c -o $@ $ Otherwise, I don't have a report for this on my radar, so I'd appreciate if you could post the testsuite.log for the failures. testsuite.log.gz attached. The thread started in libtool on Wed, 28 Sep 2005 with the Subject: forward porting UnixWare fixes to HEAD and on Fri, 11 Nov 2005 you moved it to libtool-patches, same subject. Basicly I have not semt any time to get those tests working. Thanks, also for confirming the other fix, Ralf -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] testsuite.log.gz Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
Solaris 10 w/ SunStudio 11 64bit mode
CVS HEAD pulled Fri Feb 8 17:52:22 PST 2008 Solaris 10 w/ SunStudio 11 I'm seeing failures in 64 bit mode I don't see in 32 bit mode with compiler options that woked for me in both 32 64 on branch-1.5. testsuite.log-64.gz attached. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] testsuite.log-64.gz Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: CVS HEAD test 30
On Fri, 8 Feb 2008, Ralf Wildenhues wrote: * Tim Rice wrote on Fri, Feb 08, 2008 at 03:00:05AM CET: I'm getting an UNEXPECTED PASS on test 30 of the new test suite on my UnixWare 7.1.4 box. Thanks for the bug report. I've installed this patch. 2008-02-08 Ralf Wildenhues [EMAIL PROTECTED] * tests/archive-in-archive.at Thanks Ralf, that worked. Now only 54, 55 and of course 64 (because 54 55 fail) fail on UnixWare 7.1.4. There is still some work needed on templates on UnixWare but nothing that should hold up this release. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: CVS HEAD test 30
On Fri, 8 Feb 2008, Ralf Wildenhues wrote: * Tim Rice wrote on Fri, Feb 08, 2008 at 03:00:05AM CET: I'm getting an UNEXPECTED PASS on test 30 of the new test suite on my UnixWare 7.1.4 box. Thanks for the bug report. I've installed this patch. 2008-02-08 Ralf Wildenhues [EMAIL PROTECTED] * tests/archive-in-archive.at Thanks Ralf, that worked. Now only 54, 55 and of course 64 (because 54 55 fail) fail on UnixWare 7.1.4. There is still some work needed on templates on UnixWare but nothing that should hold up this release. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
CVS HEAD test 30
I'm getting an UNEXPECTED PASS on test 30 of the new test suite on my UnixWare 7.1.4 box. A testlog generated with gmake check-local TESTSUITEFLAGS='-d -x 30' is attached. I don't seem to understand the new test suite well enough to figure this out. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]# -*- compilation -*- 30. archive-in-archive.at:26: testing ... + cat + 1 foo.c 0 + cat + 1 bar.c 0 + cd . + pwd + thisdir=/usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 + /usr/local/src/gnu/libtool-2.x/libtool --mode=compile --tag=CC cc -g -c -o foo.lo foo.c libtool: compile: cc -g -c foo.c -KPIC -DPIC -o .libs/foo.o libtool: compile: cc -g -c foo.c -o foo.o /dev/null 21 + /usr/local/src/gnu/libtool-2.x/libtool --mode=compile --tag=CC cc -g -c -o bar.lo bar.c libtool: compile: cc -g -c bar.c -KPIC -DPIC -o .libs/bar.o libtool: compile: cc -g -c bar.c -o bar.o /dev/null 21 + /usr/local/src/gnu/libtool-2.x/libtool --mode=link --tag=CC --tag=disable-shared cc -g -o libfoo.la foo.lo -version-info 1:0:0 -rpath /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 libtool: link: ar cru .libs/libfoo.a foo.o libtool: link: : .libs/libfoo.a libtool: link: ( cd .libs rm -f libfoo.la ln -s ../libfoo.la libfoo.la ) + /usr/local/src/gnu/libtool-2.x/libtool --mode=install cp libfoo.la /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 libtool: install: cp .libs/libfoo.lai /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.la libtool: install: cp .libs/libfoo.a /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.a libtool: install: chmod 644 /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.a libtool: install: : /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30/libfoo.a -- Libraries have been installed in: /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-R,LIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- + /usr/local/src/gnu/libtool-2.x/libtool --mode=link --tag=CC --tag=disable-shared cc -g -o libbar.la bar.lo ./libfoo.a -version-info 1:0:0 -rpath /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 *** Warning: Linking the shared library libbar.la against the *** static library ./libfoo.a is not portable! libtool: link: ar cru .libs/libbar.a ./libfoo.a bar.o UX:ar: ERROR: ./libfoo.a is in archive format - embedded archives are not allowed + /usr/local/src/gnu/libtool-2.x/libtool --mode=install cp libbar.la /usr/local/src/gnu/libtool-2.x/tests/testsuite.dir/30 libtool: install: `libbar.la' is not a valid libtool archive libtool: install: Try `libtool --help --mode=install' for more information. /opt/src/gnu/libtool-2.x/tests/archive-in-archive.at:48: ar -t libbar.a | grep libfoo.a + grep libfoo.a + ar -t libbar.a stderr: UX:ar: ERROR: Archive libbar.a not found stdout: + ar -t libbar.a UX:ar: ERROR: Archive libbar.a not found + archive_contents='' 30. archive-in-archive.at:26: 30. static library contains static library (archive-in-archive.at:26): UNEXPECTED PASS(sys0m0.23s) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI backport notes.texi from HEAD
On Thu, 24 Jan 2008, Ralf Wildenhues wrote: Hi Peter, * Peter O'Gorman wrote on Thu, Jan 24, 2008 at 08:29:08AM CET: I applied this to branch-1-5. Guess that makes the section in README obsolete. Wanna kill it or replace it with a pointer to notes.texi? Keep in mind not all systems have texinfo installed. Although duplication is a pain to keep in sync. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: FYI backport notes.texi from HEAD
On Thu, 24 Jan 2008, Ralf Wildenhues wrote: It will also be in the libtool manual on www.gnu.org (which the README is not), so I am not really worried about that. At least with Libtool HEAD, there is a notes.txt generated from notes.texi. Excelent! Difficult to do in branch-1-5? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: Building CVS HEAD libtool outside of source directory
On Thu, 18 Oct 2007, Ralf Wildenhues wrote: Hello Bob, * Bob Friesenhahn wrote on Thu, Oct 18, 2007 at 12:21:45AM CEST: I suspect that not many libtool developers use the VPATH build. Gary's commit script does not seem to support it. I almost exclusively do VPATH builds for the software that I test, one build tree per host, from a common NFS tree. Is your common NFS tree read only? That will expose some weaknesses in the way some VPATH builds are set up. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: Libtool 1.5.23b
On Sun, 18 Feb 2007, Ralf Wildenhues wrote: Hello Tim, Tim Rice writes: Should a single libtool handle both 32bit 64bit builds on Solaris with Sun Studio 11? No. [snip] Also please note the multilib fixes that are new in 1.5.23b are specific to GCC. OK, I'll continue to build 2 versions of libtool. Thanks. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool 1.5.23b
Should a single libtool handle both 32bit 64bit builds on Solaris
with Sun Studio 11?
I tried using it to build libiconv-1.10 and got
.
cd src gmake all
gmake[1]: Entering directory `/usr/local/src/gnu/libiconv-1.10/src'
/bin/sh ../libtool --mode=link cc -L/opt/lib/64 iconv_no_i18n.o ../srclib/libicr
t.a ../lib/libiconv.la -o iconv_no_i18n
cc iconv_no_i18n.o -o .libs/iconv_no_i18n -L/opt/lib/64 ../srclib/libicrt.a ../
lib/.libs/libiconv.so -R/opt/lib/64
ld: fatal: file iconv_no_i18n.o: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to .libs/iconv_no_i18n
gmake[1]: *** [iconv_no_i18n] Error 1
gmake[1]: Leaving directory `/usr/local/src/gnu/libiconv-1.10/src'
gmake: *** [all] Error 2
.
The 64 bit configure line looks like this.
:
PACKAGE=libiconv
DIR=gnu
VER=1.10
ID=/usr/xpg4/bin/id \
CFLAGS=-fast -xtarget=ultra -xcode=pic32 -xarch=v9 \
CPPFLAGS=-I/opt/include \
LDFLAGS=-L/opt/lib/64 \
/opt/src/${DIR}/${PACKAGE}-${VER}/configure \
--prefix=/opt/mt/${PACKAGE}-${VER} \
--libdir=/opt/lib/64\
--mandir=/opt/mt/${PACKAGE}-${VER}/man \
--enable-shared \
21 | tee x.conf
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
missing sco bits
Here is a small patch for the 1.5 branch that got missed in all
the SCO changes a while back. HEAD is OK.
I makes the C++ and C sections match.
--- libtool-1.5/libtool.m4.old 2006-05-29 19:26:34.73072 -0700
+++ libtool-1.5/libtool.m4 2006-05-29 19:29:33.405760087 -0700
@@ -6239,7 +6239,7 @@
fi
;;
-sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | 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
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
Re: Help: 64 Bit Solaris 10
On Mon, 5 Dec 2005, Edward Maros wrote: This may be a frequent question, but I have not been able to find a solution yet. I am trying to port out application to 64bit using a sparc4u running Solaris 10. The application uses autoconf/automake/libtool/gcc for configuration and building of targets. With my first attempt at going 64 bit, I hit a problem since libtool seems to configure only 32bit (at least for creating shared objects). Am I missing something that I could do to make the leap to 64 bit? Try CC=gcc -m64 ./configure Thanks, Ed -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Differnet config for root and non root user
On Thu, 17 Nov 2005, peto wrote: Dear conference, During compilation of the OO.org 2.0 in Mandrake 9.0 I found that libtool 1.4.3 shows [EMAIL PROTECTED] peto]$ libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [EMAIL PROTECTED] peto]$ libtool --config |more # Libtool was configured on host hp6.mandrakesoft.com: [snip] [EMAIL PROTECTED] peto]$ su Password: [EMAIL PROTECTED] peto]# libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [EMAIL PROTECTED] peto]# libtool --config |more # Libtool was configured on host chello082119109251.chello.sk: ^^^ [snip] Can anyone recomend me what to do to work libtool as root for shared libraries because OO.org 2.0 dmake(nmake) works only as root.,please.. You have 2 different versions of libtool on your system. When you su you get a different PATH. Remove the one you don't want or fix your PATH aftr you su. Thank you for any help as well as finding problem which can be also in path I look forward hearing from you Yours faithfully Peter Fodrek -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Differnet config for root and non root user
On Thu, 17 Nov 2005, peto wrote: D??a ??t 17. November 2005 19:46 Tim Rice nap??sal: [EMAIL PROTECTED] peto]$ libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [EMAIL PROTECTED] peto]$ libtool --config |more # Libtool was configured on host hp6.mandrakesoft.com: [snip] [EMAIL PROTECTED] peto]$ su Password: [EMAIL PROTECTED] peto]# libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [EMAIL PROTECTED] peto]# libtool --config |more # Libtool was configured on host chello082119109251.chello.sk: You have 2 different versions of libtool on your system. When you su you get a different PATH. Remove the one you don't want or fix your PATH aftr you su. Thank you, it works in confif but it does not realy produce shared libraries yet. my local version in /usr/local was made from sources and MDK vesrion works but not correctly (with freetype) Version 1.4.3 is a bit old. You might want to try 1.5.20. Peter -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: ksh88 quote.test fix (was: branch-1-5 UnixWare fixes)
On Sun, 13 Nov 2005, Ralf Wildenhues wrote: Hi Tim, [snip] * tests/quote.test: Do not fail on harmless shell bug present in some ksh88 versions. Actually ksh88 was the one that would pass the quote test before the patch. It was ksh Version M-12/28/93e-SCO that gave me trouble here. Reported by Tim Rice [EMAIL PROTECTED] and others. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: branch-1-5 UnixWare fixes
On Sat, 12 Nov 2005, Ralf Wildenhues wrote: Hi Tim, Quite some time ago: * Tim Rice wrote on Mon, Sep 26, 2005 at 08:41:21PM CEST: On Mon, 26 Sep 2005, Ralf Wildenhues wrote: : * Tim Rice wrote on Sun, Sep 25, 2005 at 10:05:21PM CEST: [snip] : I re-ran the tests using ksh88 and all tests passed. : Must be a ksh bug. : Version M-11/16/88h passes quote test : Version M-12/28/93e-SCO fails quote test : make check TESTS=quote.test VERBOSE=x = trying: \\ quoting = failed: mkdir .libs cc -c -DVAR=\\test\\ foo.c -KPIC -DPIC -o .libs/foo.o cc -c -DVAR=\\test\\ foo.c -o foo.o /dev/null 21 = trying: \ quoting *snip* FAIL: quote.test Does the test pass even with ksh88, after this patch is applied (CVS HEAD)? Tests pass on both ksh and ksh88. Good work. Thank you, Ralf -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
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)='-Wl
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
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 8 of 10: ltmain.in -L handling for SCO platforms
On Mon, 7 Nov 2005, Ralf Wildenhues wrote: Hi Tim, * Tim Rice wrote on Sun, Nov 06, 2005 at 11:41:39PM CET: ... $ dump -Lv .libs/depdemo libs/depdemo: DYNAMIC SECTION INFORMATION dynamic : [INDEX] Tag Value [1] NEEDED libl1.so.0 [2] NEEDED libl2.so.0 [3] NEEDED libl4.so.0 [4] NEEDED libl3.so.0 [5] NEEDED libl2.so.0 [6] NEEDED libl1.so.0 [7] NEEDED /usr/lib/libc.so.1 [8] INIT 0x8048750 [9] FINI 0x8048760 [10]RPATH/usr/local/src/gnu/libtool-1.5.21a/tests/_inst/lib: [11]HASH 0x80480e8 [12]STRTAB 0x8048328 [13]SYMTAB 0x8048198 [14]STRSZ0x14e [15]SYMENT 0x10 [16]DEBUG0 [17]PLTGOT 0x8049828 [18]PLTSZ0x48 [19]PLTREL 0x11 [20]JMPREL 0x8048498 [21]REL 0x8048478 [22]RELSZ0x20 [23]RELENT 0x8 Ah-ha! So the linker thinks these are two different libraries, and adds two DT_NEEDED entries. How stupid. Now we need to find out whether this affects the dynamic loader (RTLD) as well. It's bound to be pretty unlikely, but with the -lc disaster, I won't place any bets. :-/ Is there a way to find out the equivalent of what this does on Linux? $ cat /proc/$PID/maps Alternatively, and this is what it boils down to: Does the loader try to load libl1.so.0 twice (and thus, for example, create two distinct sections for static library data)? I don't care too much about the extra DT_NEEDED entry if it does no harm otherwise. UnixWare does have /proc/$PID/maps but it's binary data. Looking at truss, it looks like they are opened once. (striped out the ENOENT lines) open(/usr/local/src/gnu/libtool-1.5.21a/depdemo/l1/.libs/libl1.so.0, O_RDONLY, 02756034) = 3 open(/usr/local/src/gnu/libtool-1.5.21a/depdemo/l2/.libs/libl2.so.0, O_RDONLY, 02756034) = 3 open(/usr/local/src/gnu/libtool-1.5.21a/depdemo/l4/.libs/libl4.so.0, O_RDONLY, 02756034) = 3 open(/usr/local/src/gnu/libtool-1.5.21a/depdemo/l3/.libs/libl3.so.0, O_RDONLY, 02756034) = 3 Another thing: the RPATH entry is fishy (this is a Libtool bug): there should not be a trailing colon, I believe. I think I know where this happens (there is a TODO entry for this, too, Albert reported it some time ago but I never saw it happen). Could you post the link line of `depdemo' and its output with --debug added, too? /usr/bin/ksh88 ./libtool --tag=CC --mode=link cc -g -o depdemo main.o ./l1/libl1.la ./l2/libl2.la ./l4/libl4.la mkdir .libs LD_RUN_PATH=/usr/local/src/gnu/libtool-1.5.21a/tests/_inst/lib:$LD_RUN_PATH cc -g -o .libs/depdemo main.o -L./l1/.libs ./l1/.libs/libl1.so -L./l2/.libs ./l2/.libs/libl2.so -L./l4/.libs ./l4/.libs/libl4.so -L/usr/local/src/gnu/libtool-1.5.21a/depdemo/l3/.libs /usr/local/src/gnu/libtool-1.5.21a/depdemo/l3/.libs/libl3.so -L/usr/local/src/gnu/libtool-1.5.21a/depdemo/l2/.libs /usr/local/src/gnu/libtool-1.5.21a/depdemo/l2/.libs/libl2.so -L/usr/local/src/gnu/libtool-1.5.21a/depdemo/l1/.libs /usr/local/src/gnu/libtool-1.5.21a/depdemo/l1/.libs/libl1.so -lm creating depdemo see attached depdemo-link-debug.gz for --debug output. Thanks, Ralf -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] depdemo-link-debug.gz Description: depdemo-link-debug.gz
Re: SCO/bugfix patch 8 of 10: ltmain.in -L handling for SCO platforms
On Sat, 5 Nov 2005, Ralf Wildenhues wrote: Hi Kean, * Kean Johnston wrote on Mon, Oct 31, 2005 at 02:07:21AM CET: Handle older SCO systems correctly. Hmm. The original bug report (that added the sco3.2v5 line) is here: http://savannah.gnu.org/patch/index.php?func=detailitemitem_id=298 I don't quite understand it, though. What exactly is going wrong here? Here is an example on UnixWare 7.1.1 [snip] /usr/bin/ksh88 ./libtool --tag=CC --mode=link cc -g -o depdemo main.o ./l1/libl1.la ./l2/libl2.la ./l4/libl4.la mkdir .libs LD_RUN_PATH=/usr/local/src/gnu/libtool-1.5.21a/tests/_inst/lib:$LD_RUN_PATH cc -g -o .libs/depdemo main.o ./l1/.libs/libl1.so ./l2/.libs/libl2.so ./l4/.libs/libl4.so /usr/local/src/gnu/libtool-1.5.21a/depdemo/l3/.libs/libl3.so /usr/local/src/gnu/libtool-1.5.21a/depdemo/l2/.libs/libl2.so /usr/local/src/gnu/libtool-1.5.21a/depdemo/l1/.libs/libl1.so -lm UX:ld: ERROR: fatal error: library libl1.so.0, which is NEEDED by ./l2/.libs/libl2.so, is not found gmake[1]: *** [depdemo] Error 1 gmake[1]: Leaving directory `/usr/local/src/gnu/libtool-1.5.21a/depdemo' gmake: *** [all-recursive] Error 1 Cheers, Ralf 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 -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: SCO/bugfix patch 8 of 10: ltmain.in -L handling for SCO platforms
On Sun, 6 Nov 2005, Ralf Wildenhues wrote: Hi Tim, * Tim Rice wrote on Sun, Nov 06, 2005 at 09:28:59PM CET: On Sat, 5 Nov 2005, Ralf Wildenhues wrote: Hmm. The original bug report (that added the sco3.2v5 line) is here: http://savannah.gnu.org/patch/index.php?func=detailitemitem_id=298 I don't quite understand it, though. What exactly is going wrong here? Here is an example on UnixWare 7.1.1 [snip] /usr/bin/ksh88 ./libtool --tag=CC --mode=link cc -g -o depdemo main.o ./l1/libl1.la ./l2/libl2.la ./l4/libl4.la mkdir .libs LD_RUN_PATH=/usr/local/src/gnu/libtool-1.5.21a/tests/_inst/lib:$LD_RUN_PATH cc -g -o .libs/depdemo main.o ./l1/.libs/libl1.so ./l2/.libs/libl2.so ./l4/.libs/libl4.so /usr/local/src/gnu/libtool-1.5.21a/depdemo/l3/.libs/libl3.so /usr/local/src/gnu/libtool-1.5.21a/depdemo/l2/.libs/libl2.so /usr/local/src/gnu/libtool-1.5.21a/depdemo/l1/.libs/libl1.so -lm UX:ld: ERROR: fatal error: library libl1.so.0, which is NEEDED by ./l2/.libs/libl2.so, is not found OK. Could you post the link line and output creating ./l2/libl2.la, ... /usr/bin/ksh88 ../libtool --tag=CC --mode=link cc -g -o libl2.la -rpath /usr/local/src/gnu/libtool-1.5.21a/tests/_inst/lib -no-undefined l2.lo ../l1/libl1.la cc -G -Wl,-h -Wl,libl2.so.0 -o .libs/libl2.so.0.0.0 .libs/l2.o ../l1/.libs/libl1.so (cd .libs rm -f libl2.so.0 ln -s libl2.so.0.0.0 libl2.so.0) (cd .libs rm -f libl2.so ln -s libl2.so.0.0.0 libl2.so) ar cru .libs/libl2.a l2.o : .libs/libl2.a creating libl2.la (cd .libs rm -f libl2.la ln -s ../libl2.la libl2.la) ... further `objdump -p ./l2/.libs/libl2.so', and also, with the patch ... $ dump -Lv ./l2/.libs/libl2.so /l2/.libs/libl2.so: DYNAMIC SECTION INFORMATION dynamic : [INDEX] Tag Value [1] NEEDED libl1.so.0 [2] INIT 0x710 [3] FINI 0x720 [4] SONAME libl2.so.0 [5] HASH 0x94 [6] STRTAB 0x48c [7] SYMTAB 0x1dc [8] STRSZ0xea [9] SYMENT 0x10 [10]PLTGOT 0x1728 [11]PLTSZ0x18 [12]PLTREL 0x11 [13]JMPREL 0x590 [14]REL 0x578 [15]RELSZ0x18 [16]RELENT 0x8 ... applied, `objdump -p .libs/depdemo'? Please replace `objdump -p' with ... $ dump -Lv .libs/depdemo libs/depdemo: DYNAMIC SECTION INFORMATION dynamic : [INDEX] Tag Value [1] NEEDED libl1.so.0 [2] NEEDED libl2.so.0 [3] NEEDED libl4.so.0 [4] NEEDED libl3.so.0 [5] NEEDED libl2.so.0 [6] NEEDED libl1.so.0 [7] NEEDED /usr/lib/libc.so.1 [8] INIT 0x8048750 [9] FINI 0x8048760 [10]RPATH/usr/local/src/gnu/libtool-1.5.21a/tests/_inst/lib: [11]HASH 0x80480e8 [12]STRTAB 0x8048328 [13]SYMTAB 0x8048198 [14]STRSZ0x14e [15]SYMENT 0x10 [16]DEBUG0 [17]PLTGOT 0x8049828 [18]PLTSZ0x48 [19]PLTREL 0x11 [20]JMPREL 0x8048498 [21]REL 0x8048478 [22]RELSZ0x20 [23]RELENT 0x8 ... the appropriate UnixWare tool, probably spelled `dump -Lv'? Thanks, Ralf -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: SCO/buffix patch 6 of 10: AC_PROG_NM fixes
On Tue, 1 Nov 2005, Ralf Wildenhues wrote: Hi Kean, * Kean Johnston wrote on Tue, Nov 01, 2005 at 08:34:00AM CET: [snip] 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? -- UnixWare 7.1.4 --- $ nm -B /dev/null UX:nm: ERROR: Illegal option -- B UX:nm: TO FIX: Usage: nm [-ACDPRVghnoplrt?] [-t d|o|x] file(s)... $ echo $? 1 -- UnixWare 7.1.1 --- $ nm -B /dev/null nm: ERROR: Illegal option -- B nm: Usage: nm [-?CVhnoplruvx] 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 $ echo $? 1 -- UnixWare 2.03 --- $ nm -B /dev/null nm: ERROR: Illegal option -- B nm: Usage: nm [-?CVhnoplruvx] 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 $ echo $? 1 OpenServer 5.0.4 -- $ nm -B /dev/null nm: ERROR: Illegal option -- B i386nm: Usage: i386nm [-?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 $ echo $? 1 OpenServer 5.0.7 -- $ nm -B /dev/null nm: ERROR: Illegal option -- B i386nm: Usage: i386nm [-?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 $ echo $? 1 OpenServer 6.0.0 -- $ nm -B /dev/null UX:nm: ERROR: Illegal option -- B UX:nm: TO FIX: Usage: nm [-ACDPRVghnoplrt?] [-t d|o|x] file(s)... $ echo $? 1 -- -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: SCO/bugfix patch 1 of 10: AC_LIBTOOL_SYS_MAX_CMD_LEN
On Mon, 31 Oct 2005, Ralf Wildenhues wrote: Hi Kean, [snip] So I guess we don't want to see the read failure error from grep, since we deal with it. This slightly simpler patch should work as well, with sed being greedy. OK? Tests fine here. Cheers, Ralf 2005-10-24 Kean Johnston [EMAIL PROTECTED] * libtool.m4(AC_LIBTOOL_SYS_MAX_CMD_LEN): Set correctly for SCO. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.116 diff -u -r1.314.2.116 libtool.m4 --- libtool.m431 Oct 2005 08:38:50 - 1.314.2.116 +++ libtool.m431 Oct 2005 09:09:16 - @@ -738,6 +738,17 @@ esac fi ;; + sco3.2v5*) +lt_cv_sys_max_cmd_len=102400 +;; + sysv5* | sco5v6* | sysv4.2uw2*) +kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2/dev/null` +if test -n $kargmax; then + lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[[ ]]//'` +else + lt_cv_sys_max_cmd_len=32768 +fi +;; *) # If test is not a shell built-in, we'll probably end up computing a # maximum length that is only half of the actual maximum length, but -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: SCO/bugfix patch 1 of 10: AC_LIBTOOL_SYS_MAX_CMD_LEN
On Sun, 30 Oct 2005, Kean Johnston wrote: Patch 1 of 10 attached ... Minor nit. + sysv5* | sco5v6*) +kargmax=`grep ARG_MAX /etc/conf/cf.d/stune` This works for UnixWare 2.x too. Should be + sysv5* | sco5v6* | sysv4.2uw2*) -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
On Sun, 30 Oct 2005, Kean Johnston wrote:
Patch 7 of 10 attached ...
Rationale:
I like it when things work on my platform :)
2005-10-24 Kean Johnston [EMAIL PROTECTED]
* libtool.m4: Complete overhaul of SCO support.
I'm attaching a corrected patch.
.
case $host_os in
+ sco3.2v5*)
- *-*-sco3.2v5*)
sys_lib_search_path_spec=$sys_lib_search_path_spec /lib
;;
esac
Missing some square brackets.
- sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* |
sco3.2v5.0.[024]*)
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* |
sco3.2v5.0.[[024]]*)
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- libtool.m4.old 2005-10-15 13:12:08.0 -0700
+++ libtool.m4 2005-10-30 18:30:34.371040302 -0800
@@ -1623,13 +1635,6 @@
sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
;;
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
solaris*)
version_type=linux
need_lib_prefix=no
@@ -1655,7 +1660,7 @@
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3*)
+sysv4 | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -1688,17 +1693,27 @@
fi
;;
-sysv5*)
- version_type=linux
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
need_lib_prefix=no
need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext} $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=yes
hardcode_into_libs=yes
- sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
- sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
+ if test $with_gnu_ld = yes; then
+shlibpath_overrides_runpath=no
+sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib
/usr/lib /lib'
+ else
+shlibpath_overrides_runpath=yes
+sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+case $host_os in
+ sco3.2v5*)
+sys_lib_search_path_spec=$sys_lib_search_path_spec /lib
+ ;;
+esac
+ fi
+ sys_lib_dlsearch_path_spec='/usr/lib'
;;
uts4*)
@@ -2319,15 +2334,11 @@
lt_cv_deplibs_check_method=pass_all
;;
-sco3.2v5*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
solaris*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv4 | sysv4.2uw2* | sysv4.3*)
+sysv4 | sysv4.3*)
case $host_vendor in
motorola)
lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB
(shared object|dynamic lib) M[[0-9]][[0-9]]* Version [[0-9]]'
@@ -2354,7 +2365,7 @@
esac
;;
-unixware7* | sysv5*)
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
lt_cv_deplibs_check_method=pass_all
;;
esac
@@ -2600,13 +2615,6 @@
# Check for any special shared library compilation flags.
#
_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)=
-if test $GCC = no; then
- case $host_os in
- sco3.2v5*)
-_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)='-belf'
-;;
- esac
-fi
if test -n $_LT_AC_TAGVAR(lt_prog_cc_shlib, $1); then
AC_MSG_WARN([`$CC' requires `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to build
shared libraries])
if echo $old_CC $old_CFLAGS | grep [[
]]$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)[[]] /dev/null; then :
@@ -3477,19 +3485,6 @@
# FIXME: insert proper C++ library support
_LT_AC_TAGVAR(ld_shlibs, $1)=no
;;
- sco*)
-_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
-case $cc_basename in
- CC*)
- # FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
- ;;
- *)
- # FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
- ;;
-esac
-;;
sunos4*)
case $cc_basename in
CC*)
@@ -3582,27 +3577,48 @@
;;
esac
;;
- sysv5OpenUNIX8* | sysv5UnixWare7.[[01]].[[01]]* | sysv5uw[[78]]* |
unixware7*)
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* |
sco3.2v5.0.[[024]]*)
+_LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+runpath_var='LD_RUN_PATH'
+
case $cc_basename in
CC*)
- _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z ${wl}text'
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h ${wl}$soname -o $lib
$libobjs $deplibs
Re: tagdemo test / -c -o
On Sun, 30 Oct 2005, Ralf Wildenhues wrote: Hi Tim, * Tim Rice wrote on Sun, Oct 30, 2005 at 02:34:18AM CET: On Sun, 30 Oct 2005, Ralf Wildenhues wrote: I guess you should be able to use this manually-written rule as a workaround: .cpp.$(OBJEXT): $(CXXCOMPILE) -c $ Or this patch to automake .. --- automake-1.9.6/automake.in.old 2005-06-30 14:17:13.0 -0700 +++ automake-1.9.6/automake.in 2005-10-29 18:31:51.565961323 -0700 @@ -691,7 +691,6 @@ 'compile' = '$(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)', 'compiler' = 'CXXCOMPILE', 'compile_flag' = '-c', - 'output_flag' = '-o', 'libtool_tag' = 'CXX', 'lder' = 'CXXLD', 'ld' = '$(CXX)', No. :) Above workaround works only because - we do not use subdir-objects; in fact, we do not use subdirs at all, - none of the non-libtool objects (i.e., the `.o' ones) use per-target flags It seems strange that automake's COMPILE section has no 'output_flag' = '-o', but the CXXCOMPILE does. It's really just appropriate for the tagdemo case, not for Automake in general. Cheers, Ralf -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HEAD test 13
On Sun, 30 Oct 2005, Tim Rice wrote: . 13. old-m4-iface.at:34: testing ... libtoolize: linking file `./config.guess' libtoolize: linking file `./config.sub' libtoolize: linking file `./install-sh' libtoolize: linking file `./ltmain.sh' libtoolize: You should add the contents of `/opt/src/gnu/libtool-2.x/libltdl/m4/libtool.m4' to `aclocal.m4'. old-m4-iface.at:79: $AUTOCONF --force stderr: UX:ksh: ERROR: autoconf: not found stdout: old-m4-iface.at:79: exit code was 1, expected 0 13. old-m4-iface.at:34: 13. AM_PROG_LIBTOOL (old-m4-iface.at:34): FAILED (old-m4-iface.at:79) . Should test 13 fail if the system you are testing on has no autoconf? Perhaps it should pass. Same for 14, 27, 28 And aclocal in 14, 21, 22, 23, 27, 28 -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
tagdemo test / -c -o
branch-1-5 I'm getting falures in the tagdemo-exec tests on my UnixWare 2.03 box because of this rule in tagdemo/Makefile.in . cpp.o: $(CXXCOMPILE) -c -o $@ $ . The native c/CC compilers on the that machine does not like -c -o Is there a way to work around this, or is this an automake 1.9.6 bug? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: tagdemo test / -c -o
On Sun, 30 Oct 2005, Ralf Wildenhues wrote: Sorry for self-reply. * Ralf Wildenhues wrote on Sun, Oct 30, 2005 at 02:08:14AM CET: * Tim Rice wrote on Sun, Oct 30, 2005 at 01:41:22AM CEST: The native c/CC compilers on the that machine does not like -c -o Is there a way to work around this, or is this an automake 1.9.6 bug? Oops. Does it work if you change the AC_PROG_CC_C_O to be AM_PROG_CC_C_O in libtool-1.5/tagdemo/configure.ac and rerun bootstrap? Gah. AM_PROG_CC_C_O is C only, not C++. I guess you should be able to use this manually-written rule as a workaround: .cpp.$(OBJEXT): $(CXXCOMPILE) -c $ Or this patch to automake .. --- automake-1.9.6/automake.in.old 2005-06-30 14:17:13.0 -0700 +++ automake-1.9.6/automake.in 2005-10-29 18:31:51.565961323 -0700 @@ -691,7 +691,6 @@ 'compile' = '$(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)', 'compiler' = 'CXXCOMPILE', 'compile_flag' = '-c', - 'output_flag' = '-o', 'libtool_tag' = 'CXX', 'lder' = 'CXXLD', 'ld' = '$(CXX)', .. or this (uses undocumented Automake knowledge, thus not advised): tagdemo_OBJECTS = tagdemo.lo Reminder to self (or whoever else): Automake needs to learn that C++ and Fortran 77/90 compilers may not understand `-c -o'. Cheers, Ralf -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
UnixWare -lc fixes
After looking over some stuff in http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00839.html that related to libtool and some off list emails with Kean Johnston (the author of the gcc patch) and Ralf Wildenhues, I realize my UnixWare patch was incomplete. On UnixWare and OpenServer 56 we never want -lc on the command line. cc / CC takes care of that for us (and always gets it right). Setting build_libtool_need_lc=no takes care of most of it but that doesn't account for Makefiles adding -lc. Like this snip from gettext-0.14.5/gettext-runtime/intl/Makefile.in .. libintl.la libgnuintl.la: $(OBJECTS) $(LIBTOOL) --mode=link \ $(CC) $(CPPFLAGS) $(CFLAGS) $(XCFLAGS) $(LDFLAGS) -o $@ \ $(OBJECTS) @LTLIBICONV@ @INTL_MACOSX_LIBS@ $(LIBS) -lc \ -version-info $(LTV_CURRENT):$(LTV_REVISION):$(LTV_AGE) \ -rpath $(libdir) \ -no-undefined .. I had been patching Makefiles (post configure) in packages to strip out -lc. Now I realize libtool can do that for me. I've attached patches to branch-1-5 and HEAD. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]--- ltmain.in.old 2005-10-17 13:56:43.0 -0700 +++ ltmain.in 2005-10-17 21:29:17.160096225 -0700 @@ -1494,6 +1494,15 @@ # 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*) + # cc / CC insert libc in correct order for threads to work + test X$arg = X-lc continue + ;; esac elif test X$arg = X-lc_r; then case $host in --- libltdl/config/ltmain.m4sh.old 2005-10-15 16:26:35.0 -0700 +++ libltdl/config/ltmain.m4sh 2005-10-17 21:26:09.785056333 -0700 @@ -2612,6 +2612,15 @@ # Rhapsody C and math libraries are in the System framework deplibs=$deplibs System.ltframework continue + ;; + *-*-sco3.2v5*) + # Causes problems with __ctype + test X$arg = X-lc continue + ;; + *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*) + # cc / CC insert libc in correct order for threads to work + test X$arg = X-lc continue + ;; esac elif test X$arg = X-lc_r; then case $host in
fix for tests 20 21
Here is a patch to early-libtool.at that adds SHELL = @SHELL@ to the 2 Makefile.in files it creates for tests 20 21. Without it on some platforms you will see errors like this in testsuite.log. My toplevel Makefile had SHELL = /usr/bin/ksh88 . /bin/sh ./libtool --mode=link --tag=CC cc -o hell main.o libhello.la UX:sh (./libtool): ERROR: Bad substitution . -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] --- tests/early-libtool.at.old 2005-09-08 00:17:58.0 -0700 +++ tests/early-libtool.at 2005-09-28 21:01:44.794068004 -0700 @@ -39,6 +39,7 @@ [[prefix = @prefix@ libdir = @libdir@ top_builddir = . +SHELL = @SHELL@ DEFAULT_INCLUDES = -I. [EMAIL PROTECTED]@ EXEEXT = @EXEEXT@ LIBTOOL = @LIBTOOL@ @@ -149,6 +150,7 @@ [[prefix = @prefix@ libdir = @libdir@ top_builddir = . +SHELL = @SHELL@ DEFAULT_INCLUDES = -I. [EMAIL PROTECTED]@ EXEEXT = @EXEEXT@ LIBTOOL = @LIBTOOL@
forward porting UnixWare fixes to HEAD
: ./sub/main; lt_status=$?; if test $lt_status -eq 0; then :;
elif test X$host != X$build \
{ test -x ./sub/main || test -x ./sub/main$EXEEXT; }
then (exit 77); else (exit $lt_status); fi
0a1
UX:ksh: ERROR: ./sub/main: not found
19. template.at:115: 19. template test with subdirs (template.at:115): FAILED
(template.at:214)
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: SYSROOT/DESTDIR
On Tue, 27 Sep 2005, Ralf Wildenhues wrote: Hi Tim, * Tim Rice wrote on Tue, Sep 27, 2005 at 07:56:31PM CEST: I'd like to be able have the embedded runpath be /opt/lib even if I install in /opt/foo/lib. (the package posinstall script would put symbolic links in /opt/lib) I believe that should be possible now, although in a bit weird way: configure --prefix=/opt --enable-fast-install [OPTIONS] make make install DESTDIR=/tmp $mkdir_p /opt/foo mv /tmp/opt/* /opt/foo # create symlinks .. ./libtool --mode=finish /opt/lib (surely you can also use some other path below /opt as DESTDIR to avoid another copy if /tmp is on another mount point). Hmm, that may work. I'll have to try it sometime. It'll require some serious changes to my package build scripts. :-( Thanks. Did I miss anything? Cheers, Ralf -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-1-5 UnixWare fixes
On Mon, 26 Sep 2005, Ralf Wildenhues wrote: Hi Tim, * Tim Rice wrote on Mon, Sep 26, 2005 at 08:41:21PM CEST: On Mon, 26 Sep 2005, Ralf Wildenhues wrote: : * Tim Rice wrote on Sun, Sep 25, 2005 at 10:05:21PM CEST: [snip] : : Content-Description: branch-1-5-uw.patch *snip* : : : : -sysv4*uw2* | unixware7*) : : +unixware7*) : : : : Now, this macro doesn't have a match for sysv4*uw2* any more. Is this : : intentional? : : Quite intentional. Look at the case above, it already had sysv4*uw2* so : the one I removed would never have been used anyway. Adding the pc) : case to the $host_vendor part did what the other case was supposed to do. : : Erm, it had sysv4.2uw2* but not sysv4*uw2*. If both should be treated : similarly here, then you should replace the former with the latter (in : the line where sysv4 is also matched) Remind me never to take a proof reading job. I guess my brain was focusing in the uw2 part. All UnixWare 2.x versions (and 1.x) are sysv4.2, so the sysv4*uw2 entry becomes redundant. Well, I _was_ cheating a bit: http://lists.gnu.org/archive/html/bug-libtool/2005-09/msg00013.html http://lists.gnu.org/archive/html/libtool-patches/2005-09/msg00036.html (be sure to look through both threads -- I installed a bogus patch first, stumbling over this exact same issue ;-) And I made the same mistake (sysv4*uw2/sysv4.2*uw2) in http://lists.gnu.org/archive/html/libtool-patches/2004-10/msg00012.html OK, so we don't need to worry about sysv4*uw2 as all UnixWare 2 are sysv4.2 : It could be cleanded up further by having sysv5* | unixware7*). : (UnixWare 7 is sysv5) : : Hmm, then both of those should be treated similarly, I guess? Yes. OK. Cheers, Ralf -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: branch-1-5 UnixWare fixes
On Mon, 26 Sep 2005, Ralf Wildenhues wrote:
Hi Tim,
* Tim Rice wrote on Mon, Sep 26, 2005 at 10:45:29PM CEST:
On Mon, 26 Sep 2005, Ralf Wildenhues wrote:
* Tim Rice wrote on Mon, Sep 26, 2005 at 08:41:21PM CEST:
All UnixWare 2.x versions (and 1.x) are sysv4.2, so the sysv4*uw2 entry
becomes redundant.
Well, I _was_ cheating a bit:
http://lists.gnu.org/archive/html/bug-libtool/2005-09/msg00013.html
http://lists.gnu.org/archive/html/libtool-patches/2005-09/msg00036.html
(be sure to look through both threads -- I installed a bogus patch first,
stumbling over this exact same issue ;-)
And I made the same mistake (sysv4*uw2/sysv4.2*uw2) in
http://lists.gnu.org/archive/html/libtool-patches/2004-10/msg00012.html
OK, so we don't need to worry about sysv4*uw2 as all UnixWare 2 are
sysv4.2
Good thing we got that sorted out. ;-)
Could you -- in light of this -- repost your patch, so we can apply it?
(Or test CVS HEAD first and then repost; whatever suits you best.)
A ChangeLog entry would be nice, but I'll happily write one for you,
too. :)
Ok, here it is including an attempt at a ChangeLog entry.
Thank you,
Ralf
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- libtool-1.5/ChangeLog.old 2005-09-25 09:00:18.0 -0700
+++ libtool-1.5/ChangeLog 2005-09-26 15:54:26.944777219 -0700
@@ -1,3 +1,12 @@
+2005-09-26 Tim Rice [EMAIL PROTECTED]
+
+ * libtool.m4 (AC_DEPLIBS_CHECK_METHOD, AC_LIBTOOL_SYS_DYNAMIC_LINKER)
+ (AC_LIBTOOL_LANG_CXX_CONFIG, AC_LIBTOOL_PROG_COMPILER_PIC)
+ (AC_LIBTOOL_PROG_LD_SHLIBS):
+ * ltdl.m4 (AC_LTDL_SYS_DLOPEN_DEPLIBS):
+ Get UnixWare 7.1.[34] and OpenServer 6 fully working.
+ Improve other UnixWare versions a little.
+
2005-09-25 Alan W. Irwin [EMAIL PROTECTED],
Ralf Wildenhues [EMAIL PROTECTED]
--- libtool-1.5/libtool.m4.old 2005-09-22 16:59:00.0 -0700
+++ libtool-1.5/libtool.m4 2005-09-26 15:31:57.164617030 -0700
@@ -1655,7 +1655,7 @@
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.2uw2* | 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,6 +1688,19 @@
fi
;;
+sysv5*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $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
+ ;;
+
uts4*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
@@ -2314,11 +2327,7 @@
lt_cv_deplibs_check_method=pass_all
;;
-sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.2uw2* | 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]]'
@@ -2339,10 +2348,13 @@
siemens)
lt_cv_deplibs_check_method=pass_all
;;
+ pc)
+lt_cv_deplibs_check_method=pass_all
+;;
esac
;;
-sysv4*uw2* | unixware7*)
+unixware7* | sysv5*)
lt_cv_deplibs_check_method=pass_all
;;
esac
@@ -3559,8 +3571,29 @@
;;
esac
;;
- sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7*)
-_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+ sysv5OpenUNIX8* | sysv5UnixWare7.[[01]].[[01]]* | sysv5uw[[78]]* |
unixware7*)
+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
+ ;;
+esac
+;;
+ sysv5*)
+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
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=':'
+ runpath_var='LD_RUN_PATH'
+ _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+ ;;
+esac
;;
tandem*)
case $cc_basename in
@@ -4949,7 +4982,14 @@
;;
esac
autoreconf: Allow variable override
CVS HEAD
Here is a patch to tests/defs.m4sh to fix the hard coded autoreconf.
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- ChangeLog.old 2005-09-26 15:22:52.0 -0700
+++ ChangeLog 2005-09-26 16:31:55.389977074 -0700
@@ -1,3 +1,7 @@
+2005-09-26 Tim Rice [EMAIL PROTECTED]
+
+ * tests/defs.m4sh AUTORECONF: Allow variable override.
+
2005-09-26 Ralf Wildenhues [EMAIL PROTECTED]
* HACKING: Only update libltdl version info before release.
--- tests/defs.m4sh.old 2005-08-24 06:39:51.0 -0700
+++ tests/defs.m4sh 2005-09-26 16:27:42.929977009 -0700
@@ -31,6 +31,7 @@
m4_include([general.m4sh])
: ${AUTOCONF=autoconf}
+: ${AUTORECONF=autoreconf}
: ${LIBTOOL=./libtool}
# Sed that helps us avoid accidentally triggering echo(1) options like -n.
@@ -187,7 +188,7 @@
func_msg Configuring in $my_dir
-test -f $my_testdir/configure || autoreconf --force --install $my_testdir
+test -f $my_testdir/configure || ${AUTORECONF} --force --install
$my_testdir
if test -f $my_testdir/configure; then
eval func_msg $SHELL $my_testdir/configure $my_args
Re: autoreconf: Allow variable override
On Mon, 26 Sep 2005, Tim Rice wrote:
CVS HEAD
Here is a patch to tests/defs.m4sh to fix the hard coded autoreconf.
Oops, missed one. tests/testsuite.at needed tuning up too.
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- ChangeLog.old 2005-09-26 15:22:52.0 -0700
+++ ChangeLog 2005-09-26 18:15:08.945737083 -0700
@@ -1,3 +1,8 @@
+2005-09-26 Tim Rice [EMAIL PROTECTED]
+
+ * tests/defs.m4sh tests/testsuite.at
+ AUTORECONF: Allow variable override.
+
2005-09-26 Ralf Wildenhues [EMAIL PROTECTED]
* HACKING: Only update libltdl version info before release.
--- tests/defs.m4sh.old 2005-08-24 06:39:51.0 -0700
+++ tests/defs.m4sh 2005-09-26 16:27:42.929977009 -0700
@@ -31,6 +31,7 @@
m4_include([general.m4sh])
: ${AUTOCONF=autoconf}
+: ${AUTORECONF=autoreconf}
: ${LIBTOOL=./libtool}
# Sed that helps us avoid accidentally triggering echo(1) options like -n.
@@ -187,7 +188,7 @@
func_msg Configuring in $my_dir
-test -f $my_testdir/configure || autoreconf --force --install $my_testdir
+test -f $my_testdir/configure || ${AUTORECONF} --force --install
$my_testdir
if test -f $my_testdir/configure; then
eval func_msg $SHELL $my_testdir/configure $my_args
--- tests/testsuite.at.old 2005-09-16 01:33:24.0 -0700
+++ tests/testsuite.at 2005-09-26 18:09:16.830697004 -0700
@@ -23,6 +23,7 @@
: ${LIBTOOL=${abs_top_builddir}/libtool}
: ${ACLOCAL=aclocal}
: ${AUTOCONF=autoconf}
+: ${AUTORECONF=autoreconf}
export LIBTOOLIZE LIBTOOL ACLOCAL AUTOCONF
eval `$LIBTOOL --config | grep ^EGREP=`
eval `$LIBTOOL --config | $EGREP '^(host|host_os|build)='`
@@ -48,7 +49,7 @@
m4_define([LT_AT_BOOTSTRAP],
[
test -f ./ltmain.sh || LT_AT_LIBTOOLIZE([--copy])
-test -f ./configure || _lt_pkgdatadir=$abs_top_srcdir autoreconf --force
--verbose --install || exit 1
+test -f ./configure || _lt_pkgdatadir=$abs_top_srcdir ${AUTORECONF} --force
--verbose --install || exit 1
test -f ./configure || exit 1
./configure
])
annoying build environment
CVS HEAD Is there any reason not to have ltmain.in in the source tree at configure time and generate ltmain.sh (from ltmain.in) in the build tree? I have UnixWare, OpenServer, Solaris and Linux (each with multiple versions) here. I prefer to build from a NFS read-only source tree so I can test whatever change I make on multiple platforms while having to maintain only 1 source tree. I'd like to be able to make a change in the source tree, run bootstrap, then cd /some/build/dir, configure, make and not have it try to generate some file in the source tree. We can't do this now. But is this possible with the current design of CVS HEAD? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool generated for tests
branch-1-5 Could someone explain why the libtool generated in the test dirs are different than the one in the build dir? Or more importanbtly, why a software package using ltmain.sh from 1.5.21a would build a libtool that didn't work but copying libtool from my libtool build dir would work. The differences looked similar to the ones below. --- depdemo/libtool 2005-09-26 16:03:23.949817104 -0700 +++ libtool 2005-09-26 15:57:57.144777437 -0700 @@ -1,7 +1,7 @@ #! /bin/ksh # libtoolT - Provide generalized library-building support services. -# Generated automatically by (GNU depdemo 0.1) +# Generated automatically by (GNU libtool 1.5.21a (1.1220.2.300 2005/09/25 07:37:09)) # NOTE: Changes made to this file will be lost: look at ltmain.sh. # # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 @@ -53,7 +53,7 @@ build_libtool_libs=yes # Whether or not to build static libraries. -build_old_libs=no +build_old_libs=yes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=no @@ -70,7 +70,7 @@ host_os=sysv5UnixWare7.1.4 # The build system. -build_alias=i686-unknown-sysv5UnixWare7.1.4 +build_alias= build=i686-unknown-sysv5UnixWare7.1.4 build_os=sysv5UnixWare7.1.4 @@ -159,10 +159,10 @@ need_version=no # Whether dlopen is supported. -dlopen_support=unknown +dlopen_support=yes # Whether dlopen of programs is supported. -dlopen_self=unknown +dlopen_self=no # Whether dlopen of statically linked programs is supported. dlopen_self_static=unknown @@ -6896,7 +6896,7 @@ build_libtool_libs=yes # Whether or not to build static libraries. -build_old_libs=no +build_old_libs=yes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=no @@ -6913,7 +6913,7 @@ host_os=sysv5UnixWare7.1.4 # The build system. -build_alias=i686-unknown-sysv5UnixWare7.1.4 +build_alias= build=i686-unknown-sysv5UnixWare7.1.4 build_os=sysv5UnixWare7.1.4 @@ -7002,10 +7002,10 @@ need_version=no # Whether dlopen is supported. -dlopen_support=unknown +dlopen_support=yes # Whether dlopen of programs is supported. -dlopen_self=unknown +dlopen_self=no # Whether dlopen of statically linked programs is supported. dlopen_self_static=unknown -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
branch-1-5 UnixWare fixes
I did some work on branch-1-5 to try and get libtool fully functional
on UnixWare 7.1.4. I was mostly successful, only the quote test fails.
Probably a ksh bug. As a side effect, OpenServer 6 (also SVR5) passes
all tests. While I was at it I cleaned up the earlier UnixWare releases
a little bit.
I'll look at forwared porting to CVS HEAD if I can figure out
why configure zeros out libltdl/config/ltmain.sh
Here are the before and after stats.
pre patch post patch
UnixWare 2.03 UnixWare 2.03
4 of 98 tests failed4 of 100 tests failed
(5 tests were not run) (3 tests were not run)
Please report to bug-libtool@gnu.orgPlease report to bug-libtool@gnu.org
UnixWare 7.1.1 UnixWare 7.1.1
7 of 94 tests failed6 of 96 tests failed
(9 tests were not run) (7 tests were not run)
Please report to bug-libtool@gnu.orgPlease report to bug-libtool@gnu.org
UnixWare 7.1.4 UnixWare 7.1.4
6 of 96 tests failed1 of 103 tests failed
(7 tests were not run) Please report to bug-libtool@gnu.org
Please report to bug-libtool@gnu.org
OpenServer 6OpenServer 6
13 of 101 tests failed All 103 tests passed
(2 tests were not run)
Please report to bug-libtool@gnu.org
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- libtool-1.5/libtool.m4.old 2005-09-09 08:56:16.0 -0700
+++ libtool-1.5/libtool.m4 2005-09-23 10:53:24.163558381 -0700
@@ -1655,7 +1655,7 @@
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.2uw2* | 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,6 +1688,19 @@
fi
;;
+sysv5*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $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
+ ;;
+
uts4*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
@@ -2314,11 +2327,11 @@
lt_cv_deplibs_check_method=pass_all
;;
-sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]*)
+sysv5*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.2uw2* | 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]]'
@@ -2339,10 +2352,13 @@
siemens)
lt_cv_deplibs_check_method=pass_all
;;
+ pc)
+lt_cv_deplibs_check_method=pass_all
+;;
esac
;;
-sysv4*uw2* | unixware7*)
+unixware7*)
lt_cv_deplibs_check_method=pass_all
;;
esac
@@ -3559,8 +3575,29 @@
;;
esac
;;
- sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7*)
-_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+ sysv5OpenUNIX8* | sysv5UnixWare7.[[01]].[[01]]* | sysv5uw[[78]]* |
unixware7*)
+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
+ ;;
+esac
+;;
+ sysv5*)
+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
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=':'
+ runpath_var
branch-1-5 case statement consistency
CVS branch-1-5 pulled Sun Sep 18 13:22:46 PDT 2005 Here is a patch to branch-1-5 that adds the missing ;; lines to some case statements. While having them gone does not cause any failures that I know of, it's nice to be consistent. It will apply with some fuzz. I pulled it out of a UnixWare patch I am working on. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] --- libtool-1.5/libtool.m4.old 2005-09-09 08:56:16.0 -0700 +++ libtool-1.5/libtool.m4 2005-09-21 19:51:42.556560012 -0700 @@ -2388,6 +2401,7 @@ continue # so that we can try to find one that supports BSD flags ;; esac +;; esac fi done @@ -2833,6 +2847,7 @@ ;; esac done + ;; esac exp_sym_flag='-bexport' @@ -2870,6 +2885,7 @@ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir' _LT_AC_TAGVAR(hardcode_libdir_separator, $1)= fi + ;; esac shared_flag='-shared' if test $aix_use_runtimelinking = yes; then @@ -3759,6 +3788,7 @@ _LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun' ;; esac + ;; esac ]) @@ -5488,6 +5525,7 @@ break fi done + ;; esac exp_sym_flag='-bexport' @@ -5525,6 +5563,7 @@ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir' _LT_AC_TAGVAR(hardcode_libdir_separator, $1)= fi + ;; esac shared_flag='-shared' if test $aix_use_runtimelinking = yes; then
