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