[Mono-list] strange mono initialization problem

[John Sohn]

> The io-layer stuff is supposed to be internal to mono anyway.

It seems the reason the embedded Mono segfaults with dynamic linking is
because it is calling Wine version of these functions. When the static
version is used it calls the correct Mono version of these functions.

> A possible solution to the problem is to use a linker version script
> so that those functions are not exported by the libmono library
> (it would be a good idea to implement this in any case, IMHO).
> have a file that reads:
> == snip snip ==
> VER_1 {
> 	global: 
> 		mono_*;
> 	local:
> 		*;
> };
> == snip snip ==
> And then add to jit/Makefile.am:
> 
> libmono_la_LDFLAGS=--version-script=ldscript
> 
> Can you test if that fixes the shared libmono issue when linking to
> libwine?
> 

I am not familiar with this process but I created a file called ldscript
with the contents above and added the libmono_la_LDFLAGS as shown above.
If I did this correctly I am still getting a segfault when dynamically
linking the library. The debugger is still stepping into the Wine
TlsAlloc (when called inside of mono) instead of Mono's. It seems as
though libmono.so is calling the wrong (WineLib) version of TlsAlloc.
This is happening within the mono_init function.

> The other solution is to not embed mono in a wine application or do the
> trick that dietmar suggests (but this implies a different libmono: we
> don't want to link to libwine in the general case).
 
A WineLib "application" is a shared library that is created to run
within the Wine environment. The resulting shared library is then
invoked and executed by the wine command. For example, if test.exe was
the application name on Windows, the wine build process on Unix will
create a shared library called test.exe.so. This shared library is then
started and executed within the Wine environment (on the command line)
as: wine test.exe.so. In a sense the WineLib application is an extension
of the Wine environment. It is kind of confusing because the resulting
application created for WineLib is not really an application but a Unix
shared library.

> If libwine is used to implement the S.W.Forms classes, can't it be
> used with P/Invoke? What is the reason you choose to embed mono instead
> of using P/Invoke on libwine? ...

I tried several different ways of calling Win32/WineLib functions within
a Mono compiled application but the only way I was able to get Mono and
Wine code to execute within these environments was to embed the JIT
engine inside of a small WineLib application. The two .c files in CVS
under mcs/class/System.Windows.Forms/WINELib creates a WineLib
application (monostub.exe.so) that accepts the name of a mono executable
to run on the command line. This application is very small but since the
application is executing under Wine all Win32 functions are now
available as you mention using DllImport. This application enables any
of the WineLib/Win32 functions to be available to Mono applications when
they are started under using this application instead of the regular
"mono" command.

So as far as I can tell, the Mono engine needs to be embedded in a small
application that will run under the WineLib environment. Creating an
application for WineLib (unfortunately) is not as easy as gcc mywinapp.c
-lwine. At this point DllImport's can then be used (running inside this
WineLib/embedded Mono application) to access all of the Win32/WineLib
API.

John