From owner-freebsd-hackers Wed Mar 19 13:00:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA21738 for hackers-outgoing; Wed, 19 Mar 1997 13:00:14 -0800 (PST) Received: from werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA21728 for ; Wed, 19 Mar 1997 13:00:04 -0800 (PST) Received: (qmail 13234 invoked by uid 5); 19 Mar 1997 20:59:58 -0000 Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id HAA07624; Thu, 20 Mar 1997 07:44:52 +1100 (EST) From: John Birrell Message-Id: <199703192044.HAA07624@freebsd1.cimlogic.com.au> Subject: Re: FW: threads... To: Shimon@i-Connect.Net (Simon Shapiro) Date: Thu, 20 Mar 1997 07:44:51 +1100 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from Simon Shapiro at "Mar 19, 97 12:04:14 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > - there is name space collisions between libc and libc_r. > supposedly libc_r is a full blown replacement for libc (?). > if you link with libc_r, libc gets linked as well. since > ld assumes startup files (crt0.o and std lib c). order is > important to solve some name space problems but this causes > other non-fatal problems - like an empty stub for > _thread_init() Use libc_r _instead_ of libc. libc_r is a super-set of libc, so the name space collisions are not surprising -- they're intended! You can avoid gcc telling ld to link lib by using -nostdlib. > > - threads initialization doesn't occurr (_thread_init). there > doesn't seem to be an entry on the Construct list for this > guy in libc_r. even though I have explicitly called this > routine in the application things still don't seem to be > setup correctly. Some other missing component ???? If you link correctly, this should not be a problem. > > - threads seem to get created but their start proc never > gets executed - scheduling... > > - signals aren't reliable > > Of course the later two problems could hinge on the first. Probably. If the correct linking doesn't solve your problems, ask your developer to email me. Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137