Date: Tue, 23 Jan 1996 11:02:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: chuckr@glue.umd.edu (Chuck Robey) Cc: FreeBSD-current@freebsd.org Subject: Re: Threads breaking compile Message-ID: <199601231802.LAA17886@phaeton.artisoft.com> In-Reply-To: <Pine.SUN.3.91.960122210626.11112A-100000@cappuccino.eng.umd.edu> from "Chuck Robey" at Jan 22, 96 09:10:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> A variable called __thread_init was breaking libmytinfo, so I waited for > the next ctm update, now the same thing is breaking even xinstall. Oh, > well, here's the error listing from libmytinfo, on my other machine, the > same error is infecting xinstall. > > ===> libmytinfo > cc -O -Wall -I/usr/src/lib/libmytinfo -c /usr/src/lib/libmytinfo/addstr.c > -o addstr.o > cc -O -Wall -I/usr/src/lib/libmytinfo -o mkcaplist > /usr/src/lib/libmytinfo/mkcaplist.c readcaps.o > /usr/lib/crt0.o: Undefined symbol `__thread_init' referenced from text > segment > *** Error code 1 > > Could someone please look at this? I don't understand why _thread_init isn't being inserted into a linker set that is called for initialization at startup time (per C++ virtual base class constructor initialization). It *should* be possible to live without the thing in any cause, causing initialization to occur on first reference. I have grave misgivings on setting up a default threading environment for non-threaded applications: it is a real waste. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601231802.LAA17886>