ML symbols in petscksp.so

[Jed Brown]

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- ...

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: 

ML symbols in petscksp.so

[Jed Brown]

Jed Brown wrote:
> Jed Brown wrote:
>> Satish Balay wrote:
>>> I don't see any changes in the 'shared' target for linux [in conf/rules]
>>>
>>> And I just did a build with current petsc-dev - and see a bunch of ML_ 
>>> symbols
>> Thanks Satish.  Wiping externalpackages and PETSC_ARCH was enough.
> 
> I spoke too soon.

Okay, my problem was that a completely different package (OpenCV, a
dependency for something else) installed a libml in /usr/lib, the timing
was just coincidental.  Since I keep some libraries in /usr (like
parmetis and hdf5), -L/usr/lib came before -L${PETSC_LIB_DIR} in
PACKAGES_LIBS, therefore the wrong libml was linked in shared_linux.
OTOH, the correct one was linked for the examples because
-L${PETSC_LIB_DIR} was prepended to the link line.  The complete story
follows, in case someone else runs into this issue.


So I had

/usr/lib/libml.so (opencv)
$PETSC_DIR/$PETSC_ARCH/lib/libml.a ($PETSC_LIB_DIR/libml.a)

The link for shared_arch is effectively

  -L/usr/lib -L${PETSC_LIB_DIR} -lml

which brings in /usr/lib/libml.so which doesn't resolve anything, but
the linker doesn't complain about unresolved symbols because it was
building a shared library.  Now we might expect an example to actually
fail over this, but that is linked with

  -L{PETSC_LIB_DIR} -lpetsc* ${PETSC_EXTERNAL_LIB_BASIC}

so this time it is resolved to the correct $PETSC_LIB_DIR/libml.a.


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.


Jed


[*] I find PETSc link lines to be slightly deceptive.  They often look
like

  -L/A -rpath=/A -lA -L/B -rpath=/B -lB

with the implication that it would resolve to /A/libA.a /B/libB.a, but
the linker will find /A/libB.a if it exists.

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: 

ML symbols in petscksp.so

[Lisandro Dalcin]

On Thu, Oct 29, 2009 at 7:01 PM, Satish Balay  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  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- ...


>
> 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

ML symbols in petscksp.so

[Lisandro Dalcin]

On Thu, Oct 29, 2009 at 4:45 PM, Jed Brown  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...




-- 
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

ML symbols in petscksp.so

[Satish Balay]

On Thu, 29 Oct 2009, Lisandro Dalcin wrote:

> >> > 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?

Yes the current situation doesn't fix the above problem.

> 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...

Yes. it becomes harder. The thing I keep recommending in these cases
is: make sure only one copy of the package is in the whole chain of
packages. [just like we keep recommending - use the same compile to
compile every package, use the same MPI across all packages etc..]

[note the problem with sharedlibraries can exists even if only one
copy of a package is maintained]

> 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- ...

Since the curent thing is broken anyway - I guess I shouldn't object to
this change..

satish

> 
> 
> >
> > 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...
> 
> 
> 
> 

ML symbols in petscksp.so

[Matthew Knepley]

On Thu, Oct 29, 2009 at 4:01 PM, Satish Balay  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  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..]
>
> The ideal solution is to have every library have its own .so
> file.. [but this is not easy]
>

I am with Satish here. This smells like sticking pregenerated template stuff
in libraries,
which eventually gets heinous, and everyone always goes back to all headers.
I am
for keeping each package in its own libraries.

  Matt


> Satish
>
-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL: 

ML symbols in petscksp.so

[Satish Balay]

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  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..]

The ideal solution is to have every library have its own .so
file.. [but this is not easy]

Satish

ML symbols in petscksp.so

[Barry Smith]

On Oct 29, 2009, at 3:52 PM, Lisandro Dalcin wrote:

> On Thu, Oct 29, 2009 at 4:45 PM, Jed Brown  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...

Agreed.

Barry


>
>
>
>
> -- 
> 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

ML symbols in petscksp.so

[Jed Brown]

Jed Brown wrote:
> Satish Balay wrote:
>> I don't see any changes in the 'shared' target for linux [in conf/rules]
>>
>> And I just did a build with current petsc-dev - and see a bunch of ML_ 
>> symbols
> 
> Thanks Satish.  Wiping externalpackages and PETSC_ARCH was enough.

