[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
Thu Jul 27 10:53:59 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 lupus at ximian.com.


--- shadow/78767	2006-07-27 07:30:06.000000000 -0400
+++ shadow/78767.tmp.11765	2006-07-27 10:53:59.000000000 -0400
@@ -3,21 +3,21 @@
 Version: 1.1
 OS: unknown
 OS Details: 
 Status: NEW   
 Severity: Unknown
-Priority: Blocker
+Priority: Normal
 Component: JIT
 AssignedTo: lupus at ximian.com                            
 ReportedBy: michael at ximian.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
-Summary: incorrect TLS usage ...
+Summary: can't load libmono as a module
 Something -really- bad happens when dlopening libmono requiring libraries,
 as done by the OO.o integration.
 To debug that simply compile / run the attached sample in
 /usr/lib/ooo-2.0/program on a SLED10 system with the OpenOffice_org-mono
@@ -168,6 +168,22 @@
 ------- Additional Comments From michael at ximian.com  2006-07-27 06:45 -------
 I wonder if: the -mno-tls-direct-seg-refs compile option might have
 something to do with exacerbating the problem ? I'll try without that.
 ------- Additional Comments From michael at ximian.com  2006-07-27 07:30 -------
 shot in the dark, but removing that compile flag didn't help :-)
+------- Additional Comments From lupus at ximian.com  2006-07-27 10:53 -------
+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.
+Allowing this corner case usage would slow down all the users of
+libmono (possibly including the mono command itself since it was in
+the plan to just link it dynamically with libmono as the current
+correct usage of the tls attribute allows it to be basically as fast
+as statically linking).
+There are two alternative solutions:
+*) provide a libmono-module.so compiled without optimized __thread
+support and make corner cases like ooo's use that
+*) change the ooo binding to not load libmono as a module
+Obviously the -mno-tls-direct-seg-refs flag has no relation to this issue.

More information about the mono-bugs mailing list