From owner-freebsd-hackers Tue Mar 25 15:17:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19304 for hackers-outgoing; Tue, 25 Mar 1997 15:17:46 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19291 for ; Tue, 25 Mar 1997 15:17:39 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id QAA19298; Tue, 25 Mar 1997 16:15:50 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199703192044.HAA07624@freebsd1.cimlogic.com.au> Date: Wed, 19 Mar 1997 14:37:27 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: John Birrell Subject: Re: FW: threads... Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanx a million. We will follow up... Simon Hi John Birrell; On 19-Mar-97 you wrote: > 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