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