Final Linking for Cactus Executable
-----------------------------------

Author: Thomas Radke
Date: April 2001
Status: Suggestions

What
----

At the moment the final Cactus link line includes all the thorn libraries
twice in a straightforward manner. This is occasionally not enough to 
resolve all the symbols, and we will need to be a little cleverer to make 
sure it works all the time.

For example, one pathological case is 

- main(), calling routine aa(), is compiled into main.o
 -   aa(), calling routine bb(), is compiled into libaa.a
 -   bb(), calling routine cc(), is compiled into libbb.a
 -   cc(), doing something useful, is compiled into libcc.a

Now, if we have

  cc main.o -laa -lbb -lcc

everything works fine. But

  cc main.o -lcc -lbb -laa            # or even
  cc main.o -lcc -lbb -laa -lcc -lbb -laa

gives an error

  ./libbb.a(bb.o): In function `bb':
  bb.o(.text+0x4): undefined reference to `cc'
  collect2: ld returned 1 exit status

Or, a Cactus example is IOHDF5 calling IOHDF5Util calling PUGHSlab.
Here you need to add '-lPUGHSlab' a third time by hand in order to make 
it link. It only happens with IOStreamedHDF5 excluded from the ThornList. 
If this one was added everything worked again due to the different lib 
ordering.


Suggestions
-----------

One thing could be using library groups.
The upper example does link if you call it

  cc main.o -Xlinker --start-group       \
                     -laa -lbb -lcc      \
            -Xlinker --end-group

Then the order of libs doesn't matter at all,
and you also need to add every lib only once.
But, unfortunately, library groups are GNU-specific.

A general solution would be to build a database of INHERIT/FRIEND
dependencies from the thorns' interface.ccl files when running the CST.
With this information, a minimal liblist can be build by removing
duplicate entries with no dependencies, sorting libs in the list
according to their dependency path, and duplicating FRIEND groups.
On the linker command line we would then just append this minimal
set of thorn libs.

This general solution was finally implemented at least partially
in that it solved the problems with unsorted liblists.
It cannot yet handle indirect FRIEND relationships (ie. A is friend
of B, B is friend of C, so A is also friend of C). But this situation
is assumed to happen in rare cases only...