[Mono-bugs] [Bug 78767][Nor] Changed - can't load libmono as a module

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Wed Aug 9 07:06:53 EDT 2006


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by michael at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=78767

--- shadow/78767	2006-08-09 06:33:13.000000000 -0400
+++ shadow/78767.tmp.14653	2006-08-09 07:06:53.000000000 -0400
@@ -227,6 +227,41 @@
 /tmp/cc6u2lae.s: Assembler messages:
 /tmp/cc6u2lae.s:16: Error: `mono_lmf_addr at GOTTPOFF(%rip)' is not a
 valid base/index expression
 make: *** [all] Error 1
 
 
+
+------- Additional Comments From michael at ximian.com  2006-08-09 07:06 -------
+Zoltan wrote:
+> michael, could you try that change with OO ? I.e. change the
+> MONO_THREAD_VAR_OFFSET defines in utils/mono-compiler.h to the above?
+
+Yes - I tried this (with a suitable #undef) here is what happened:
+
+TLS               VAR_OFFSET          Result
+initial-exec      <as normal>         crash
+initial-exec      -1                  crash
+local-dynamic     <as normal>         crash
+local-dynamic     -1                  * works * :-)
+
+And of course OO.o works fine with the last case here.
+
+> Paolo wrote:
+> As I told michael already, our usage of the tls attribute is
+> correct for a shared library. At the time I tracked down the
+> issue to the loading of libmono at runtime, as a module.
+
+So - the semantic difference between a shlib and a module is unclear
+to me. However - if we want people to add Mono scripting support to
+their applications, this will of course frequently be done using
+plugins - OO.o is just the tip of the iceberg: Mozilla, gedit ;-) ...
+
+Apps in general will not want to hard link directly to libmono if they
+can avoid it, that sort of hard build & run-time dependency is rather
+unpleasant surely [ not to mention degrading startup performance for
+when it's not actually used ].
+
+Wrt. renaming libmono - to libmono-module: if that works for you, I'm
+fine with it [ any solution is good I guess ;-]. OTOH - surely having
+a statically linked version to 'mono' will make 'mono' even smaller,
+more efficent & faster to start.


More information about the mono-bugs mailing list