Re: [jamboost] order of static and dynamic libraries

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-04-28 14:17:44

Toon Knapen wrote:

> Rene Rivera wrote:
> 
>>Toon Knapen wrote:
>>
>>>I have a dynamic library 'bar' that calls MPI routines (or whatever 
>>>third party library) that are defined in a static library. Now my 
>>>executable 'foo' calls a function defined in 'bar' and also calls MPI 
>>>functions.
>>>
>>> foo.exe ----calls----> bar.so ----calls-----> MPI (mpich.a, pmpich.a)
>>> | ^
>>> |---------------------------------------------
>>>
>>
>>In your small example I do have a question... Why do you add the MPI 
>>dependency to the foo.exe instead of adding it to the bar.so, which is 
>>the one that has the real requirement? Doing that instead would solve 
>>the link order problem in this case.
>>
> 
> 
> I thought about doing this. This would mean that the mpi functions are 
> defined in bar.so as well. So when linking foo.exe with bar.so and 
> libmpich.a I was afraid to have multiple defines or blowing up the size 
> of the exe. But probably my fear is unjustified since the linker will 
> just drop the second (and up) definition of the MPI function. right ?

I'm not sure the linker would be that smart. It might work that way for 
ELF, but it's not likely work that way for win32 where reverse binding 
is not automatic. The only way to find out is to look at the resulting 
symbols in bar.so. If "nm" shows weak symbols for the MPI functions it 
will use the ones from the exe. If it shows global symbols, it's making 
two different copies in the exe and the so.

> However this is not a real clean solution IMO because suppose that I 
> create bar.so but somebody else uses my bar.so and links foo.exe. Now my 
> bar.so contains (part of) the MPI library definitions. If somebody else 
> now links with bar.so _and_ links with the MPI libraries installed on 
> _his_ machine, he's possibly linking the application with 2 different 
> versions of the MPI libaries which might result in strange behaviour.

The only real solution I can see is to put the MPI functions in a shared 
library. It's the only way to guarantee a single runtime binding on 
different platforms.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq