ML symbols in petscksp.so

[Lisandro Dalcin]

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