Re: PGI and C++ templates
Sorry to self-followup. Another thing came to mind: * Ralf Wildenhues wrote on Sat, Mar 05, 2005 at 05:10:31PM CET: > * Jeff Squyres wrote on Sat, Mar 05, 2005 at 01:07:11AM CET: > > > You must now do an extra pre-link step to instantiate all the templates > > used in this library, putting all the library .o's on this line, and no > > -c flag. *snip* > > Similar question: do we have to know which objects need > prelink/contain/use templates? How about subdirs: which are the > important ones? > > What happens if templates are not used at all? > > At which time is Template.dir populated (and which dir, in the case of > subdir-objects)? Is is maybe possible to specify the Template.dir with > another parameter (this might be necessary in special cases only)? > > > Achive or build the shared library as before, except you must include > > the new hidden templates in the Template.dir directory: > > > > $ ar qv lib_mylib.a Template.dir/*.o file1.o file2.o etc. At the moment, Template.dir/ is not cleaned by `make clean'. This should be done, I'm not sure whether by Automake rules or by Libtool. What happens if you have source files which used to provide/use templates, but no longer do so, but still have objects lying around in Template.dir/, which now get erroneously added to the static/shared archive? What about objects in Template.dir/ which do not belong to the current link at all (because they belong in a different library)? Do we have to know the names of all objects from Template.dir/*.o to use or can we just add all of them without problems? Remember we may not be allowed to add exported symbols to the library as that will destroy runtime (in the case of shared linking) or program-link-time (in the case of static linking) link order. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: PGI and C++ templates
On Mar 5, 2005, at 11:10 AM, Ralf Wildenhues wrote: For each source file in the library, compile it: $ pgCC -c --one_instantiation_per_object $(YOUR_FLAGS) file.cc Can we issue the `--one_instantiation_per_object' for all C++ source, not just the source with templates in it? I don't see a problem with this...? It works in my tests. What happens for input/output in subdirs (this is an important question)? E.g., what does pgCC -c --one_instantiation_per_object -c -o sub/foo.o src/bar.c do? It looks like: - sub/foo.o is created as expected - but Template.dir/* is created in cwd (not sub/Template.dir) Here's what I did (note that bar.cc contains a template): - [12:53] vogon:/tmp/lt-pgi-test % find . . ./src ./src/bar.cc [12:53] vogon:/tmp/lt-pgi-test % pgCC -c --one_instantiation_per_object -c -o src/bar.o src/bar.cc [12:53] vogon:/tmp/lt-pgi-test % find . . ./Template.dir ./src ./src/bar.ti ./src/bar.o ./src/bar.cc [12:53] vogon:/tmp/lt-pgi-test % pgCC --one_instantiation_per_object --prelink_objects src/bar.o C++ prelinker: executing: /[path-obscured]/pgi-5.2-4/linux86/5.2/bin/pgCC --one_instantiation_per_object -o src/bar.o -c src/bar.cc [12:53] vogon:/tmp/lt-pgi-test % find . . ./Template.dir ./Template.dir/q__tm__2_i_db1e5f54.o ./src ./src/bar.ti ./src/bar.o ./src/bar.cc ./src/bar.ii - However, it looks like this behavior (Template.dir being made in the cwd instead of the subdir) can be overridden with the "--instantiation_dir " option. -- [12:55] vogon:/tmp/lt-pgi-test % find . . ./src ./src/bar.cc [12:55] vogon:/tmp/lt-pgi-test % pgCC -c --instantiation_dir src/Template.dir --one_instantiation_per_object -c -o src/bar.o src/bar.cc [12:55] vogon:/tmp/lt-pgi-test % find .. ./src ./src/Template.dir ./src/bar.ti ./src/bar.cc ./src/bar.o [12:56] vogon:/tmp/lt-pgi-test % pgCC --instantiation_dir src/Template.dir --one_instantiation_per_object --prelink_objects src/bar.o C++ prelinker: executing: /[dir obscured]/pgi-5.2-4/linux86/5.2/bin/pgCC --instantiation_dir src/Template.dir --one_instantiation_per_object -o src/bar.o -c src/bar.cc [12:56] vogon:/tmp/lt-pgi-test % find . . ./src ./src/Template.dir ./src/Template.dir/q__tm__2_i_db1e5f54.o ./src/bar.ti ./src/bar.cc ./src/bar.o ./src/bar.ii - Note that it looks like files are not made in Template.dir until the --prelink_objects step. You must now do an extra pre-link step to instantiate all the templates used in this library, putting all the library .o's on this line, and no -c flag. $ pgCC --one_instantiation_per_object --prelink_objects $(YOUR_FLAGS) file1.o file2.o etc. Similar question: do we have to know which objects need prelink/contain/use templates? How about subdirs: which are the important ones? What happens if templates are not used at all? It looks like pgCC is smart enough to figure this stuff out. I took the above example and added "foo.cc" -- a trivial C++ function that has no templates. So: bar.cc has a template, foo.cc does not have a template. - [13:01] vogon:/tmp/lt-pgi-test % find . . ./src ./src/bar.cc ./src/foo.cc [13:01] vogon:/tmp/lt-pgi-test % pgCC -c --instantiation_dir src/Template.dir --one_instantiation_per_object -o src/foo.o src/foo.cc [13:02] vogon:/tmp/lt-pgi-test % find . . ./src ./src/bar.cc ./src/foo.cc ./src/Template.dir ./src/foo.o [13:02] vogon:/tmp/lt-pgi-test % pgCC -c --instantiation_dir src/Template.dir --one_instantiation_per_object -o src/bar.o src/bar.cc [13:02] vogon:/tmp/lt-pgi-test % find . . ./src ./src/bar.cc ./src/foo.cc ./src/Template.dir ./src/foo.o ./src/bar.ti ./src/bar.o [13:02] vogon:/tmp/lt-pgi-test % pgCC --instantiation_dir src/Template.dir --one_instantiation_per_object --prelink_objects src/foo.o src/bar.o C++ prelinker: executing: /[dir obscured]/pgi-5.2-4/linux86/5.2/bin/pgCC --instantiation_dir src/Template.dir --one_instantiation_per_object -o src/bar.o -c src/bar.cc [13:03] vogon:/tmp/lt-pgi-test % find . . ./src ./src/bar.cc ./src/foo.cc ./src/Template.dir ./src/Template.dir/q__tm__2_i_db1e5f54.o ./src/foo.o ./src/bar.ti ./src/bar.o ./src/bar.ii -- My guess is that the --prelink_objects step only does something if there are corresponding .ti files. Note that the Template.dir directory is created right away, and it is empty, so testing for its presence in libtool logic does not appear to be useful. One final test -- do all this with just foo.cc (the one without any templates). Do we get any errors, for example, if we --prelink_objects without any .o files with templates? - [13:06] vogon:/tmp/lt-pgi-test % find . . ./src ./src/foo.cc [13:06] vogon:/tmp/lt-pgi-test % pgCC -c --instantiation_dir src/Template.dir --one_instantiation_per_object -o src/foo.o src/foo.cc [13:06] vogon:/tmp/lt-pgi-test % find . . ./src ./src/foo.cc ./src/Template.dir ./src/foo.o [13:06] vogon:/tmp/lt-pgi-test % pgCC --instantiation_dir src/Template.dir --one_instantiation_per_object --prelink_objects src/foo.o [13:06] vogon:/tmp/lt-pgi-te
Re: PGI and C++ templates
On Mar 7, 2005, at 3:07 AM, Ralf Wildenhues wrote:
Achive or build the shared library as before, except you must include
the new hidden templates in the Template.dir directory:
$ ar qv lib_mylib.a Template.dir/*.o file1.o file2.o etc.
At the moment, Template.dir/ is not cleaned by `make clean'. This
should be done, I'm not sure whether by Automake rules or by Libtool.
But this has always been a problem, right? (i.e., not just with the
PGI compilers)
I've long since added my own m4 to my configure scripts to see if the
C++ compiler uses a template subdirectory, and if so, add it to
CLEANFILES.
Has something changed that I no longer need to do this?
What happens if you have source files which used to provide/use
templates, but no longer do so, but still have objects lying around in
Template.dir/, which now get erroneously added to the static/shared
archive?
This is definitely a problem. :-\
I always just took care to run "make clean" or manually remove the
template subdirs in those cases. If AM/LT/somebody could take of this
for me, that would be fantastic.
What about objects in Template.dir/ which do not belong to the current
link at all (because they belong in a different library)? Do we have
to know the names of all objects from Template.dir/*.o to use or can
we just add all of them without problems? Remember we may not be
allowed to add exported symbols to the library as that will destroy
runtime (in the case of shared linking) or program-link-time (in the
case of static linking) link order.
Hmm. Good question. I guess one option here may be to use the
--instantiation_dir switch to have a different "Template.dir" (so to
speak) for each target library...? I'm not quite sure how that would
work, though, because AM would be the one with this knowledge (i.e.,
know which source files belong to which library) -- I don't know how AM
would pass this information down to LT [in a clean manner]...
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: PGI and C++ templates
Engineering can confirm
1. You should use the --instantiation_dir flag to
keep separate instantiation directories for each
library.
2. You should always clean the Template.dir with any
changes to the associated library templates.
regards,
dave
> On Mar 7, 2005, at 3:07 AM, Ralf Wildenhues wrote:
>
Achive or build the shared library as before, except you must include
the new hidden templates in the Template.dir directory:
$ ar qv lib_mylib.a Template.dir/*.o file1.o file2.o etc.
>>
>> At the moment, Template.dir/ is not cleaned by `make clean'. This
>> should be done, I'm not sure whether by Automake rules or by Libtool.
>
> But this has always been a problem, right? (i.e., not just with the
> PGI compilers)
>
> I've long since added my own m4 to my configure scripts to see if the
> C++ compiler uses a template subdirectory, and if so, add it to
> CLEANFILES.
>
> Has something changed that I no longer need to do this?
>
>> What happens if you have source files which used to provide/use
>> templates, but no longer do so, but still have objects lying around in
>> Template.dir/, which now get erroneously added to the static/shared
>> archive?
>
> This is definitely a problem. :-\
>
> I always just took care to run "make clean" or manually remove the
> template subdirs in those cases. If AM/LT/somebody could take of this
> for me, that would be fantastic.
>
>> What about objects in Template.dir/ which do not belong to the current
>> link at all (because they belong in a different library)? Do we have
>> to know the names of all objects from Template.dir/*.o to use or can
>> we just add all of them without problems? Remember we may not be
>> allowed to add exported symbols to the library as that will destroy
>> runtime (in the case of shared linking) or program-link-time (in the
>> case of static linking) link order.
>
> Hmm. Good question. I guess one option here may be to use the
> --instantiation_dir switch to have a different "Template.dir" (so to
> speak) for each target library...? I'm not quite sure how that would
> work, though, because AM would be the one with this knowledge (i.e.,
> know which source files belong to which library) -- I don't know how AM
> would pass this information down to LT [in a clean manner]...
>
> --
> {+} Jeff Squyres
> {+} [EMAIL PROTECTED]
> {+} http://www.lam-mpi.org/
>
___
http://lists.gnu.org/mailman/listinfo/libtool
