Date: Sat, 25 May 1996 14:43:08 +1000 (EST) From: John Birrell <cimaxp1!jb@melb.werple.net.au> To: Glue.umd.edu!chuckr@melb.werple.net.au (Chuck Robey) Cc: freefall.freebsd.org!freebsd-current@melb.werple.net.au Subject: Re: libc_r Message-ID: <199605250442.OAA25529@melb.werple.net.au> In-Reply-To: <Pine.OSF.3.91.960524173206.6765D-100000@professor.eng.umd.edu> from "Chuck Robey" at May 24, 96 05:33:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Anybody know the status of the libc_r threads library? Does it work? There have been changes to files fork.S, pipe.S, sigpending.S and sigreturn.S which won't compile with _THREAD_SAFE because they have too many arguments for the macro PSYSCALL (which takes care of the #ifdef for _THREAD_SAFE). I don't know why these changes were made. The file uthread_select.c needs a fix to work with the X libraries. Other than that it should work. I say *should* because I'm running 2.1.0R on our system at the moment (The slightest mention of VM changes ruins my day 8-). Our application programs link against the code from the libc_r directory, but it is built using our code management system, not make so I can't even claim that libc_r will build as it is now. FWIW, our factory monitoring and control software is fully functional using the (non-threaded) X libraries on the 2.1.0R CD and the libc_r code. The source for this contains over a million lines of documented code built into 62 shared libraries. Under FreeBSD on a 486/50 with 16Mb of memory running X, the system can still execute PLC code faster than the fastest Allen Bradley PLC. Regards, -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 6900 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605250442.OAA25529>