I spoke too soon.  It worked with the minimal

--with-shared --with-blas-lapack-dir=/usr --with-mpi-dir=/usr --download-ml

but the symbols are missing with my usual options

--with-shared --with-{blas-lapack,umfpack}-dir=/usr 
--with-{mpi,parmetis,zoltan,hdf5}-dir=/usr 
--download-{ml,blacs,chaco,superlu,superlu_dist,spooles,sundials,hypre,spai,scalapack,mumps}
 --with-{sowing,c2html,lgrind}


Here are my build logs if you want to have a look, otherwise I'll
investigate tomorrow.

http://59A2.org/files/petsc-builds.tar.bz2

PETSC_ARCH=ompi-ml has all the symbols, PETSC_ARCH=ompi is only missing ML 
symbols.



Jed

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: 

ML symbols in petscksp.so

[Jed Brown]

Satish Balay wrote:
> I don't see any changes in the 'shared' target for linux [in conf/rules]
> 
> And I just did a build with current petsc-dev - and see a bunch of ML_ symbols

Thanks Satish.  Wiping externalpackages and PETSC_ARCH was enough.  It
just didn't work when I only wiped the ML-related stuff and
reconfigured.  I'm not sure what I missed, but sorry for the confusion.

Jed

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: 

ML symbols in petscksp.so

[Jed Brown]

Barry Smith wrote:
> 
>   We do do this for Mac (libpetsc*.dylib) and I think it mostly works.
> But I am not aware of anyone doing this intentionally for PETSc on Linux
> (though I think it is a good idea if it can be done).

It has been working for more than a year on Linux.  If you still have a
--with-shared build from last week, run

$ nm -D $PETSC_ARCH/lib/libpetscksp.so |grep ML_  # I have over 800 symbols

I still have all the symbols from HYPRE, Sundials, MUMPS, etc.  Only ML
was broken in the last few days.

> On Oct 28, 2009, at 4:27 PM, Matthew Knepley wrote:
>> Wenever did this, and satill don't. We use -rpath, so that you can
>> track back to the associated shared library, if it exists.

Use of RPATH is orthogonal to this, --download-* builds static libs
which get bundled into libpetsc*.so.

Jed

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: 

ML symbols in petscksp.so

[Jed Brown]

Matthew Knepley wrote:
> You always have to link the ML library if you configure for ML, right?

No, all the third party libs used to be put into the PETSc shared libs
(but not the static libs).  The easiest way to do this is with
-Wl,--whole-archive though I haven't looked at the build system to see
if this is how it is actually being done.  All the others still behave
this way, but ML is no longer included.

So if you are using shared libs, you only need to link libpetsc*.so.
This is recommended practice with shared libs, you only explicitly link
the interface libraries (those that your code actually calls into) and
let the linker handle the dependencies.  Of course when using static
libs, you need to explicitly link all the dependencies.

Jed

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: 

ML symbols in petscksp.so

[Jed Brown]

Something recently caused these symbols to get lost, meaning that users have to 
explicitly link the static libml.a.

Jed

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: 

ML symbols in petscksp.so

[Satish Balay]

On Wed, 28 Oct 2009, Jed Brown wrote:

> Barry Smith wrote:
> > 
> >   We do do this for Mac (libpetsc*.dylib) and I think it mostly works.
> > But I am not aware of anyone doing this intentionally for PETSc on Linux
> > (though I think it is a good idea if it can be done).
> 
> It has been working for more than a year on Linux.  If you still have a
> --with-shared build from last week, run
> 
> $ nm -D $PETSC_ARCH/lib/libpetscksp.so |grep ML_  # I have over 800 symbols
> 
> I still have all the symbols from HYPRE, Sundials, MUMPS, etc.  Only ML
> was broken in the last few days.

I don't see any changes in the 'shared' target for linux [in conf/rules]

And I just did a build with current petsc-dev - and see a bunch of ML_ symbols

>
./configure 
--with-mpi-dir=/home/petsc/soft/linux-Ubuntu_8.04-ia32/mpich2-1.0.8p1-gcc431 
--download-ml=1 PETSC_ARCH=arch-linux-ml --with-shared=1 && make 
PETSC_ARCH=arch-linux-ml
[petsc:petsc-dev/arch-linux-ml/lib] petsc> nm -Ao *.so | grep ML_ | grep ' T ' 
| wc -l
820
[petsc:petsc-dev/arch-linux-ml/lib] petsc> 


