Re: PGI and C++ templates
Ralf, Jeff, and everyone,
We looked at what you did, and it appears you understand how
things were put together.
However, the 6.0 release is about to come out, and
the template instantiation mechanism
has been totally rewritten for linux targets. All of the
template related compiler switches will be deprecated:
--one_instantiation_per_object
--instantiation_dir
--instantiate
--[no_]auto_instantiation
--prelink_objects
-Wc,-tlocal
-Wc,-tused
-Wc,-tall
This new instantiation method uses the Gnu linker to resolve all
template references and discard the duplicates. This new feature
is not compatible with previous releases. Users will need to
recompile all C++ code, and modify the build tools that do a
prelink step.
In general, the compiler will simply ignore and give a warning
when these template switches are used. Tools that attempt
to archive Template.dir/*.o will find that the directory
is no longer created by the compiler driver.
regards,
dave
Sorry for the self-reply,
* Ralf Wildenhues wrote on Mon, Mar 14, 2005 at 07:49:00PM CET:
This is a status update on libtool/pgi/C++ with templates.
Now here's an improved patch against branch-2-0. Should work for both
static and shared uninstalled libraries plus programs linked against
them, and seems to also work when relinking is required upon
installation. It works with the example Markus provided a while ago.
Turns out pgCC is smart enough to recreate all that is needed with the
correct PICness all by itself, so we don't even need to adjust
Template.dir. Nice compiler work!
What's missing is correct `make clean'ing, which will be addressed later
in reply to Jeff's macro.
Testing would be *great*, as would be reviewing.
Cheers,
Ralf
,-- ***experimental*** patch for PGI + templates ---
* m4/libtool.m4 (_LT_COMPILER_C_O): The compiler may create
subdirectories which we have to remove here.
* m4/libtool.m4 (_LT_LINKER_SHLIBS): New TAGDECL $prelink_cmds
intended for compilation of template instantiations for program
outputs.
* m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [ linux ]: Enable template
compilation for Portland pgCC in prelink_cmds and old_archive_cmds.
* config/ltmain.m4sh (func_mode_link): execute $prelink_cmds if
nonempty.
Index: config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v
retrieving revision 1.1.2.47
diff -u -r1.1.2.47 ltmain.m4sh
--- config/ltmain.m4sh12 Mar 2005 08:50:45 - 1.1.2.47
+++ config/ltmain.m4sh15 Mar 2005 16:55:37 -
@@ -5530,6 +5530,18 @@
func_generate_dlsyms $outputname @PROGRAM@ no
+ # template prelinking step
+ if test -n $prelink_cmds; then
+ cmds=$prelink_cmds
+ save_ifs=$IFS; IFS='~'
+ for cmd in $cmds; do
+ IFS=$save_ifs
+ eval cmd=\$cmd\
+ $show $cmd
+ $run eval $cmd
+ test $? -eq 0 || exit $?
+ done
+ fi
wrappers_required=yes
case $host in
Index: m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.125.2.36
diff -u -r1.125.2.36 libtool.m4
--- m4/libtool.m4 14 Mar 2005 15:03:24 - 1.125.2.36
+++ m4/libtool.m4 15 Mar 2005 16:55:37 -
@@ -1482,7 +1482,7 @@
test -d out/ii_files $RM out/ii_files/* rmdir out/ii_files
$RM out/* rmdir out
cd ..
- rmdir conftest
+ $RM -r conftest
$RM conftest*
])
_LT_TAGDECL([compiler_c_o], [lt_cv_prog_compiler_c_o], [1],
@@ -3112,7 +3112,7 @@
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
;;
- pgCC)
+ pgCC*)
# Portland Group C++ compiler
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
@@ -4468,6 +4468,8 @@
[Symbols that should not be listed in the preloaded symbols])
_LT_TAGDECL([], [include_expsyms], [1],
[Symbols that must always be exported])
+_LT_TAGDECL([], [prelink_cmds], [2],
+[Commands necessary for linking programs (against libraries) with
templates])
dnl FIXME: Not yet implemented
dnl _LT_TAGDECL([], [thread_safe_flag_spec], [1],
dnl[Compiler flag to generate thread safe objects])
@@ -5191,10 +5193,25 @@
_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
_LT_TAGVAR(whole_archive_flag_spec,
$1)='${wl}--whole-archive$convenience ${wl}--no-whole-archive'
;;
- pgCC)
+ pgCC*)
# Portland Group C++ compiler
-_LT_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
${wl}$soname -o
Re: PGI and C++ templates
hi Ralf Wildenhues wrote: Sorry for the self-reply, * Ralf Wildenhues wrote on Mon, Mar 14, 2005 at 07:49:00PM CET: This is a status update on libtool/pgi/C++ with templates. Now here's an improved patch against branch-2-0. Should work for both static and shared uninstalled libraries plus programs linked against them, and seems to also work when relinking is required upon installation. It works with the example Markus provided a while ago. that sounds promising Turns out pgCC is smart enough to recreate all that is needed with the correct PICness all by itself, so we don't even need to adjust Template.dir. Nice compiler work! What's missing is correct `make clean'ing, which will be addressed later in reply to Jeff's macro. Testing would be *great*, as would be reviewing. i will test it on real-life MD code. but we have Open-Doors days this week - so no time at all. will do it next week. thanks, markus Cheers, Ralf snip patches smime.p7s Description: S/MIME Cryptographic Signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: PGI and C++ templates
On Mar 14, 2005, at 1:49 PM, Ralf Wildenhues wrote:
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.
Can you be bothered to share it with us? Has it hung enough to be
considered for Automake?
Sure -- it's attached.
I don't know if it's good enough to be considered for AM; it's really
a shotgun approach (I don't know anything about their coding
standards):
- make a temp dir, cd into it
- compile some C++ stuff that contains templates
- remove all known files
- see what files/dirs are left
There's probably other ways to do it; I have dim recollections of this
macro coming into existence around 3am one night... :-)
(looking at this code again -- it's been years since I've examined it
-- there's a *lot* that would need to be cleaned up and generalized; I
am realizing how much I didn't know about AC when I wrote that macro --
it's embarrassing! ;-) The shotgun approach idea can be extracted from
this code, if it's useful -- that's probably about it)
Has something changed that I no longer need to do this?
We might want to have something like it.
That would be fantastic.
[Template.dir stuff snipped]
I'll let the PGI people reply to this stuff...
Does anybody have some real-world code using C++/templates/libraries
that I (or, even better, you) can test with (and that is not too
complicated to set up)?
'fraid not. We only needed C libraries to build with LAM/MPI -- the
C++ templating issue came up after that was solved. Sorry! :-(
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
cxx_find_template_repository.m4
Description: Binary data
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: PGI and C++ templates
Hello everyone, This is a status update on libtool/pgi/C++ with templates. Skip to the [ Interesting part ] if you are in a hurry. * [EMAIL PROTECTED] wrote on Mon, Mar 07, 2005 at 11:06:50PM CET: 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. Thank you for this information. Jeff Squyres wrote: 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) Sure. 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. Can you be bothered to share it with us? Has it hung enough to be considered for Automake? Has something changed that I no longer need to do this? We might want to have something like it. 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. This seems to me the easier part. 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]... OK, I got a little further, so here are a few random thoughts: First, it's necessary to have different template dir's for PIC and non-PIC objects. Otherwise, pgCC will get all confused and angry at template loops and such. Then, pgCC --one_instantiation_per_object already creates template objects while compiling the normal objects (-c foo.c -o foo.o). Weird enough, I have only been able to reproduce this with -fpic but not without. I don't know but hope, that - if I compile all sources (pgCC --one_instantiation_per_object -c) - then rm -rf Template.dir - then pgCC --one_instantiation_per_object --prelink_objects *.o the third step recreates all template objects I deleted in the second step. It looks like this works. Certainly, I need the same template directory for all objects of one library I want to create (so the prelinker knows which ones are done, and which ones are still necessary because of other templates in there). I have not found out a way to get the prelink step to tell me which template objects will really be necessary for the subsequent link. Why would this be necessary? It would enable parallel building while still being able to put all non-PIC objects into the same directory without cleaning in-between. Not even parallel builds, just building several libraries in one directory need this. This is because I cannot just include every template object I can grab -- ones unrelated to the output library can and will break the link. That's the reason for the rm -rf above. Furthermore, the docs don't seem to mention that, when linking a program, I also have to run the prelinking step. Not too surprising. While prelinking, I must not only list the objects to consider, but also the libraries I will link against: pgCC --prelink_objects --one_instantiation_per_object main.o \ deplib1.a deplib2.so Then, only instantiations not in deplib1.a or deplib2.so will be built. Hehe, here's the reason why installable shared libraries with templates are really silly: changing deplib2.so later on can easily break installed applications. It suffices to un-inline a function, remove use of some non-template function in a deplib of deplib2.so which itself depends on a template, boink. (But you probably knew all of this). [ Interesting part ]
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 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]
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
Re: PGI and C++ templates
Hi Jeff,
* Jeff Squyres wrote on Sat, Mar 05, 2005 at 01:07:11AM CET:
Can I impose on the good will of a libtool wizard? I could attempt
this myself, but I don't have a good track record mucking around in the
LT source. ;-)
Not true. But let's see what we can do..
Here's the situation: on branch-1-5, we have good PGI compiler support
-- *except* for libraries with C++ templates. For that, we need some
more work (someone identified this recently -- I'm afraid I don't
remember who). I have mailed the PGI support folks (CC'ed on this
mail) and they have told me what needs to be done (if you care, the
full thread is here:
http://www.pgroup.com/userforum/viewtopic.php?t=172postdays=0postorder=ascstart=0):
Thank you for this link, quite helpful.
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?
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?
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?
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.
Same questions as above.
Is there any way someone can add this to Libtool (preferably both
1.5.x and 2.0.x), or provide me with some guidance on how to do so? (I
did ok in tinkering around to add simple command line switch changes,
but the multi-step outlined procedure would take me a lng time to
figure out).
I'd love this to work better with Libtool. One thing that kept me from
putting a solution for one compiler in (apart from the fact that I had
not delved deep into PGCC) is that similar things might be necessary for
SGI C++ and others. Where possible, larger code snippets should be
factored out. Maybe this is not necessary.
Let's see how far we get with PGI, we can still do refactoring later.
(BTW, I had even once looked at their online docs, but the questions
above are not answered fully in there.)
There's one condition: this is only necessary for PGI compiler versions
5.2-4 and prior of their compiler. With their most recent version
(soon to be released) -- 6.0 -- none of this is necessary, and what we
have now in Libtool will work just fine (i.e., they cleaned up the
compiler to do templates in libraries much better -- the entire
multi-step process listed above is unnecessary).
Nice.
Here's a quick-n-easy way to get the version of the compiler:
pgcc_major_ver=`pgCC -V | awk '/pgCC/ { print \$2 }' | cut -d. -f1`
pgcc_need_extra=`expr $pgcc_major_ver \ 6`
Can we get the complete output of pgCC?
Would
( set `pgCC -V`; pgcc_major_ver=$2
case $pgcc_major_ver in
[1-5].*) :;;
*) false;;
esac )
suffice as yesno-test (little faster)?
(Note you need to double `[' and `]' in most m4 macros.)
How does that sound?
Thank you for your work on this.
If you want to start fuddling around with the archive_cmds, one further
hint: `~' is used to delimit commands in the *_cmds libtool variables.
So, if we the subdir stuff turns out to be trivial, we can just add a
command to archive_cmds/archive_expsyms_cmds/old_archive_cmds and be
done mostly.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
