Re: [Libmesh-users] Linking problem (libpmpich++.a)

[Roy Stogner <roystgnr@ic...>]

On Sat, 12 Feb 2011, Rafa Rodríguez Galván wrote:

> I used to work with dynamic linking in my personal computer, but suppose
> I'll try static linking, at least while cluster admins do not provide a
> libmpich++.so. And I'll try also METHOD=prof.

Oh, pay no attention to my METHOD=prof suggestion, unless you really
also need profiling output.  I forgot about --disable-shared, and if
that's working properly then it's a *much* more flexible way to do
things.
---
Roy

Re: [Libmesh-users] Linking problem (libpmpich++.a)

[Rafa Rodríguez Galván <rafael.rodriguez@uc...>]

I used to work with dynamic linking in my personal computer, but suppose 
I'll try static linking, at least while cluster admins do not provide a 
libmpich++.so. And I'll try also METHOD=prof.

Tank you!

Rafa.

El 12/02/11 02:48, Derek Gaston escribió:
> On Fri, Feb 11, 2011 at 6:42 PM, Derek Gaston<friedmud@...>  wrote:
>
>> It's a lot easier than that.  Just configure libmesh with "./configure
>> --disable-shared"
>>
>>
> BTW - This is the way we configure libMesh on all of our clusters here.  The
> reason?  If multiple people are pulling from the same libMesh area we would
> screw up everyone's executables every time we update libMesh.  With static
> linking that's not a problem... they will just get the updated libMesh next
> time they compile.
>
> We do also have a non-default libMesh module that is dynamically linked...
> because that's the only way to use TBB.  But users of that module are made
> aware that they need to make sure and keep their executables up to date.
>
> Now... for development shared libraries are EXTREMELY useful... at a
> previous job we did all development with static linking... it was a
> nightmare.  So much more useful to be able to make a small change to a
> libraries .C and recompile the library and _not_ relink every library and
> executable that depends on it.
>
> Derek
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Libmesh-users mailing list
> Libmesh-users@...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] Linking problem (libpmpich++.a)

[Derek Gaston <friedmud@gm...>]

On Fri, Feb 11, 2011 at 6:42 PM, Derek Gaston <friedmud@...> wrote:

> It's a lot easier than that.  Just configure libmesh with "./configure
> --disable-shared"
>
>
BTW - This is the way we configure libMesh on all of our clusters here.  The
reason?  If multiple people are pulling from the same libMesh area we would
screw up everyone's executables every time we update libMesh.  With static
linking that's not a problem... they will just get the updated libMesh next
time they compile.

We do also have a non-default libMesh module that is dynamically linked...
because that's the only way to use TBB.  But users of that module are made
aware that they need to make sure and keep their executables up to date.

Now... for development shared libraries are EXTREMELY useful... at a
previous job we did all development with static linking... it was a
nightmare.  So much more useful to be able to make a small change to a
libraries .C and recompile the library and _not_ relink every library and
executable that depends on it.

Derek

Re: [Libmesh-users] Linking problem (libpmpich++.a)

[Derek Gaston <friedmud@gm...>]

2011/2/11 Roy Stogner <roystgnr@...>

> If they balk and you're stuck having to build a statically-linking
> libmesh.a, then as a workaround try building libMesh with
> "METHOD=prof".  Someone correct me if I'm wrong, but I think that
> should give you a static library, so you'll at least be able to link
> applications against non-PositionIndependentCode dependencies.
>

It's a lot easier than that.  Just configure libmesh with "./configure
--disable-shared"

Derek