[Mono-list] strange mono initialization problem

Paolo Molaro lupus@ximian.com
Fri, 23 Aug 2002 12:27:20 +0200

On 08/23/02 Dietmar Maurer wrote:
> > These functions in WineLib are getting called from the Mono JIT code
> > instead of the correct functions in libmono (mono/io-layer/threads.c).
> This is intentional! Our io-layer abstraction simulates the MS function,
> so you don't compile the whole io-layer if you are on a MS compatible
> platform. Take a look at the io-layer/Makefile.am:
> libwapi_la_SOURCES = $(WINDOWS_SRC)
> libwapiinclude_HEADERS = $(WINDOWS_H)
> else
> libwapi_la_SOURCES = $(OTHER_SRC)
> libwapiinclude_HEADERS = $(OTHER_H)
> endif
> I assume you have do to something similar if you link with wine.

Yes, but that would mean having a different mono runtime (and I'm not
sure it would work that way).
The io-layer stuff is supposed to be internal to mono anyway.
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 {
== snip snip ==
And then add to jit/Makefile.am:


Can you test if that fixes the shared libmono issue when linking to

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

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? If you stick to that, the wine
implementation of S.W.Forms won't be used generally, since we're not
going to distribute a mono runtime linked to libwine:-)


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