I'm using mkbundle and trying to create an embedded version of a little program IdaTester that uses Isis2. That system in turn uses features from Mono that depend on MonoPosixHelper
My problem is that mkbundle doesn't recognize the dependency and I end up with an executable that still needs to dynamically link against ~/bin/lib/libMonoPosixHelper.so, causing problems when I move this executable to a system where I don't have Mono installed. In effect, the bundle is missing one of the things it should be statically linked against.
My executable does work, but only if I make sure to run it only on machines that have the dynamic library in the "right place". This defeats the purpose of an embedded executable... I was hoping to be able to hand people this program as a kind of server they could put anywhere and launch as a binary, and obviously if they need to install the library for this to work, the server isn't exactly standalone!
I see how to force mkbundle to include any dll files the program depends upon, but MonoPosixHelper doesn't exist as a dll; this is a Linux-only library and exists only as a shared library. Does anyone know of a way to "force" the bundle to embed it statically?
In case this helps, my little compile script is as follows:
mcs -debug+ IdaTester.cs Isis.cs -r:System.dll -r:Microsoft.CSharp.dll -r:Mono.Posix.dll
mkbundle --static -o IdaTester IdaTester.exe --deps
I then run IdaTester; this works on platforms where the libMonoPosixHelper library can be found, but will fail at runtime when trying to dynamically load that library if running on a platform where libMonoPosixHelper hasn't been installed...
As far as I can tell, the best option available to me is either to build a non-shared Mono library containing the same methods as are currently found in MonoPosixHelper.so, or to provide a copy of MonoPosixHelper.so as a component to be installed in the same folder as my server. Neither seems ideal: the former forces me to "reach into" the Mono distribution, which creates a longer term maintenance issue, while the latter forces me into a more complex distribution and installation mode. But it seems that once one generates a shared library, you simply can't statically link against that version of the library; the Linux loader just doesn't treat such a thing as a library in the way it handles more standard libraries.
In contrast, if I do generate a standard library from the same .o files, the loader will be happy to statically link against it, and because mxbundle ultimately runs cc and hence uses the standard ld, that option would work for me. So I guess that's the answer to my question.