On Thu, Oct 29, 2009 at 7:01 PM, Satish Balay <balay at mcs.anl.gov> wrote: > On Thu, 29 Oct 2009, Barry Smith wrote: > >> >> On Oct 29, 2009, at 3:52 PM, Lisandro Dalcin wrote: >> >> > On Thu, Oct 29, 2009 at 4:45 PM, Jed Brown <jed at 59a2.org> wrote: >> > > >> > > I realize that the real problem here was OpenCV's libml and the fact >> > > that linkers don't resolve symbols by starting with the most recent -L >> > > path [*], but we should at least remember that putting -L{PETSC_LIB_DIR} >> > > at the beginning of the line can completely change the way symbols are >> > > resolved. >> > > >> > >> > 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... >> > :-) >> > >> > 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... > > This works for folks who use PETSc - and nothing else. But once you > have 2 packages doing this [say both add in hypre symbols] - and then > some user wants to use these two packages - you have conflicts. [esp > with multiple copies of global variables etc..] >
And can you explain me how the current situation is better? Let's suppose other self-contained beast like PETSc also builds a static hypre lib... then when you mix stuff, you have two libhypre.a at different places... Then you link your program... and the linker will likely pick one... which one? whatever... All this works by accident, I think... So I still think that for petsc-downloaded external packages built as static libs, the -W,-whole-archive should be used... If this is not what users want, then they should previously build these ext packages themselves and pass info to configure.py... After all, when I ask PETSc to download a pkg is because I do not have it built/installed... for example, I never petsc-download blas/lapack because I have them in my boxes... The same applies with MPI, I've never --download-mpi... 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> ... > > The ideal solution is to have every library have its own .so > file.. [but this is not easy] > > Satish > Yes... Perhaps it is not that hard... -- Lisandro Dalc?n --------------- Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC) Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC) Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET) PTLC - G?emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594