Satish

ML symbols in petscksp.so

[Barry Smith]

On Oct 28, 2009, at 4:37 PM, Jed Brown wrote:

> Barry Smith wrote:
>>
>>  We do do this for Mac (libpetsc*.dylib) and I think it mostly works.
>> But I am not aware of anyone doing this intentionally for PETSc on  
>> Linux
>> (though I think it is a good idea if it can be done).
>
> It has been working for more than a year on Linux.  If you still  
> have a
> --with-shared build from last week, run
>
> $ nm -D $PETSC_ARCH/lib/libpetscksp.so |grep ML_  # I have over 800  
> symbols
>

I never said it didn't work. I just said we didn't intentionally  
set it up this way.

Since Matt and I are not aware of this feature than whoever did  
set it up (or you) have to figure out why it changed for ML.

Also I said I like it.

Barry

> I still have all the symbols from HYPRE, Sundials, MUMPS, etc.  Only  
> ML
> was broken in the last few days.
>
>> On Oct 28, 2009, at 4:27 PM, Matthew Knepley wrote:
>>> Wenever did this, and satill don't. We use -rpath, so that you can
>>> track back to the associated shared library, if it exists.
>
> Use of RPATH is orthogonal to this, --download-* builds static libs
> which get bundled into libpetsc*.so.
>
> Jed
>

ML symbols in petscksp.so

[Barry Smith]

   We do do this for Mac (libpetsc*.dylib) and I think it mostly  
works. But I am not aware of anyone doing this intentionally for PETSc  
on Linux (though I think it is a good idea if it can be done).

Bartry

On Oct 28, 2009, at 4:27 PM, Matthew Knepley wrote:

> On Wed, Oct 28, 2009 at 4:14 PM, Jed Brown  wrote:
> Matthew Knepley wrote:
> > You always have to link the ML library if you configure for ML,  
> right?
>
> No, all the third party libs used to be put into the PETSc shared libs
> (but not the static libs).  The easiest way to do this is with
> -Wl,--whole-archive though I haven't looked at the build system to see
> if this is how it is actually being done.  All the others still behave
> this way, but ML is no longer included.
>
> Wenever did this, and satill don't. We use -rpath, so that you can  
> track back to
> the associated shared library, if it exists.
>
>   Matt
>
> So if you are using shared libs, you only need to link libpetsc*.so.
> This is recommended practice with shared libs, you only explicitly  
> link
> the interface libraries (those that your code actually calls into) and
> let the linker handle the dependencies.  Of course when using static
> libs, you need to explicitly link all the dependencies.
>
> Jed
>
>
>
>
> -- 
> What most experimenters take for granted before they begin their  
> experiments is infinitely more interesting than any results to which  
> their experiments lead.
> -- Norbert Wiener

ML symbols in petscksp.so

[Matthew Knepley]

On Wed, Oct 28, 2009 at 4:14 PM, Jed Brown  wrote:

> Matthew Knepley wrote:
> > You always have to link the ML library if you configure for ML, right?
>
> No, all the third party libs used to be put into the PETSc shared libs
> (but not the static libs).  The easiest way to do this is with
> -Wl,--whole-archive though I haven't looked at the build system to see
> if this is how it is actually being done.  All the others still behave
> this way, but ML is no longer included.
>

Wenever did this, and satill don't. We use -rpath, so that you can track
back to
the associated shared library, if it exists.

  Matt


> So if you are using shared libs, you only need to link libpetsc*.so.
> This is recommended practice with shared libs, you only explicitly link
> the interface libraries (those that your code actually calls into) and
> let the linker handle the dependencies.  Of course when using static
> libs, you need to explicitly link all the dependencies.
>
> Jed
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL: 

ML symbols in petscksp.so

[Matthew Knepley]

You always have to link the ML library if you configure for ML, right?

  Matt

On Wed, Oct 28, 2009 at 3:34 PM, Jed Brown  wrote:

> Something recently caused these symbols to get lost, meaning that users
> have to explicitly link the static libml.a.
>
> Jed
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL: