Re: errors/seg-fault in hdgeant

[Richard Jones <richard.t.jones@uconn.edu>]

See my responses below.
-rtj

David Lawrence wrote:
>
> Hi Richard,
>
>    I see that the bimsel.F file is in the gelhad directory and it is 
> being compiled with by BMS with the following:
>
> gfortran -DCERNLIB_MOTIF -D_GELH_ -DCERNLIB_TYPE -I.. -I. -I.. 
> -I../include -I/Users/davidl/HallD/builds/latest/include 
> -I/usr/local/cern/PRO/include -I/usr/include/cernlib/PRO -Wall   -c -o 
> bimsel.o bimsel.F
> ar rv .lib/Darwin_macosx10.4-i386-gcc4.0.1/libgelhad.a bimsel.o
> a - bimsel.o
>
>
> Notice though that it is being placed in the gelhad library file 
> libgelhad.a. The link command from my Mac is below. The main thing to 
> note is that the bimsel.o object comes in through one of two 
> libraries. A cernlib one or libgelhad.a. The gelhad library comes 
> first on the link command, but experience tells me that does not 
> guarantee that is where the object is pulled from.

No, but nor is it a random or obscure process by which it is decided 
which object gets linked in.  It gets decided by the following rule: 
"Resolve unresolved symbols first referenced in object XXX.o by looking 
in the same library where XXX.o was found, or downstream in the link 
list."  But bimsel.o is an internal fluka routine that is not called 
from outside the fluka package.  Therefore the first place it is 
referenced is in an object pulled in from libgeant321.a, hence the first 
place it will search for bimsel.o is libgeant321.a where the calling 
fluka object is found.  So if all you do is to include libgelhad.a in 
your link path then you get the wrong one.  The simplest way to avoid 
this is to force-load bimsel.o upstream in the link list, so that its 
symbols are already defined in advance of their reference.  Look in 
Makefile.orig for how I did that.  You can also duplicate what you did 
to force-load the guXXXX.o objects to make sure you get the custom code 
for these user hook routines, and not the dummy library versions.

> I think it might be worthwhile if Mark tried using your Makefile first 
> to see if he can reproduce the problem when the executable is linked 
> in a different way since I don't think we can rule out that this isn't 
> the bug you already fixed.
>
Good idea.