[Mono-devel-list] DllImport with multiple shared libraries

Jonathan Pryor jonpryor at vt.edu
Thu Dec 23 21:10:14 EST 2004

On Thu, 2004-12-23 at 20:51 +0100, Heribert.Schuetz.extern at HVB.de wrote:
> I'm trying to call into native code from C# within Mono (on Linux). It works
> fine as long as the native function is completely implemented in a single
> shared library. If, however, this shared library requires another shared
> library, I don't know how I should tell Mono about this other library.

Short answer: you shouldn't need to.  Mono doesn't load the library, the
Linux Shared Library mechanism does, through dlopen(3).

The reason you shouldn't need to is because the library knows all the
libraries it statically depends on.  How's it know this?  Because you
provide them on the link line.

Except you're not, so everything breaks.  This is also why using
<iostream> breaks your app, you're not linking against the appropriate

The fix?  This is untested, but it should get the point across:

	all: run

		g++ -c -o $@ -fpic $<

	libnative.so : native.o libnative2.so
		g++ -shared -o $@ -L. -lnative2 $^

	libnative2.so : native2.o
		g++ -shared -o $@ $^

		mcs $<

	run: native.exe libnative2.so libnative.so
		LD_LIBRARY_PATH=`pwd` mono native.exe

The key points to keep in mind are:

1.  You're using the correct convention, *lib*native.so, not native.so.
This is Unix, not Windows, the prefix should be used (because of (2)).

2.  The libnative.so link line explicitly links against libnative2.so
(this is done by the -L. -- include the current directory in the link
path -- and -lnative2, which links against libnative2.so)

3.  You're using g++ to generate the final .so.  G++ knows to link in
the required C++ standard libraries, libstdc++.so, which should permit
you to #include <iostream> without having linker problems.

 - Jon

More information about the Mono-devel-list mailing list