Re: cmdline_wrap.at
[ droping libtool@ from replies ]
Hi John, Ralf
On Sun, 1 Mar 2009, John Wolfe wrote:
Hi Ralf, Tim
Here I am playing catch up again.
At first look at the patch I have one concern and that may be what is
contributing to
the failures later reported in this thread.
- In the patch, I think the $CC -r should be $LD -r
Using the C++ compiler command to do the linking does not work! It will
begin to suck in
multiple copies of C++ startup runtime routines as you loop through the
link.
I wondered about that. Switching to $LD did the trick.
.
79 tests behaved as expected.
7 tests were skipped.
.
So after the minor change to Ralf's patch here is what we end up with.
- ChangeLog -
2009-02-28 Ralf Wildenhues ralf.wildenh...@gmx.de
Fix low max_cmd_len template test on UnixWare.
* libltdl/config/ltmain.m4sh (func_mode_link): When expanding
$reload_cmds, always put objects in $reload_objs rather than
adding them to the command line, to allow more general command
lines in reload_cmds. Ensure $reload_objs contains a leading
space.
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [sysv5*,
sco3.2v5*, sco5v6*] reload_cmds: For CC, invoke prelinker
before creating reloadable object.
(_LT_CMD_RELOAD) reload_cmds, reload_flag: Declare as
_LT_TAGDECL, not _LC_DECL.
(_LT_LANG_CXX_CONFIG, _LT_LANG_F77_CONFIG, _LT_LANG_FC_CONFIG)
(_LT_LANG_GCJ_CONFIG) reload_cmds, reload_flag: Initialize
from default (C tag) value.
* THANKS: Update.
Report and analysis by Tim Rice and John Wolfe.
- Begin patch -
--- libtool-2.x/libltdl/config/ltmain.m4sh.old 2009-02-28 10:00:56.0
-0800
+++ libtool-2.x/libltdl/config/ltmain.m4sh 2009-02-28 12:30:33.696970038
-0800
@@ -6923,17 +6923,19 @@
# command to the queue.
if test $k -eq 1 ; then
# The first file doesn't have a previous command to add.
- eval concat_cmds=\$reload_cmds $objlist $last_robj\
+ reload_objs=$objlist
+ eval concat_cmds=\$reload_cmds\
else
# All subsequent reloadable object files will link in
# the last one created.
- eval concat_cmds=\\$concat_cmds~$reload_cmds $objlist
$last_robj~\$RM $last_robj\
+ reload_objs=$objlist $last_robj
+ eval concat_cmds=\\$concat_cmds~$reload_cmds~\$RM
$last_robj\
fi
last_robj=$output_objdir/$output_la-${k}.$objext
func_arith $k + 1
k=$func_arith_result
output=$output_objdir/$output_la-${k}.$objext
- objlist=$obj
+ objlist= $obj
func_len $last_robj
func_arith $len0 + $func_len_result
len=$func_arith_result
@@ -6943,7 +6945,8 @@
# reloadable object file. All subsequent reloadable object
# files will link in the last one created.
test -z $concat_cmds || concat_cmds=$concat_cmds~
- eval concat_cmds=\\${concat_cmds}$reload_cmds $objlist
$last_robj\
+ reload_objs=$objlist $last_robj
+ eval concat_cmds=\\${concat_cmds}$reload_cmds\
if test -n $last_robj; then
eval concat_cmds=\\${concat_cmds}~\$RM $last_robj\
fi
--- libtool-2.x/libltdl/m4/libtool.m4.old 2009-02-28 10:00:56.0
-0800
+++ libtool-2.x/libltdl/m4/libtool.m4 2009-03-01 13:49:53.289834138 -0800
@@ -2888,8 +2888,8 @@
fi
;;
esac
-_LT_DECL([], [reload_flag], [1], [How to create reloadable object files])dnl
-_LT_DECL([], [reload_cmds], [2])dnl
+_LT_TAGDECL([], [reload_flag], [1], [How to create reloadable object files])dnl
+_LT_TAGDECL([], [reload_cmds], [2])dnl
])# _LT_CMD_RELOAD
@@ -5314,6 +5314,8 @@
_LT_TAGVAR(module_expsym_cmds, $1)=
_LT_TAGVAR(link_all_deplibs, $1)=unknown
_LT_TAGVAR(old_archive_cmds, $1)=$old_archive_cmds
+_LT_TAGVAR(reload_flag, $1)=$reload_flag
+_LT_TAGVAR(reload_cmds, $1)=$reload_cmds
_LT_TAGVAR(no_undefined_flag, $1)=
_LT_TAGVAR(whole_archive_flag_spec, $1)=
_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=no
@@ -6221,6 +6223,7 @@
_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G
${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs
$compiler_flags'
_LT_TAGVAR(old_archive_cmds, $1)='$CC -Tprelink_objects $oldobjs~
'$_LT_TAGVAR(old_archive_cmds, $1)
+ _LT_TAGVAR(reload_cmds, $1)='$CC -Tprelink_objects $reload_objs~$LD
-r -o $output$reload_objs'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib
$libobjs
Re: cmdline_wrap.at
Hi Ralf, 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. Responses and comments to individual sections embedded below. -- John Ralf Wildenhues wrote: 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? I guess that you could consider it an optimization. If a.o and d.o need the same template function(s), it/they would be generated the prelink of a.o. They would, therefore, already be in the libfoo-1.0. The prelink of d.o, without seeing the contents of libfoo-1.o, would also causes them to be generated in the d.o. The template functions are weak symbols, so not a problem when linking, but just a waste of .text space for the duplicate, but unused code.. Anyway, I think the patch below should implement this (and add John to THANKS). Can you try it? Thanks. Again, I believe the $CC -r need to be $LD -r It appears that I had a few typo's in my example before. -/bin/ls === /bin/ld -left the -r out of the 2nd /bin/ld command (below) My apologies for any confusion. /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 [ snip preliminary patches] ___ 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'
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: cmdline_wrap.at
Hi Ralf, On Sat, 28 Feb 2009, Ralf Wildenhues wrote: [snip] Is this an optimization only, or a necessary thing? IOW, if I omit libfoo-1.0 in this CC -Tprelink_objects line, would that only pessimize link time, or could it affect the link result? I'll let John answer this Anyway, I think the patch below should implement this (and add John to THANKS). Can you try it? Thanks. The test still fails although the patch could be correct. It looks like this never makes it into the generated libtool. + _LT_TAGVAR(reload_cmds, $1)='$CC -Tprelink_objects $reload_objs~$CC -r -o $output$reload_objs' . t...@server01-unixware 132% grep Tprelink libtool old_archive_cmds=\$CC -Tprelink_objects \$oldobjs~ . In fact there is no reload_cmds= in the TAG CONFIG: CXX section . t...@server01-unixware 133% grep -n ^reload_cmds= libtool 123:reload_cmds=\$LD\$reload_flag -o \$output\$reload_objs t...@server01-unixware 134% grep -n CONFIG: CXX libtool 9097:# ### BEGIN LIBTOOL TAG CONFIG: CXX 9245:# ### END LIBTOOL TAG CONFIG: CXX . -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net
Re: cmdline_wrap.at
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: cmdline_wrap.at
Hi Ralf, On Sat, 28 Feb 2009, Ralf Wildenhues wrote: [snip] Is this an optimization only, or a necessary thing? IOW, if I omit libfoo-1.0 in this CC -Tprelink_objects line, would that only pessimize link time, or could it affect the link result? I'll let John answer this Anyway, I think the patch below should implement this (and add John to THANKS). Can you try it? Thanks. The test still fails although the patch could be correct. It looks like this never makes it into the generated libtool. + _LT_TAGVAR(reload_cmds, $1)='$CC -Tprelink_objects $reload_objs~$CC -r -o $output$reload_objs' . t...@server01-unixware 132% grep Tprelink libtool old_archive_cmds=\$CC -Tprelink_objects \$oldobjs~ . In fact there is no reload_cmds= in the TAG CONFIG: CXX section . t...@server01-unixware 133% grep -n ^reload_cmds= libtool 123:reload_cmds=\$LD\$reload_flag -o \$output\$reload_objs t...@server01-unixware 134% grep -n CONFIG: CXX libtool 9097:# ### BEGIN LIBTOOL TAG CONFIG: CXX 9245:# ### END LIBTOOL TAG CONFIG: CXX . -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cmdline_wrap.at
[ 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)=
Re: cmdline_wrap.at
Hi Tim,
Hello Ralf,
Happy to contribute where I can. Sorry to not get back to you sooner:
I actually spent an evening away from the computer.
Any way, the SCO/USL C++ compiler by default will do automatic template
instantiation. The compiler and a template prelinker cooperate to
determine necessary instantiations, assign them to compilation units,
and perform them as needed. Some of this work is done at link time rather
than compile time. Information about instantiation assignments is kept
in .ii and .ti files alongside corresponding .o files.
The .ti file contains the the source file name, current working directory,
compilation options and object module name (including directory is different).
This is only created if template declarations are defined or used by the
the source
The .ii file contains the list of instantiation assignments made by the
prelinker to each source file compilation. This is initially non-existent.
At link time (done with the CC command) the C++ compiler initiates the
prelinker phase. If a .ti file is seen along side a .o, the prelinker
will check all object file and libraries on the link line templates that
still need to be instantiated. These instantiations are assigned to
an object module (through the .ii file) and that source file is recompiled.
The same prelink process looks at these new .o's, to check for any new needed
instantiations have resulted from the current instantiations.. When all
undefined templates are handled, the prelink process completes and
the C++ compiler driver hands thing to the linker.
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.
renaming or moving a .o: should not be done unless corresponding changes
made to the .ti and .ii files and .it file contents.
shared objects: doing the complete link with $CC -G . takes care
of the prelink phase for all the .o's on the command line.
archives:requires that a $CC -Tprelink_objects
${all_objs_to_be_added_to_archive}
be done prior to the $AR command.
This is, I believe the patch the Tim has passed back to
libtool@gnu.org
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.
/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.
:
: then which objects does CC -Tprelink_objects need to be run on?
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.
If I can be of any additional help, please do not hesitate to ask.
John Wolfe
Tim Rice wrote:
Hi Ralf,
On Wed, 25 Feb 2009, Ralf Wildenhues wrote:
: Hi Tim,
:
: * Tim Rice wrote on Mon, Feb 23, 2009 at 10:47:49PM CET:
: On Sat, 21 Feb 2009, Ralf Wildenhues wrote:
: * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET:
:
:I'm trying to understand the cmdline_wrap.at test.
:I've added this patch to fix the 2 template tests that were failing
:on UnixWare 7.1.4
:
: Can you post the verbose output of the test both without and with the
: patch? Thanks.
: gmake check-local TESTSUITEFLAGS='-k simple template test -v -d -x'
:
: Sure, attched as x.tst-without-patch x.tst-with-patch
: I've also attached the curent patch I'm using as uw-template.patch
: It's just a s/CXX/CC/ of the old one.
:
: How come there is no ranlib step in old_archive_cmds?
Simple, there is no ranlib on UnixWare.
: Otherwise, if it causes no other testsuite regressions, it looks good to
: me.
No other
Re: cmdline_wrap.at
Hi Ralf, On Wed, 25 Feb 2009, Ralf Wildenhues wrote: : Hi Tim, : : * Tim Rice wrote on Mon, Feb 23, 2009 at 10:47:49PM CET: : On Sat, 21 Feb 2009, Ralf Wildenhues wrote: : * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET: : :I'm trying to understand the cmdline_wrap.at test. :I've added this patch to fix the 2 template tests that were failing :on UnixWare 7.1.4 : : Can you post the verbose output of the test both without and with the : patch? Thanks. : gmake check-local TESTSUITEFLAGS='-k simple template test -v -d -x' : : Sure, attched as x.tst-without-patch x.tst-with-patch : I've also attached the curent patch I'm using as uw-template.patch : It's just a s/CXX/CC/ of the old one. : : How come there is no ranlib step in old_archive_cmds? Simple, there is no ranlib on UnixWare. : Otherwise, if it causes no other testsuite regressions, it looks good to : me. No other regressions. : How long is the actual command line length limit on your system? : If it is 1MB or unlimited, then this is unlikely to ever be a problem : in practice, and you can ignore the failure. But some systems have : pretty low limits. : : On my system it is 131072 but it is a kernel tunable and the default : out of the box is 32k. : : That's too low for some packages. Indeed, but it can be tuned as high as 1048576. : The output of the failing/passing of the test above may help analyze the : failure of the cmdline_wrap test. : : John Wolfe was looking at this too (using 2.2.6) and here is what : he had to say : -- : I know why test 73 (small command line) test fails on #62 (C++ : templates). : : - one of the link lines (second) linking against a .la, gets : broken up and .o's are collected in a relocatable object using. : : /bin/ld -r : : Ergo the problem, the prelink phase is skipped. It is not a : problem with the archive being built, since $AR can accumulate : object files, 1 file at a time. : So the CC -Tprelink_objects is accomplished as expected - just : before the $AR. : The prelinker command echo can be seen in the log. : : For shared objects, what is needed is to get a CC -Tprelink_objects : done on the libobjs before they are added to the relocatable object. : : Can you show how it would need to work? If libtool reloads : a.o b.o c.o - libfoo-1.o : d.o e.o f.o libfoo-1.o - libfoo-2.o : and links : g.o libfoo-2.o - libfoo.la : : then which objects does CC -Tprelink_objects need to be run on? Maybe we can get John to comment on this one. He knows the C++ compile much better than I do. : The /bin/ld cannot be replaced with $CC since the C++ compiler : driver will link in startup modules also. Soon get a multiple : defined symbol. : : Yes. : : Thanks, : Ralf -- Tim RiceMultitalents(707) 887-1469 t...@multitalents.net ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cmdline_wrap.at
Hi Tim, * Tim Rice wrote on Mon, Feb 23, 2009 at 10:47:49PM CET: On Sat, 21 Feb 2009, Ralf Wildenhues wrote: * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET: I'm trying to understand the cmdline_wrap.at test. I've added this patch to fix the 2 template tests that were failing on UnixWare 7.1.4 Can you post the verbose output of the test both without and with the patch? Thanks. gmake check-local TESTSUITEFLAGS='-k simple template test -v -d -x' Sure, attched as x.tst-without-patch x.tst-with-patch I've also attached the curent patch I'm using as uw-template.patch It's just a s/CXX/CC/ of the old one. How come there is no ranlib step in old_archive_cmds? Otherwise, if it causes no other testsuite regressions, it looks good to me. How long is the actual command line length limit on your system? If it is 1MB or unlimited, then this is unlikely to ever be a problem in practice, and you can ignore the failure. But some systems have pretty low limits. On my system it is 131072 but it is a kernel tunable and the default out of the box is 32k. That's too low for some packages. The output of the failing/passing of the test above may help analyze the failure of the cmdline_wrap test. John Wolfe was looking at this too (using 2.2.6) and here is what he had to say -- I know why test 73 (small command line) test fails on #62 (C++ templates). - one of the link lines (second) linking against a .la, gets broken up and .o's are collected in a relocatable object using. /bin/ld -r Ergo the problem, the prelink phase is skipped. It is not a problem with the archive being built, since $AR can accumulate object files, 1 file at a time. So the CC -Tprelink_objects is accomplished as expected - just before the $AR. The prelinker command echo can be seen in the log. For shared objects, what is needed is to get a CC -Tprelink_objects done on the libobjs before they are added to the relocatable object. Can you show how it would need to work? If libtool reloads a.o b.o c.o - libfoo-1.o d.o e.o f.o libfoo-1.o - libfoo-2.o and links g.o libfoo-2.o - libfoo.la then which objects does CC -Tprelink_objects need to be run on? The /bin/ld cannot be replaced with $CC since the C++ compiler driver will link in startup modules also. Soon get a multiple defined symbol. Yes. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cmdline_wrap.at
Hi Ralf,
On Sat, 21 Feb 2009, Ralf Wildenhues wrote:
Hi Tim,
* Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET:
I'm trying to understand the cmdline_wrap.at test.
I've added this patch to fix the 2 template tests that were failing
on UnixWare 7.1.4
Can you post the verbose output of the test both without and with the
patch? Thanks.
gmake check-local TESTSUITEFLAGS='-k simple template test -v -d -x'
Sure, attched as x.tst-without-patch x.tst-with-patch
I've also attached the curent patch I'm using as uw-template.patch
It's just a s/CXX/CC/ of the old one.
so now the only failure is the low max_cmd_len test.
OK, cool.
I guess I don't really know what cmdline_wrap.at is trying to acomplish.
And I'm puzzled why the simple template test fails inside cmdline_wrap
but not outside of it.
Well, it tries to simulate a very long command line, so long that its
expansion by libtool will exceed the kernel command line length limit.
It does this by setting the limit very low, which libtool internally
compares against. So then the wrapping code branches are exercised,
which create intermediate libraries or objects.
How long is the actual command line length limit on your system?
If it is 1MB or unlimited, then this is unlikely to ever be a problem
in practice, and you can ignore the failure. But some systems have
pretty low limits.
On my system it is 131072 but it is a kernel tunable and the default
out of the box is 32k.
The test case tries to re-run all kinds of other tests in our testsuite
(exactly those that only exercise the $LIBTOOL script), for best
possible code coverage.
The output of the failing/passing of the test above may help analyze the
failure of the cmdline_wrap test.
John Wolfe was looking at this too (using 2.2.6) and here is what
he had to say
--
I know why test 73 (small command line) test fails on #62 (C++
templates).
- one of the link lines (second) linking against a .la, gets
broken up and .o's are collected in a relocatable object using.
/bin/ld -r
Ergo the problem, the prelink phase is skipped. It is not a
problem with the archive being built, since $AR can accumulate
object files, 1 file at a time.
So the CC -Tprelink_objects is accomplished as expected - just
before the $AR.
The prelinker command echo can be seen in the log.
For shared objects, what is needed is to get a CC -Tprelink_objects
done on the libobjs before they are added to the relocatable object.
The /bin/ld cannot be replaced with $CC since the C++ compiler
driver will link in startup modules also. Soon get a multiple
defined symbol.
--
Thanks.
Thanks!
Ralf
--
Tim RiceMultitalents(707) 887-1469
t...@multitalents.net--- libltdl/m4/libtool.m4.old 2009-02-18 18:54:38.0 -0800
+++ libltdl/m4/libtool.m4 2009-02-22 20:54:26.786787091 -0800
@@ -6219,6 +6219,8 @@
CC*)
_LT_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib
$libobjs $deplibs $compiler_flags'
_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G
${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs
$compiler_flags'
+ _LT_TAGVAR(old_archive_cmds, $1)='$CC -Tprelink_objects $oldobjs~
+ $AR $AR_FLAGS $oldlib$oldobjs$old_deplibs'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib
$libobjs $deplibs $compiler_flags'
abs_srcdir=`CDPATH=${ZSH_VERSION+.}: cd /home2/src/gnu/libtool-2.x
pwd`; cd tests; \
CONFIG_SHELL=/bin/ksh /bin/ksh $abs_srcdir/tests/testsuite \
MAKE=gmake CC=cc CFLAGS=-g CPP=cc -E CPPFLAGS= LD=/usr/bin/ld
LDFLAGS= LIBS= LN_S=ln -s NM=/usr/bin/nm -p RANLIB=: STRIP=strip
lt_INSTALL=/home2/src/gnu/libtool-2.x/libltdl/config/install-sh -c OBJEXT=o
EXEEXT= SHELL=/bin/ksh CONFIG_SHELL=/bin/ksh CXX=CC CXXFLAGS=-g
CXXCPP=CC -E F77= FFLAGS= FC= FCFLAGS= GCJ= GCJFLAGS=-g -O2
_lt_pkgdatadir=/home2/src/gnu/libtool-2.x
LIBTOOLIZE=/usr/local/src/gnu/libtool-2.x/libtoolize
LIBTOOL=/usr/local/src/gnu/libtool-2.x/libtool
tst_aclocaldir=/home2/src/gnu/libtool-2.x/libltdl/m4 -k simple template
test -v -d -x
## -- ##
## libtool 2.2.7a test suite. ##
## -- ##
73. template.at:27: testing ...
/home2/src/gnu/libtool-2.x/tests/template.at:28: { test -n $CXX test
X$CXX != Xno; } || (exit 77)
+ test -n CC
+ test XCC != Xno
/home2/src/gnu/libtool-2.x/tests/template.at:28: test X$CXX != Xg++ || (g++
-v /dev/null 21) || (exit 77)
+ test XCC != Xg++
+ cat
+ 1 aclib.h 0
+ cat
+ 1 aclib.cpp 0
+ cat
+ 1 alib.h 0
+ cat
+ 1 alib.cpp 0
+ cat
+ 1 prog.cpp 0
/home2/src/gnu/libtool-2.x/tests/template.at:79: $LIBTOOL --tag=CXX
--mode=compile $CXX -I. $CPPFLAGS $CXXFLAGS -c -o alib.lo alib.cpp
+ /usr/local/src/gnu/libtool-2.x/libtool --tag=CXX --mode=compile CC -I. -g -c
-o
Re: cmdline_wrap.at
Hi Tim, * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET: I'm trying to understand the cmdline_wrap.at test. I've added this patch to fix the 2 template tests that were failing on UnixWare 7.1.4 Can you post the verbose output of the test both without and with the patch? Thanks. gmake check-local TESTSUITEFLAGS='-k simple template test -v -d -x' so now the only failure is the low max_cmd_len test. OK, cool. I guess I don't really know what cmdline_wrap.at is trying to acomplish. And I'm puzzled why the simple template test fails inside cmdline_wrap but not outside of it. Well, it tries to simulate a very long command line, so long that its expansion by libtool will exceed the kernel command line length limit. It does this by setting the limit very low, which libtool internally compares against. So then the wrapping code branches are exercised, which create intermediate libraries or objects. How long is the actual command line length limit on your system? If it is 1MB or unlimited, then this is unlikely to ever be a problem in practice, and you can ignore the failure. But some systems have pretty low limits. The test case tries to re-run all kinds of other tests in our testsuite (exactly those that only exercise the $LIBTOOL script), for best possible code coverage. The output of the failing/passing of the test above may help analyze the failure of the cmdline_wrap test. Thanks! Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
