Peter,
    As I mentioned, the revised copies of lammpi.info and lammpi.patch
are now in the fink tracking system. I am considering one last set of
changes and would be interested in your opinion on them. Currently I
have added a patch to gromacs-mpi...

+++ gromacs-3.3/src/gmxlib/Makefile.in.fixed 2005-11-17 23:14:35.000000000 -0 
500 
@@ -178,7 +178,7 @@ 
 INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ 
 LDFLAGS = @LDFLAGS@ 
 LIBOBJS = @LIBOBJS@ 
-LIBS = @LIBS@ 
+LIBS = @LIBS@ -Wl,-single_module 
 LIBSUFFIX = @LIBSUFFIX@ 
 LIBTOOL = @LIBTOOL@ 
 LN_S = @LN_S@ 

...to work around the fact that common symbols exist in liblammpio.a
because it is built as non-PIC code which is silently linked into
gromacs-mpi's shared libraries by mpicc. The hack to work around this
has been described at...

http://gcc.gnu.org/ml/gcc/2005-06/msg00186.html

My understanding is that the presence of non-PIC code in a static
lib which is linked into a shared lib still makes these shared libs
broken and subject to strange crashes.

http://people.redhat.com/drepper/dsohowto.pdf

My inclination is to patch the Makefilei.in for liblammpio.a to have
all of its objects compiled with -fno-common to make them PIC code.
This would allow me to set a Depends on lammpi-7.1.1-1 for
gromacs-mpi 3.3-1 and drop the -Wl,-single_module hack in gromacs-mpi.
What is your view on this? While I can't demonstrate actual breakage in
lammpi without hack to build liblammpio.a as PIC code, it seems
obviously wrong not to do so.
            Jack


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to