Lisandro Dalcin wrote: > I think that the real problem here is that developers should be > smarter and they should not use such short names for a library... "ml" > .. just two characters... What "ml" stand for? "mailing list"? the > internet country code for Mali at Africa? "milliliter" ? "Markup > Language", "ML" the programming language? Well... I'll stop here...
Yes, that's insane. The name ML doesn't even appear in the associated header file, the closest thing is a class named CvANN_MLP. I posted this issue on their forum so maybe they'll fix it. > IMHO, I think that what Jed suggested in previous mail about using > -Wl,-whole-archive ${PETSC_EXTERNAL_LIB} -Wl,-no-whole-archive when > --with-shared is in action could be a VERY good idea... Then PETSc > link lines will not need to refer at all to these static libs from > external packages... As Satish and Matt say, this can cause some trouble. The current state is a bit mixed in that static libs get pulled into libpetsc*.so (only the symbols that PETSc requires), but shared libs get resolved by the loader (with rpath). I think putting these symbols in libpetsc*.so is the right thing to do because only explicitly linking the interface is normal on systems with shared libs. With static libs, it is normal to have to link recursive dependencies. This is a pain in the ass when you aren't using the upstream build system. In particular, given the strings A_LIBS and B_LIBS (both including recursive dependencies, suppose there is no overlap), it's pretty much impossible to link both portably because AB_LIBS = $A_LIBS $B_LIBS will incorrectly resolve stuff in B_LIBS from paths used by something in A_LIBS. Some people say "your environment is broken" when this is the case, but it's easy to end up with when the package manager puts some stuff in /usr and you install some libs elsewhere. The only workaround I know is to manually resolve all the libraries in A_LIBS and B_LIBS separately. Unfortunately, dealing with all of this is essentially a part of your API when using static libraries. Bundling the symbols from the various static libs into libpetsc*.a means that users can link the same way and don't have to resolve recursive dependencies. > Satish, please note that I'm talking about using --whole-archive ONLY > with the pkgs that PETSc automatically downloads upon user requests > using --download-<pkg> ... Note that the current system still puts the necessary symbols from all static libs into libpetsc*.so. Putting them into libpetsc*.a (a) makes the linking API uniform, -L/path/to/petsc/lib -lpetsc* (b) causes a problem if they update that lib, don't update PETSc, and then expect their code to be calling the updated version Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091029/4d270cb6/attachment.pgp>