On Wed, Jul 17, 2013 at 03:02:16PM +0000, Jeff Squyres (jsquyres) wrote:
> On Jul 17, 2013, at 10:48 AM, Nathan Hjelm <hje...@lanl.gov> wrote:
>
> > I must be missing something here. type_size.c contains MPI_Type_size and
> > MPI_Type_size_x and I see all the MPI and PMPI variants in the resulting
> > .so, .dylib, and .a.
>
>
> If you have a nathan.c file with:
>
> -----
> void MPI_foo() { ... }
> void MPI_bar() { ... }
> -----
>
> This will result in defining both symbols in that nathan.o file, which ends
> up in libmpi.so.
>
> Then if someone writes a code like this:
>
> -----
> int main() {
> MPI_Init();
> MPI_Foo();
> MPI_Bar();
> MPI_Finalize();
> return 0;
> }
> -----
>
> And then they interpose their own version of MPI_Bar() with their
> libinterposition.so, *it won't work* (meaning their version of MPI_Bar()
> won't be called).
>
> This happens because the linker will first see MPI_Foo() in main and resolves
> it. When it resolves the MPI_Foo symbol, it pulls *all* symbols out of the
> .o from where MPI_Foo came (i.e., nathan.o in libmpi.so) -- i.e., including
> MPI_Bar.
>
> So when MPI_Bar goes to get executed, it's *already been resolved* to the one
> in nathan.o/libmpi.so, not the one from libinterposition.so.
>
> Even worse, if they reversed the order of foo/bar in main, then the linker
> would likely give you a duplicate symbol error because it will first resolve
> MPI_Bar from libinterposition.so, and then later resolve MPI_Foo from
> libmpi.so, but it will also pull MPI_Bar from libmpi.so -- kaboom.
>
> Linkers are insanely complicated.
Ugh. Thats unfortunate. I guess I could add a type_size.h and put the static
inline function in there then put the definions of MPI_Type_size_x and
MPI_Type_size in their own files. This way I can still avoid the extra code.
-Nathan
