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: [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
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, 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 AT&T 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: [PATCH] Enable runtime cwrapper debugging; add tests
On Mon, 14 Dec 2009, Charles Wilson wrote: > Two related lines of inquiry: > 1) Under *normal* development rules -- e.g not a pre-release > bug-fix-only phase, nor a not-quite-pre-release code slush like (I > think) we're in right now, for 2.2.8 -- surely you aren't suggesting > that EVERY contribution must be validated on EVERY platform, prior to > push? These were tested on cyg/ming and linux, so in general, during > /normal/ development, that should be sufficient contra reveiwer > comments, right? I would strongly advocate testing at least one System V based system. Non bash shells sometimes have issues. -- 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
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*] : For CC, invoke prelinker
before creating reloadable object.
(_LT_CMD_RELOAD) : Declare as
_LT_TAGDECL, not _LC_DECL.
(_LT_LANG_CXX_CONFIG, _LT_LANG_F77_CONFIG, _LT_LANG_FC_CONFIG)
(_LT_LANG_GCJ_CONFIG) : 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, $
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: 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
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: 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: 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: 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: Building CVS HEAD libtool outside of source directory
On Wed, 17 Oct 2007, Bob Friesenhahn wrote: > On Thu, 18 Oct 2007, Ralf Wildenhues wrote: > > > > > The VPATH build is quite useful for libtool, particularly given that > > > 'make clean' and 'make distclean' do not work unless the testsuite has > > > been successfully run. > > > > Could you elaborate on that? How can I reproduce non-working 'make > > clean'? > > I am not sure if the problem still exists. For a number of years it was not > possible since the Makefiles in the test subdirectories were broken or did not > exist. Or perhaps the problem was lmited to 'make distclean'. 'make distclean' has had problems with VPATH builds because of a deficency in automake (at least 1.9.6). If you ran 'make distclean' before running the test suite some directories would be missing causing an error. This patch fixes it. ... --- automake-1.9.6/lib/am/subdirs.am.old2005-05-14 13:21:06.0 -0700 +++ automake-1.9.6/lib/am/subdirs.am2005-10-27 21:04:01.460314004 -0700 @@ -93,7 +93,7 @@ esac; \ rev=''; for subdir in $$list; do \ if test "$$subdir" = "."; then :; else \ - rev="$$subdir $$rev"; \ + test -d "$$subdir" && rev="$$subdir $$rev"; \ fi; \ done; \ ## Always do `.' last. ... I bug reported it in Oct 2005 so it may be fixed by now. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: preparing for 1.5.24
On Sun, 11 Feb 2007, Ralf Wildenhues wrote: > Hello libtoolers, > > I would like to release 1.5.24 as soon as possible. I've flushed my > queue now, except for the patch I just posted and whatever w32 changes > are still needed. > > To ensure that there are no regressions, I would like to announce a sort > of prerelease. To make things simple, the easiest would be for me to Looks good on UnixWare 7.1.1 & 7.1.4, OpenServer 5.0.7
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: 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 2>&1 > > = 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: Hi Ralf, > > And how it looks on my platforms. > > http://www.multitalents.net/head-status.html > > this is quite interesting to see, but it really would be much more > interesting to see the VERBOSE=x failures for the old suite tests, > and $top_builddir/tests/testsuite.log for the new suite tests. Done. Check it out now. Thanks for looking at this. > > Don't bother HTMLizing the output if you don't have to, and I suggest a > rerun should wait for my pending testsuite update patch; it hopefully > fixes a lot of the failures you are seeing. Testing your patch was next on my list. :-) -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
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*
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 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=detailitem&item_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] PLTSZ 0x48 [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/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=detailitem&item_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 5 of 10: ltmain.in: exclude -lc on SCO platforms
On Fri, 4 Nov 2005, Ralf Wildenhues wrote: > Is gettext the only package that exposes this? Could you be bothered > to write a bug report (or have already done so)? I don't know if gettext is the only one or not. I just sent a patch to [EMAIL PROTECTED] > > > Any reason this patch has not been added to CVS yet? > > Except above reasons, time for review is finite. ;) ^ That reason is always acceptable to me on volunteer projects. :-) > > Cheers, > Ralf > > -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: SCO/buffix patch 6 of 10: AC_PROG_NM fixes
On Wed, 2 Nov 2005, Ralf Wildenhues wrote: > Hi Kean, > > * Kean Johnston wrote on Tue, Nov 01, 2005 at 05:56:58PM CET: > > > > >>>nm -B /dev/null > > >>>on SCO output, by the way? Maybe we can adjust the old scheme to that? > > >> > > >>A usage message becuase it doesn't support -B, but it does > > >>support -p. > > > > > >Care to cut and paste it? Thanks. What's the return value? > > keats:~% /usr/ccs/bin/elf/nm -B /dev/null > > /usr/ccs/bin/elf/nm: ERROR: Illegal option -- B > > i386/usr/ccs/bin/elf/nm: Usage: i386/usr/ccs/bin/elf/nm [-?CVhnopruvx] > > file(s) . > *snip* > > OK. What's the output with -p? UnixWare 7.1.4, OpenServer 6 UX:nm: ERROR: illegal file type: /dev/null UnixWare 2.03, UnixWare 7.1.1, OpenServer 5.0.4, OpenServer 5.0.7 nm: /dev/null: invalid file type -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
On Sun, 30 Oct 2005, Kean Johnston wrote: Kean Johnston wrote: > Patch 5 of 10 attached ... Tim caught a small ommission. A corrected patch is attached. Any reason this patch has not been added to CVS yet? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] Rationale: On some releases of OpenServer 5, libc was poorly constructed and had static versions of __ctype. Due to a bug with copy relocations, linking a shared library with -lc would result in a shared library having one notion of __ctype, and the a.out having another. Thus, things like atoi() would behave differently inside the shared library versus the a.out. This is really bad. Also, there is no need to link in -lc, as it is always loaded by definition, as that is the RTLD and you cant have any form of dynamic ELF program without it. On OpenServer 6 and UnixWare, explicitly linking with -lc is even worse. The threads library is constructed in such a way that it provides several of the same functions that appear in libc. The version for libthread.so are the real, threads-safe versions. The versions that are in libc are stub versions that are present to allow programs to link, while still using simpler versions of things like mutexes and condition variables. In order for threads to work correctly, libc *must* be the very last library in the load order, so that those symbols that need it are resolved out of the threads library. If you explicitly link with -lc when creating a shared library, then libc is processed as a dependency when the shared library is loaded, and appears too early in the dependency chain. 2005-10-24 Kean Johnston <[EMAIL PROTECTED]> * ltmain.in(*-*-sco3.2v5*): Dont pass through -lc. (*-*-sysv5*): Ditto. Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.91 diff -u -3 -p -r1.334.2.91 ltmain.in --- ltmain.in 18 Oct 2005 07:26:05 - 1.334.2.91 +++ ltmain.in 30 Oct 2005 21:22:25 - @@ -1494,6 +1495,15 @@ EOF # Rhapsody C and math libraries are in the System framework deplibs="$deplibs -framework System" continue + ;; + *-*-sco3.2v5* | *-*-sco5v6*) + # Causes problems with __ctype + test "X$arg" = "X-lc" && continue + ;; + *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*) + # Compiler inserts libc in the correct place for threads to work + test "X$arg" = "X-lc" && continue + ;; esac elif test "X$arg" = "X-lc_r"; then case $host in
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 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(ar
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: UnixWare -lc fixes
On Tue, 18 Oct 2005, Albert Chin wrote: > On Mon, Oct 17, 2005 at 09:53:29PM -0700, Tim Rice wrote: > > 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 5&6 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. I forgot to mention, credit for these patches should relly go to Kean Johnston. > > Ick. Packages like gettext need to be fixed, not libtool. Garbage in = > Garbage out. This has obviously come up before. There is already code there for openbsd/freebsd and others. I'm just adding a couple of platforms. While it would be nice if all the "broken" packages out there were fixed, it probably won't happen without libtool issuing a big warning message when it is invoked with "libtool ...some_options -lc ...some_mode_options". And now a question. Looking at libltdl/config/ltmain.m4sh, the code in the area I patched (about line 2600) seems to be duplicated down at about line 4500. I'm trying to understand why the netbsd and openbsd cases are there. I would expect that they have build_libtool_need_lc=no and those 2 cases would to nothing. Or is that just cruft? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
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 5&6 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@
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
+ : 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
])
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 : 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: 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 $com
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 Sun, Sep 25, 2005 at 10:05:21PM CEST:
: > On Sun, 25 Sep 2005, Ralf Wildenhues wrote:
: > : * Tim Rice wrote on Fri, Sep 23, 2005 at 10:20:29PM 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
:
: Please post the failing output of
: make check TESTS=quote.test VERBOSE=x
:
: Thank you.
---< begin "make check TESTS=quote.test VERBOSE=x" >
[EMAIL PROTECTED] 14% gmake check TESTS=quote.test VERBOSE=x
Making check in .
gmake[1]: Entering directory `/usr/local/src/gnu/libtool-1.5/build'
gmake[1]: Nothing to be done for `check-am'.
gmake[1]: Leaving directory `/usr/local/src/gnu/libtool-1.5/build'
Making check in libltdl
gmake[1]: Entering directory `/usr/local/src/gnu/libtool-1.5/build/libltdl'
gmake[1]: Leaving directory `/usr/local/src/gnu/libtool-1.5/build/libltdl'
Making check in doc
gmake[1]: Entering directory `/usr/local/src/gnu/libtool-1.5/build/doc'
gmake[1]: Nothing to be done for `check'.
gmake[1]: Leaving directory `/usr/local/src/gnu/libtool-1.5/build/doc'
Making check in tests
gmake[1]: Entering directory `/usr/local/src/gnu/libtool-1.5/build/tests'
gmake check-TESTS
gmake[2]: Entering directory `/usr/local/src/gnu/libtool-1.5/build/tests'
=== Running quote.test
== compile mode
= trying: no quoting
= passed: 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 2>&1
= 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 2>&1
= 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 2>&1
= 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 2>&1
= 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 2>&1
= trying: "[" quoting
= passed: 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 2>&1
= trying: "]" quoting
= passed: 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 2>&1
= trying: "~" quoting
= passed: 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 2>&1
= trying: "#" quoting
= passed: 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 2>&1
= trying: "^" quoting
= passed: 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 2>&1
= trying: "&" quoting
= passed: 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 2>&1
= trying: "*" quoting
= passed: 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 2>&1
= trying: "(" quoting
= passed: 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 2>&1
= trying: ")" quoting
= passed: 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 2>&1
= trying: "{" quoting
= passed: 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 2>&1
= trying: "}" quoting
= passed: 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 2>&1
= trying: "|" quoting
= passed: 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 2>&1
= trying: ";" quoting
= passed: 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 2>&
alternate names for autom4te
CVS HEAD
Here is a small patch to configure.ac to allow
AUTOM4TE=/opt/bin/autom4te259 /some/path/to/configure .
(solved my "106 of 106 tests failed" problem) ;-)
--- configure.ac.old2005-08-29 06:58:07.0 -0700
+++ configure.ac2005-09-25 13:39:25.645733007 -0700
@@ -37,7 +37,7 @@
## ##
AC_CONFIG_TESTDIR([tests])
-AC_SUBST([AUTOM4TE], [autom4te])
+AC_SUBST([AUTOM4TE], [${AUTOM4TE=autom4te}])
AC_SUBST([AUTOTEST], ['$(AUTOM4TE) --language=autotest'])
--------
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
Re: branch-1-5 UnixWare fixes
On Sun, 25 Sep 2005, Ralf Wildenhues wrote:
: Hi Tim,
:
: * Tim Rice wrote on Fri, Sep 23, 2005 at 10:20:29PM CEST:
: >
: > 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.
:
: Which of the quote test lines fail? Did you run the test in a new build
: tree or did you ever re-configure (there is a bug in branch-1-5 wrt.
Always a fresh build tree.
: setting $SHELL correctly on a config.status-induced configure rerun. If
: in doubt retry with a new build tree)
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
:
: > 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.
:
: Hmm. While the improvements look really good, and I know virtually
: nothing about the systems in question, I still have a couple of
: comments. It would be nice if you could take a look, see below.
:
: Thanks!
: Ralf
:
: Content-Description: branch-1-5-uw.patch
[snip]
: > @@ -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*)
:
: 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.
It could be cleanded up further by having "sysv5* | unixware7*)".
(UnixWare 7 is sysv5)
I assume that unixware7* is in there for backward compatibility for
some old config.guess.
:
: >lt_cv_deplibs_check_method=pass_all
: >;;
: > esac
[snip]
: > @@ -5404,7 +5448,7 @@
: >fi
: >;;
: >
: > -solaris* | sysv5*)
: > +solaris*)
:
: Any reason for this change?
Oops, that's one of the things I tried that didn't make any difference.
Best to leave that in for now.
:
: >if $LD -v 2>&1 | grep 'BFD 2\.8' > /dev/null; then
: > _LT_AC_TAGVAR(ld_shlibs, $1)=no
: > cat <&2
: > @@ -5966,27 +6010,30 @@
: >runpath_var=LD_RUN_PATH
: >;;
: >
: > - sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7*)
: > +sysv5OpenUNIX8* | sysv5UnixWare7.[[01]].[[10]]* | sysv5uw[[78]]* |
unixware7*)
: >_LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z ${wl}text'
: >if test "$GCC" = yes; then
: > _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h ${wl}$soname -o
$lib $libobjs $deplibs $compiler_flags'
: >else
: > _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h ${wl}$soname -o $lib
$libobjs $deplibs $compiler_flags'
: >fi
: > + _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
: >runpath_var='LD_RUN_PATH'
: >_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
: >;;
: >
: > sysv5*)
: > - _LT_AC_TAGVAR(no_undefined_flag, $1)=' -z text'
: > - # $CC -shared without GNU ld will not create a library from C++
: > - # object files and a static libstdc++, better avoid it by now
: > - _LT_AC_TAGVAR(archive_cmds, $1)='$LD -G${allow_undefined_flag} -h
$soname -o $lib $libobjs $deplibs $linker_flags'
: > - _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" >
$lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo
"local: *; };" >> $lib.exp~
: > - $LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib
$libobjs $deplibs $linker_flags~$rm $lib.exp'
: > - _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
: > - _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
: > + _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z ${wl}text'
: > + if test "$GCC" = yes; then
: > + _LT_AC_TAGVAR(archive_cmds, $1)=&#
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_cm
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
