[SCM] GNU Libtool branch, master, updated. v2.2.6-99-g55b363f
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 55b363f2147638c3b5c78df264286863f23ff605 (commit)
from 7c483431f1026e5bbfedc18c369652bb96f9f8dd (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 55b363f2147638c3b5c78df264286863f23ff605
Author: Tim Rice t...@multitalents.net
Date: Sat Feb 28 14:12:03 2009 +0100
Fix C++ template handling for old archives on UnixWare 7.1.4.
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [sysv5*,
sco3.2v5*, sco5v6*] old_archive_cmds: For CC, add template
prelink step before archiving. Fixes template.at test failures.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
Summary of changes:
ChangeLog |7 +++
libltdl/m4/libtool.m4 |2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 022da07..9161d3f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2009-02-28 Tim Rice t...@multitalents.net
+
+ Fix C++ template handling for old archives on UnixWare 7.1.4.
+ * libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [sysv5*,
+ sco3.2v5*, sco5v6*] old_archive_cmds: For CC, add template
+ prelink step before archiving. Fixes template.at test failures.
+
2009-02-28 Török Edwin edwinto...@gmail.com (tiny change)
Ralf Wildenhues ralf.wildenh...@gmx.de
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index b75a55a..51e8910 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -6219,6 +6219,8 @@ if test $_lt_caught_CXX_error != yes; then
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~
+ '$_LT_TAGVAR(old_archive_cmds, $1)
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib
$libobjs $deplibs $compiler_flags'
hooks/post-receive
--
GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.2.6-100-g95f16dc
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 95f16dc1f658f0ff2a47d728e4b49cc90c1f09e3 (commit)
from 55b363f2147638c3b5c78df264286863f23ff605 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 95f16dc1f658f0ff2a47d728e4b49cc90c1f09e3
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date: Sat Feb 28 22:37:34 2009 +0100
Add missing parentheses in the manual.
* doc/libtool.texi (Distributing libltdl, Test descriptions):
Add missing parentheses.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
Summary of changes:
ChangeLog|5 +
doc/libtool.texi |4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 9161d3f..da9640a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2009-02-28 Ralf Wildenhues ralf.wildenh...@gmx.de
+
+ * doc/libtool.texi (Distributing libltdl, Test descriptions):
+ Add missing parentheses.
+
2009-02-28 Tim Rice t...@multitalents.net
Fix C++ template handling for old archives on UnixWare 7.1.4.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 0b35500..2f90ca3 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -4474,7 +4474,7 @@ unnecessary but makes it easy to forget to upgrade
@file{acinclude.m4}
if you move to a different release of libltdl.
@c
}. Having made the macros available, you must add a call to the
-...@samp{ltdl_init} macro (after the call to @samp{LT_INIT}
+...@samp{ltdl_init} macro (after the call to @samp{LT_INIT})
to your package's @file{configure.ac} to
perform the configure time checks required to build the library
correctly. Unfortunately, this method has problems if you then try to
@@ -5004,7 +5004,7 @@ static and shared libraries, @file{depdemo-static.test}
builds only static
libraries (@option{--disable-shared}), and @file{depdemo-shared.test} builds
only shared libraries (@option{--disable-static}).
@file{depdemo-nofast.test} configures @file{depdemo/libtool} to
-disable the fast-install mode (@option{--enable-fast-install=no}.
+disable the fast-install mode (@option{--enable-fast-install=no}).
@item mdemo-conf.test
@itemx mdemo-exec.test
hooks/post-receive
--
GNU Libtool
Re: bootstrap: CVS is history
Hello Andreas,
* Andreas Schwab wrote on Wed, Feb 18, 2009 at 05:44:41PM CET:
The libtool repository no longer uses CVS.
2009-02-18 Andreas Schwab sch...@suse.de
* bootstrap: Remove references to CVS.
Thanks for the patch. I went through the tree and removed remaining
references, resulting in this combined patch, pushed.
Cheers,
Ralf
2009-02-28 Andreas Schwab sch...@suse.de
Ralf Wildenhues ralf.wildenh...@gmx.de
Remove remaining references to CVS.
* bootstrap: Remove references to CVS.
* README.alpha: Likewise.
* clcommit.m4sh: Likewise.
* doc/libtool.texi: Bump copyright years.
(libtool script contents): Describe macro_revision as revision
without reference to CVS.
diff --git a/README.alpha b/README.alpha
index 2231630..903fafb 100644
--- a/README.alpha
+++ b/README.alpha
@@ -21,10 +21,9 @@ subject line including the string `[PLATFORM]'.
=
If this distribution doesn't work for you, before you report the
-problem, please try upgrading to the latest version from CVS first:
+problem, please try upgrading to the latest version from git first:
- export CVS_RSH=ssh
- cvs -z3 -d :pserver:anonym...@cvs.sv.gnu.org:/sources/libtool co libtool
+ git clone git://git.savannah.gnu.org/libtool.git
cd libtool
./bootstrap
@@ -115,7 +114,8 @@ send the file `tests/testsuite.log' to the bug report
mailing list,
bug-libt...@gnu.org.
--
- Copyright (C) 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009 Free Software
+ Foundation, Inc.
Written by Gary V. Vaughan, 2004
This file is part of GNU Libtool.
diff --git a/bootstrap b/bootstrap
index f8b44c1..0b3648f 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1,7 +1,7 @@
#! /bin/sh
-# bootstrap -- Helps bootstrapping libtool, when checked out from CVS.
+# bootstrap -- Helps bootstrapping libtool, when checked out from repository.
#
-# Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc,
+# Copyright (C) 2003, 2004, 2005, 2006, 2009 Free Software Foundation, Inc,
# Mritten by Gary V. Vaughan, 2003
#
# This file is part of GNU Libtool.
@@ -47,7 +47,7 @@ export SHELL
case $1 in
--help|-h*)
cat EOF
-`echo $0 | sed 's,^.*/,,g'`: This script is designed to bootstrap a fresh CVS
checkout
+`echo $0 | sed 's,^.*/,,g'`: This script is designed to bootstrap a fresh
repository checkout
of Libtool. Useful environment variable settings:
reconfdirs='. libltdl' Do not bootstrap the old test suite.
WORKING_LIBOBJ_SUPPORT=: Declare that you have fixed LIBOBJDIR support
@@ -149,7 +149,7 @@ rm -f Makefile
# Make a dummy libtoolize script for autoreconf:
cat $auxdir/libtoolize 'EOF'
#! /bin/sh
-# This is a dummy file for bootstrapping CVS libtool.
+# This is a dummy file for bootstrapping libtool.
echo $0: Bootstrap detected, no files installed. | sed 's,^.*/,,g'
exit 0
EOF
diff --git a/clcommit.m4sh b/clcommit.m4sh
index 73719cc..351076a 100644
--- a/clcommit.m4sh
+++ b/clcommit.m4sh
@@ -5,7 +5,7 @@ AS_INIT[]m4_divert_push([HEADER-COPYRIGHT])dnl
# Written by Gary V. Vaughan g...@gnu.org
# and Alexandre Oliva aol...@redhat.com
-# Copyright (C) 1999, 2000, 2004, 2006, 2008 Free Software Foundation, Inc.
+# Copyright (C) 1999, 2000, 2004, 2006, 2008, 2009 Free Software Foundation,
Inc.
# This is free software; see the source for copying conditions. There is NO
# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
@@ -52,7 +52,7 @@ AS_INIT[]m4_divert_push([HEADER-COPYRIGHT])dnl
# This script eases checking in changes to git-maintained projects
# with ChangeLog files. It will check that there have been no
-# conflicting commits in the CVS repository and print which files it
+# conflicting commits in the git repository and print which files it
# is going to commit to stderr. A list of files to compare and to
# check in can be given in the command line. If it is not given, all
# files in the current working directory are considered for check in.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 02340d9..0b35500 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -26,7 +26,7 @@
@ifnottex
This file documents GNU Libtool @value{VERSION}
-Copyright (C) 1996-2008 Free Software Foundation, Inc.
+Copyright (C) 1996-2009 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
@@ -53,7 +53,7 @@ identical to this one except for the removal of this paragraph
@page
@vskip 0pt plus 1filll
-Copyright @copyright{} 2008 Free Software Foundation, Inc.
+Copyright @copyright{} 2009 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the @sc{gnu} Free Documentation License, Version 1.3
@@ -5902,7 +5902,7 @@ linking.
@defvar
Re: Bug#517501: libtool: uninitialized shell variable causes link failure when run under zsh
tags fixed-upstream thanks [ adding libtool-patches; see http://bugs.debian.org/517501 ] OK, here's the deal: 'emulate sh' turns off the special properties of the $path array, but keeps its first entry: $ zsh -c 'echo $path.; emulate sh; echo $path.' /usr/local/bin /usr/bin /bin /usr/bin/X11 /usr/games /usr/X11R6/bin. /usr/local/bin. BTW, this doesn't happen if zsh is invoked as sh: $ ln -s /usr/bin/zsh sh; ./sh -c 'echo $path.; emulate sh; echo $path.' . . Not sure whether that may be considered a bug in zsh or not, but anyway libtool should not assume that the ordinary variable $path is unset. Your proposed patch does not set $path in all possible cases, so I'm applying this one to upstream GNU Libtool to fix it. Cheers, and thanks again, Ralf 2009-02-28 Török Edwin edwinto...@gmail.com (tiny change) Ralf Wildenhues ralf.wildenh...@gmx.de Do not add bogus directory arguments to link command lines. * libltdl/config/ltmain.m4sh (func_mode_link): Ensure $path is always initialized before it is used. Reported for zsh, for which $path contains $PATH entries even after emulate sh, see http://bugs.debian.org/517501. diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 49e07c3..7fcf4cb 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -5624,6 +5624,7 @@ func_mode_link () if test $link_all_deplibs != no; then # Add the search paths of all dependency libraries for deplib in $dependency_libs; do + path= case $deplib in -L*) path=$deplib ;; *.la)
Re: Bug#517501: libtool: uninitialized shell variable causes link failure when run under zsh
* Török Edwin wrote on Sat, Feb 28, 2009 at 01:49:27PM CET: Is there a release date planned for next libtool release? No. Well, maybe yes, but isn't there an empirical law like publishing the next planned release date will double the chance of it being missed? ;-) I would like to know if I should apply this patch to ClamAV's config/ltmain.sh, or wait until a new version of libtool is released (ClamAV's release is planned for March 16th). Given that you should not change the Libtool version used at the very last second to a fresh release, I'd suggest you apply this patch. Cheers, Ralf
Re: Bug#517501: libtool: uninitialized shell variable causes link failure when run under zsh
On 2009-02-28 14:29, Ralf Wildenhues wrote: tags fixed-upstream thanks [ adding libtool-patches; see http://bugs.debian.org/517501 ] OK, here's the deal: 'emulate sh' turns off the special properties of the $path array, but keeps its first entry: $ zsh -c 'echo $path.; emulate sh; echo $path.' /usr/local/bin /usr/bin /bin /usr/bin/X11 /usr/games /usr/X11R6/bin. /usr/local/bin. BTW, this doesn't happen if zsh is invoked as sh: $ ln -s /usr/bin/zsh sh; ./sh -c 'echo $path.; emulate sh; echo $path.' . . Not sure whether that may be considered a bug in zsh or not, but anyway libtool should not assume that the ordinary variable $path is unset. Your proposed patch does not set $path in all possible cases, so I'm applying this one to upstream GNU Libtool to fix it. Thanks. Is there a release date planned for next libtool release? I would like to know if I should apply this patch to ClamAV's config/ltmain.sh, or wait until a new version of libtool is released (ClamAV's release is planned for March 16th). Best regards, --Edwin
Re: cmdline_wrap.at
Hello Tim,
* Tim Rice wrote on Thu, Feb 26, 2009 at 01:50:27AM CET:
On Wed, 25 Feb 2009, Ralf Wildenhues wrote:
: * Tim Rice wrote on Mon, Feb 23, 2009 at 10:47:49PM CET:
:
: 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.
OK, thanks. I'm installing the patch like this, to avoid information
duplication here.
Still need to address John's reply. If anyone has a Portland Group
compiler installation available for testing (or even allows shell
access), I'd be delighted to hear about it. My evaluation license
(for 6.0) has long since expired ...
Cheers,
Ralf
2009-02-28 Tim Rice t...@multitalents.net
Fix C++ template handling for old archives on UnixWare 7.1.4.
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [sysv5*,
sco3.2v5*, sco5v6*] old_archive_cmds: For CC, add template
prelink step before archiving. Fixes template.at test failures.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index b75a55a..51e8910 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -6219,6 +6219,8 @@ if test $_lt_caught_CXX_error != yes; then
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~
+ '$_LT_TAGVAR(old_archive_cmds, $1)
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib
$libobjs $deplibs $compiler_flags'
Re: cmdline_wrap.at
Hello John, Tim,
* John Wolfe wrote on Thu, Feb 26, 2009 at 07:38:41PM CET:
Happy to contribute where I can. Sorry to not get back to you sooner:
I actually spent an evening away from the computer.
No problem at all of course.
[ snip explanations ]
All that is probably more than you want to know, but it does high-light the
fact that once the object file is disassociated from its directory or
original name, and by implication it's .ti and .ii file, it becomes
impossible for any prelink run to successfully recreate an object
module if needed later to resolve a needed instantiation.
ACK. Actually, thank you for the detailed explanations, they really
help. I have one question left:
relocatable objects: This, like archives, must have a prelink phase forced
before
using the linker to create a relocatable object from C++
object files containing template references that may
be undefined.
So for the specific example below
: Can you show how it would need to work? If libtool reloads
: a.o b.o c.o - libfoo-1.o
CC -Tprelink_objects a.o b.o c.o
/bin/ls -r a.o b.o c.o -o libfoo-1.o
: d.o e.o f.o libfoo-1.o - libfoo-2.o
CC -Tprelink_objects d.o e.o f.o libfoo.-1.o
# libfoo-1.o included allows templates already
# instantiated in the previous step to be seen
# and reused.
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?
Anyway, I think the patch below should implement this (and add John to
THANKS). Can you try it? Thanks.
/bin/ld d.o e.o f.o libfoo-1.o -o libfoo-2.o
: and links
: g.o libfoo-2.o - libfoo.la
CC -G g.o libfoo-2.o ...
# CC will run the prelink on g.o if needed.
I noticed that libtool.m4 has sections for the Portland Group C++ compiler.
They like USL/SCO make use of the Edison Design Group C++ compiler frontend.
Notice their use of the C++ compiler option --prelink_objects. I do not
know the details of their implementation, but given the fact that they must
force the template instantiation prelink phase for everything, they must not
be doing an automatic template instantiation. However, I strongly suspect
that they too are FAILing the C++ template test(s) in cmdline_wrap_at.
I remember vaguely to have tested at least the normal template tests
back then; but at the time of
| commit 652709d6887c0bfaf227fdd6ec31523f5e9bd99b
| Author: Ralf Wildenhues ralf.wildenh...@gmx.de
| Date: Thu Apr 7 17:58:26 2005 +
|
| Improved Portland support: prelinking of C++ templates and whole_archive.
the cmdline_wrap test did not exist yet, so assuming it's broken is
sensible. ;-)
Note to self: our testsuite should test reloadable object creation with
C++ and templates.
Cheers,
Ralf
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.
* THANKS: Update.
Report and analysis by Tim Rice and John Wolfe.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 7fcf4cb..fd5b1c7 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -6923,17 +6923,19 @@ EOF
# 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 @@ EOF
#
Document INNER_TESTSUITEFLAGS, drop leading space
Hello, I found this very helpful while debugging the template test inside the low max_cmd_len test. Any reasons against applying it? Thanks, Ralf 2009-02-28 Ralf Wildenhues ralf.wildenh...@gmx.de Document INNER_TESTSUITEFLAGS, drop leading space. * README: Document INNER_TESTSUITEFLAGS. * tests/cmdline_wrap.at (Run tests with low max_cmd_len): When using INNER_TESTSUITEFLAGS on the testsuite invocation, drop leading space after -k libtool, so that the user may further limit the set of tests to be run. diff --git a/README b/README index 2bffd27..612699e 100644 --- a/README +++ b/README @@ -104,6 +104,15 @@ possible to test an installed script, possibly from a different Libtool release, with gmake check-local TESTSUITEFLAGS=-k libtool LIBTOOL=/path/to/libtool +Some tests, like the one exercising max_cmd_len limits, make use of this +to invoke the testsuite recursively on a subset of tests. For these +tests, the variable INNER_TESTSUITEFLAGS may be used. It will be +expanded right after the `-k libtool', without separating whitespace, +so that further limiting of the recursive set of tests is possible. +For example, to run only the template tests within the max_cmd_len, use + gmake check-local TESTSUITEFLAGS=-v -x -k max_cmd_len \ + INNER_TESTSUITEFLAGS=',template -v -x' + If you wish to report test failures to the libtool list, you need to send the file `tests/testsuite.log' to the bug report mailing list, bug-libt...@gnu.org. @@ -165,7 +174,8 @@ For more details about version numbers, see: http://www.gnu.org/software/libtool/contribute.html -- - Copyright (C) 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. + Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009 Free Software + Foundation, Inc. Written by Gary V. Vaughan, 2004 This file is part of GNU Libtool. diff --git a/tests/cmdline_wrap.at b/tests/cmdline_wrap.at index 0c47db8..13edabc 100644 --- a/tests/cmdline_wrap.at +++ b/tests/cmdline_wrap.at @@ -1,6 +1,6 @@ # cmdline_wrap.at -- run tests with low max_cmd_len -*- Autotest -*- -# Copyright (C) 2007 Free Software Foundation, Inc. +# Copyright (C) 2007, 2009 Free Software Foundation, Inc. # Written by Ralf Wildenhues, 2007 # # This file is part of GNU Libtool. @@ -40,7 +40,7 @@ mkdir tests cd tests INNER_TESTSUITEFLAGS=$INNER_TESTSUITEFLAGS abs_top_srcdir=$abs_top_srcdir \ abs_builddir=$abs_builddir -AT_CHECK([$CONFIG_SHELL $abs_srcdir/testsuite -k libtool $INNER_TESTSUITEFLAGS], +AT_CHECK([$CONFIG_SHELL $abs_srcdir/testsuite -k libtool$INNER_TESTSUITEFLAGS], [], [ignore], [ignore]) AT_CLEANUP
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: [PATCH] Make compilation of preloaded module glue -Wstrict-prototypes clean
Hello Lennart, all,
* Lennart Poettering wrote on Sat, Feb 21, 2009 at 04:10:37AM CET:
When generating the glue code for preloaded modules libtool produces
invalid prototypes without argument lists. When compiling with
slightly fascist compiler options (-Wstrict-prototypes) this has the
effect of causing gcc to print gazillions of warnings when the final
libtool call is done -- for each symbol one.
The fix is trivial. The prototypes should have an argument list of void,
not empty.
Thanks for the bug report and patch. My issue here is the following:
AFAIK the extern int function (); declares a function with an
unspecified number of parameters, rather than one with no parameters.
Now, I don't know whether this has an effect on the generated code
(on some weird system), since of course the thus-declared functions
do not really have zero parameters. If somebody knows this better,
please speak up! (Of course us assigning the pointer to such function
to a pointer to void is another ISO C violation in this area, but
let's not get more ambitious than necessary right now.)
Since the code in typical configure link tests like AC_CHECK_LIB or
AC_CHECK_FUNC uses the same idiom, I'm inclined to leave the code the
way it is, and argue that you should not use -Wstrict-prototypes, at
least not in conjunction with -Werror (as that could also cause bogus
configure results). What we could do, however, would be to remove
any occurrence of -Wstrict-prototypes from the LTCC libtool variable
to avoid the noise during the build. In that case, I suppose it would
be prudent to also drop alike flags for other compilers we care about.
Cheers,
Ralf
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3308,7 +3308,7 @@ esac
# Transform an extracted symbol line into a proper C declaration.
# Some systems (esp. on ia64) link data and code symbols differently,
# so use this general approach.
-lt_cv_sys_global_symbol_to_cdecl=sed -n -e 's/^T .* \(.*\)$/extern int
\1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'
+lt_cv_sys_global_symbol_to_cdecl=sed -n -e 's/^T .* \(.*\)$/extern int
\1(void);/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'
# Transform an extracted symbol line into symbol name and symbol address
lt_cv_sys_global_symbol_to_c_name_address=sed -n -e 's/^: \([[^ ]]*\) $/
{1\\\, (void *) 0},/p' -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/
{\\2\, (void *) \\2},/p'
Re: Suppressing --whole-archive
* Barthelemy von Haller wrote on Fri, Feb 27, 2009 at 04:46:32PM CET: Hi again, sorry the second attachment was wrong. Here is the correct one. Yep, thanks. It also shows that I forgot to ask a more basic question first: namely, which libtool version is was. The log shows that it's 1.5.6. This is very old. The corresponding code has changed since, and the code that would expand to this whole-archive bit has gone. I would urge you to please use a newer libtool, or ask the maintainers of the package you're using to rebootstrap it with a newer version. Current Libtool is 2.2.6a. FWIW, the bug has been fixed in 1.5.20, with commit a02e5b87b812205f06e54cb0a06baaacbc815245 Author: Peter O'Gorman pe...@... Date: Tue May 31 03:47:34 2005 + * ltmain.in: Do not add installed static litool libraries to convenience, they are not convenience libraries. Reported by Chen-Mou Cheng chenmou.ch...@gmail.com diff --git a/ltmain.in b/ltmain.in index 6d6eb18..be7c7a5 100644 --- a/ltmain.in +++ b/ltmain.in @@ -2729,8 +2729,6 @@ EOF fi fi else - convenience=$convenience $dir/$old_library - old_convenience=$old_convenience $dir/$old_library deplibs=$dir/$old_library $deplibs link_static=yes fi Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking together .dll using .a static libraries
* Roumen Petrov wrote on Fri, Feb 27, 2009 at 10:07:19PM CET: LRN wrote: OK, maybe it's a stupid question, but i have to ask anyway. MinGW ships some static .a libraries. How do i link these to shared .dll libraries? It seems that libtool always performs a check (filemagic in my case) on each -lname argument, and to pass that check the library has to be x86 archive import or x86 DLL, but not x86 archive static. Some of those libraries are always linked as example mingwex. Which libraries are this exactly (for various MinGW versions), and are any of these import libs? For the non-import default-linked ones, we should probably add exceptions to libtool to accept them, but I'm not sure whether that is the right thing here. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cmdline_wrap.at
Hello Tim,
* Tim Rice wrote on Thu, Feb 26, 2009 at 01:50:27AM CET:
On Wed, 25 Feb 2009, Ralf Wildenhues wrote:
: * Tim Rice wrote on Mon, Feb 23, 2009 at 10:47:49PM CET:
:
: 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.
OK, thanks. I'm installing the patch like this, to avoid information
duplication here.
Still need to address John's reply. If anyone has a Portland Group
compiler installation available for testing (or even allows shell
access), I'd be delighted to hear about it. My evaluation license
(for 6.0) has long since expired ...
Cheers,
Ralf
2009-02-28 Tim Rice t...@multitalents.net
Fix C++ template handling for old archives on UnixWare 7.1.4.
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [sysv5*,
sco3.2v5*, sco5v6*] old_archive_cmds: For CC, add template
prelink step before archiving. Fixes template.at test failures.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index b75a55a..51e8910 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -6219,6 +6219,8 @@ if test $_lt_caught_CXX_error != yes; then
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~
+ '$_LT_TAGVAR(old_archive_cmds, $1)
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib
$libobjs $deplibs $compiler_flags'
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: cmdline_wrap.at
Hello John, Tim,
* John Wolfe wrote on Thu, Feb 26, 2009 at 07:38:41PM CET:
Happy to contribute where I can. Sorry to not get back to you sooner:
I actually spent an evening away from the computer.
No problem at all of course.
[ snip explanations ]
All that is probably more than you want to know, but it does high-light the
fact that once the object file is disassociated from its directory or
original name, and by implication it's .ti and .ii file, it becomes
impossible for any prelink run to successfully recreate an object
module if needed later to resolve a needed instantiation.
ACK. Actually, thank you for the detailed explanations, they really
help. I have one question left:
relocatable objects: This, like archives, must have a prelink phase forced
before
using the linker to create a relocatable object from C++
object files containing template references that may
be undefined.
So for the specific example below
: Can you show how it would need to work? If libtool reloads
: a.o b.o c.o - libfoo-1.o
CC -Tprelink_objects a.o b.o c.o
/bin/ls -r a.o b.o c.o -o libfoo-1.o
: d.o e.o f.o libfoo-1.o - libfoo-2.o
CC -Tprelink_objects d.o e.o f.o libfoo.-1.o
# libfoo-1.o included allows templates already
# instantiated in the previous step to be seen
# and reused.
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?
Anyway, I think the patch below should implement this (and add John to
THANKS). Can you try it? Thanks.
/bin/ld d.o e.o f.o libfoo-1.o -o libfoo-2.o
: and links
: g.o libfoo-2.o - libfoo.la
CC -G g.o libfoo-2.o ...
# CC will run the prelink on g.o if needed.
I noticed that libtool.m4 has sections for the Portland Group C++ compiler.
They like USL/SCO make use of the Edison Design Group C++ compiler frontend.
Notice their use of the C++ compiler option --prelink_objects. I do not
know the details of their implementation, but given the fact that they must
force the template instantiation prelink phase for everything, they must not
be doing an automatic template instantiation. However, I strongly suspect
that they too are FAILing the C++ template test(s) in cmdline_wrap_at.
I remember vaguely to have tested at least the normal template tests
back then; but at the time of
| commit 652709d6887c0bfaf227fdd6ec31523f5e9bd99b
| Author: Ralf Wildenhues ralf.wildenh...@gmx.de
| Date: Thu Apr 7 17:58:26 2005 +
|
| Improved Portland support: prelinking of C++ templates and whole_archive.
the cmdline_wrap test did not exist yet, so assuming it's broken is
sensible. ;-)
Note to self: our testsuite should test reloadable object creation with
C++ and templates.
Cheers,
Ralf
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.
* THANKS: Update.
Report and analysis by Tim Rice and John Wolfe.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 7fcf4cb..fd5b1c7 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -6923,17 +6923,19 @@ EOF
# 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 @@ EOF
#
Re: Crosscompiling fails since Gstreamer moved to new libtool version
Hello Andreas, Richard,
* Richard Purdie wrote on Thu, Feb 26, 2009 at 02:58:25PM CET:
On Thu, 2009-02-26 at 14:16 +0100, Andreas Frisch wrote:
the guys from gstreamer went through and moved to a newer libtool
version in their plugin packages. since then i can't crosscompile
anymore them with openembedded like with the previous releases. i
described the problem here:
http://bugzilla.gnome.org/show_bug.cgi?id=572532
unfortunately, none of the gstreamer guys as able to help me with this
libtool-specific issue. i found out that the main libtool code moved
out of aclocal.m4 into a new file libtool.m4 in the m4 subdir of the
source directory. i couldn't get configure to create the
mipsel-linux-libtool instead of regular libtool though, not even by
changing the line default_ofile=${host_alias}-libtool.
maybe any of you can give me hint how i could solve my issue - thanks
in advance!
As a warning the creation of mipsel-linux-libtool is an OpenEmbedded
specific patch and I'd suspect is not supported by libtool upstream.
Which version of libtool are you using in OpenEmbedded?
For reference in Poky, the gstreamer recipes have:
do_configure_prepend() {
# This m4 file contains nastiness which conflicts with libtool 2.2.2
rm ${S}/m4/lib-link.m4 || true
}
suggesting there was something in that m4 file that caused problems.
All of the above, and the information in the referenced bugzilla,
still leave me scratching my head. I cannot tell whether this is a
bug in Libtool, a bug in some package that uses or modifies Libtool
code, and I cannot tell whether lib-link.m4 (from gnulib/gettext?)
has a bug or conflict with Libtool 2.2.x.
One way to shed light that is often good is to provide a recipe to
reproduce the problem, including how to build the packages involved.
Please take into account that I don't have gstreamer development
tools installed, nor know know openembedded. I do have a Debian
lenny available, and (a pointer to) instructions on how to get the
corresponding sources and build them would be appreciated.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
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: Linking together .dll using .a static libraries
Ralf Wildenhues wrote:
* Roumen Petrov wrote on Fri, Feb 27, 2009 at 10:07:19PM CET:
LRN wrote:
OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check (filemagic in
my case) on each -lname argument, and to pass that check the library has
to be x86 archive import or x86 DLL, but not x86 archive static.
Some of those libraries are always linked as example mingwex.
Which libraries are this exactly (for various MinGW versions), and are
any of these import libs?
quote for gcc spec file:
==
*lib:
%{pg:-lgmon} %{mwindows:-lgdi32 -lcomdlg32} -luser32 -lkernel32
-ladvapi32 -lshell32
*libgcc:
%{mthreads:-lmingwthrd} -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
==
- mingwthrd: import, specific
- mingw32: static
- moldname: import (for functions without underscore)
- mingwex: static
- msvcrt+other xx*32: import (runtime)
mingwex is a specific extension. As example library add float and long
double functions missing in msvcrt. Version 3.15 (3.14 ?) add posix
compatible IO.
For the non-import default-linked ones, we should probably add
exceptions to libtool to accept them, but I'm not sure whether
that is the right thing here.
Thanks,
Ralf
Roumen
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: ltdl weirdness
Hello Matěj, to add to Bob's reply: * Bob Friesenhahn wrote on Mon, Feb 23, 2009 at 07:50:03PM CET: On Mon, 23 Feb 2009, Matěj Týč wrote: Next, if the executable is compiled with -export-dynamic, things that were compiled in really provide symbols that would be missing in the module. However, things that were linked in as external libs don't seem to be exported. Is this expected behaviour? However, there is a Yes, this is now the expected behavior. Older libltdl allowed libraries required by loaded modules and module symbols to become part of the global namespace. As of libtool 2.2.X, this is no longer the default. But also, new API has been added that allows to dlopen with global symbol visibility (which I think the above is referring to). Quoting NEWS: - New lt_dlopenadvise takes a new lt_dladvise type argument, which lets the caller request local or global symbol visibility from the module loader with lt_dladvise_local and lt_dladvise_global respectively. If neither is given, or if lt_dlopen (or lt_dlopenext) are called, then the system default module symbol visibility is used. See the manual for details. difference between having nothing and between having linked external symbols in executable compiled using -export-dynamic flag -- the first case results in the inability to open the module (see the first problem), whereas the latter results in runtime error. Any suggestions regarding good practices? It is necessary for all symbols to be already available in the using program or library, or referenced by the module as a dependency, when the module is loaded. Yes. For portability to some (non-ELF) systems, it may even be necessary that all module symbol references be fulfilled at module creation time. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cmdline_wrap.at
[ let's drop libtool@ from replies ]
* Tim Rice wrote on Sat, Feb 28, 2009 at 07:37:47PM CET:
On Sat, 28 Feb 2009, Ralf Wildenhues wrote:
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.
Yep. Updated patch below.
Thanks for testing and the quick feedback,
Ralf
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.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 7fcf4cb..fd5b1c7 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -6923,17 +6923,19 @@ EOF
# 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 @@ EOF
# 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
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 51e8910..78f43f9 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2888,8 +2888,8 @@ case $host_os in
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_cmds, $1)=
_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 @@ if test $_lt_caught_CXX_error != yes; then
_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~$CC
-r -o $output$reload_objs'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib
$libobjs $deplibs $compiler_flags'
@@ -6555,6 +6558,8 @@ _LT_TAGVAR(module_cmds, $1)=
_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)=
