Re: cmdline_wrap.at

[John Wolfe]

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 
address@hidden

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 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
>
>