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