[Mono-list] strange mono initialization problem

[Paolo Molaro]

On 08/24/02 John Sohn wrote:
> > 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.

Sorry, I was sloppy (I went from memory): the change to
Makefile.am should read:

diff -u -r1.35 Makefile.am
--- Makefile.am	12 Aug 2002 10:05:51 -0000	1.35
+++ Makefile.am	24 Aug 2002 10:36:44 -0000
@@ -3,6 +3,8 @@
 	$(GMODULE_CFLAGS)		\
 	$(GLIB_CFLAGS)
 
+libmono_la_LDFLAGS=-Wl,-version-script=ldscript
+
 if X86
 bin_PROGRAMS = mono
 lib_LTLIBRARIES = libmono.la

i.e. with -Wl,... otherwise the option is not passed down to the linker.
You can then check with:
	nm -D .libs/libmono.so|grep ' T '

that only symbols starting with "mono_" are exported.
Can you retest with that change?

> > 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.

Yeah, I know that. It's fine for testing if implementing S.W.Forms
works out using wine (BTW, thanks for doing that!). It's just that it's
not a possible long-term solution, IMHO, having two different mono
loaders, one linked to libwine that can use S.W.F and one that can't.
Anyway, maybe we can discuss this later with the wine people if your
experiments turn out to work.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better