[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PGI and C++ templates

From: trs
Subject: Re: PGI and C++ templates
Date: Mon, 7 Mar 2005 14:06:50 -0800 (PST)
User-agent: SquirrelMail/1.4.3a

Engineering can confirm

1. You should use the --instantiation_dir flag to
   keep separate instantiation directories  for each

2. You should always clean the Template.dir with any
   changes to the associated library 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
> 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
> {+} address@hidden
> {+}

reply via email to

[Prev in Thread] Current Thread [Next in Thread]