On Fri, Jun 25, 2004 at 05:09:08PM -0400, Joe Marcus Clarke wrote: > On Fri, 2004-06-25 at 16:44, John Merryweather Cooper wrote: > > I'm working on porting (and getting fully working) lang/mono > > version 0.96, and I'm having a problem. In one of my object > > files--mini.lo--I'm getting an extern reference to > > ___tls_get_addr. I've been over the source code in mini.c > > and all the included headers, and I can't find anything to > > get rid of this reference or find a way to resolve it. As > > a result, the linking of the mono runtime binary fails with > > this symbol unresolved. > > > > Any and all clues are welcome! > > As I recall, this is from boehm. You'll have to tell boehm not to do > thread-local storage. Note: boehm is in the libgc subdirectory inside > mono. > > Joe > > > > > jmc > > _______________________________________________ > > freebsd-gnome_at_freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-gnome > > To unsubscribe, send any mail to "freebsd-gnome-unsubscribe_at_freebsd.org" > -- > PGP Key : http://www.marcuscom.com/pgp.asc > > Hmmm . . . Well, looking at the libgc code, I note that if it detects GCC 3.x it uses pthreads for thread local storage. The configure script doesn't provide a means to turn off tls. Just to be sure, I undefined USE_COMPILER_TLS on the command line with -UUSE_COMPILER_TLS. No dice, ___tls_get_addr still shows up in the mini.lo object which gets linked into libmono.so which causes mono to fail to link with an undefined symbol (see attached build script). I've checked all the objects in libgc, and none of them are defining this symbol. It seems prettly clear that it comes into existance during the compile of mini.c (it's in mini.lo), but I can't for the life of me find were it is in mini.c or in it's includes. jmc
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:59 UTC