I have spent most of the weekend doing just that.
I had to recomp sendmail, imapd, inn, lpd and gated and still have at least
one elusive transient to identify.
Others have also identified agetty.
It is labourious and a bloody nuisance, but it does clean things up and, in
my case at least, improved both performance and space. (1.3.95 & ELF)
Cheers,
Stephen.
>
>I have installed libc.so.5.3.9
>Compiled 1.3.96
>Rebooted
>
>still get those fcntl_setlk() errors ...
>
>
>lrwxrwxrwx 1 root root 13 Apr 26 18:41 /lib/libc.so.5 ->
libc.so.5.3.9*
>-rwxr-xr-x 1 bin bin 579395 Apr 5 09:40 /lib/libc.so.5.3.9*
>
>
>----------
>From: Kai Henningsen[SMTP:kai@khms.westfalen.de]
>Sent: Friday, April 26, 1996 2:30 AM
>To: linux-kernel@vger.rutgers.edu
>Subject: Re: memtest86, built into kernel
>
>mjb@sophos.com (Matthew J Brown) wrote on 23.04.96 in <199604230750.
IAA02280@elbereth.sophos.com>:
>
>> I don't think that parity gives you that much protection, though, so
>> I'm not convinced that it's worth seeking out systems that support it.
>> ECC may be a different story.
>
>Parity _could_ be good - _if_ you could use it end-to-end. That's true for
>all error detection schemes, of course.
>
>So what we would really want to see is parity on the data bus, generated
>and checked by the devices hanging on that bus.
>
>For example, on a memory read, the CPU gets to check the RAM parity bit.
>On a I/O write, the FDC gets to check the CPU parity bit. And so on.
>
>That would catch things like oxidated connectors.
>
>Oh well, we can dream.
>
>MfG Kai
>
>
========================================================================
Stephen Davies Consulting scldad@sdc.com.au
Adelaide, South Australia. Voice: 61-8-2728863
Computing & Network solutions. Fax : 61-8-2741015