Re: cmdline_wrap.at

[John Wolfe]

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]