[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cmdline_wrap.at
From: |
John Wolfe |
Subject: |
Re: cmdline_wrap.at |
Date: |
Sun, 01 Mar 2009 15:12:47 -0500 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20090105) |
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 <address@hidden>
| Date: Thu Apr 7 17:58:26 2005 +0000
|
| 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]
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: cmdline_wrap.at,
John Wolfe <=