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
[email protected]
https://lists.sourceforge.net/lists/listinfo/fink-devel
