Jack Howarth wrote: [] > release. However the openmpi developers have > renamed the libopal.0.0.0.dylib and the > liborte.0.0.0.dylib share libraries as > libopen-pal.0.dylib and libopen-rte.0.dylib. > It appears that the release is supposed > to be backwardly compatible even with this > change as long as the packages using openmpi > use the provided compiler tools to build. > Could everyone check if their packages > using openmpi explicitly links in > libopal or liborte into their programs > or libraries? I assume as long as these > were indirectly pulled in from the > other openmpi libraries instead that > we will be okay. I would really like to > avoid creating another forked openmpi > package despite the fact this this violates > the fink rule of changing the names of > distributed libraries.
In the new paraview-mpi-openmpi package, I was indeed forced to link to libopal in order to avoid undefined symbols. openmpi/libmpi.dylib has lots of undefined symbols that are defined in libopal. But here is an idea how you could maintain compatibility, assuming that the new libraries are really binary compatible: In the openmpi-shlibs package, add a symlink libopal.0.dylib -> libopen-pal.0.dylib In this way, binaries that were linked with the old libopal will find the new library under the old install_name and everybody will be happy. -- Martin ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
