Skip site navigation (1)Skip section navigation (2)
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>