On Tue, 4 Oct 2005, David Berry wrote:
> The failures seem to be due to multiply defined GRP symbols, but I cannot
> really see what is going on.
>
> 1) Why does this problem only occur on MACOS?
>
> 2) Why have these problems only just started, when the last modification
> to the grp makefile was 4 days ago (and even then the change should have
> harmless)?
>
> 3) GRP follows the same model of other libraries such as NDF in that
> libgrp contains basic routines, and libgrp_adam contains both basic
> routines and adam routines. The errors in the build log file suggest that
> the problem is caused by the basic routines being in both libraries, but
> this works ok for other libraries (like NDF), so why not GRP? [the
> grp_link_adam script is like ndf_link_adam in including both libraries in
> the list of required libraries].
David,
the problem caused by the new C interface routines. These also need to be
included in the ADAM library.
I think what's going on here is that previously (and in NDF etc.) the
duplicate symbols in the standalone version were not checked because no
symbols were needed beyond those in the ADAM version (even though the
standalone library is needed by the executable at runtime, I guess that's
to allow for any inter-library dependencies not picked by the linker).
> I suppose I *could* change grp_link_adam to be:
>
> echo -lgrp_adam ...
>
> instead of
>
> echo -lgrp_adam -lgrp ...
>
> but I can't see why this should only be necessary on MACOS.
Hmm, looking at this I think that what's at the root of the duplications
used in all these libraries must be because of common blocks and blockdata
initialisation. If the standalone and ADAM versions share these, then all
the code must be present in both libraries, and typically you'd also just
do what you show above, i.e. just echo -lxxx_adam in the xxx_adam script.
Clearly if GRP doesn't access any common blocks in the ADAM routines then
all this is unnecessary and you should stop including the standalone code
and the blockdata.
Cheers,
Peter.
|
