[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: John Wolfe
Subject: Re:
Date: Sun, 01 Mar 2009 15:12:47 -0500
User-agent: Thunderbird (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 
                     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          ->

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.


[ snip preliminary patches]

reply via email to

[Prev in Thread] Current Thread [Next in Thread]