[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The fate of libc5



On Mon, Jul 10, 2000 at 01:19:19PM -0400, Ben Collins wrote:
> Currently libc5 is only still supported under i386 and m68k (AFAICT). It
> hasn't been our primary libc since bo, which will be 3 releases out of
> date when potato releases. Isn't it time to get rid of this? Are there any
> compelling reasons to continue to have it around? I think most
> commercial, closed-source applications for Linux now use glibc anyway, so
> I don't see any reason at all to keep it around, except to compile all
> those old ip exploits from rootshell.com.
> 
> I think we should move libc5 out of woody very soon. A lot of very old
> cruft and hacks (ldso) are still around because of this. If we can get rid
> of libc5, ldso will become obsoleted by libc6 2.2.x (since it contains a
> very good ldconfig and ldd, and ld-linux.so.1 wont be needed anymore). It
> also means that nss1 compat modules will not beed needed, this again
> reducing the amount of cruft/hacks in the default build.
> 
> Anyone else agree, or can give a real reason why this shouldn't be the
> case?
Hi Ben,

Though I can see why libc5 seems unnecessary and outdated, if removed, some
users will be surprised to find nonworking binaries.  A quick ldd through my
/usr/local/bin shows several programs depending on libc5 which I couldn't
otherwise recompile.  l3enc, l3dec, mp3enc would suddenly stop working.

I personally have this one program which I wrote and lost the source to. 
All I have is the libc5 binary.  I wouldn't look forward to rewriting it as
it works.  In short, if keeping libc5 around is introducing problems or
causing a lot of extra work for other developers, I guess removal would be
viable.  However, if it's self-contained and someone is willing to maintain
it, what harm is there in leaving it in.

Just my $0.02,
Shane

-- 
Shane Wegner: shane@cm.nu
Personal website: http://www.cm.nu/~shane/

Attachment: pgpgolD6fYJI1.pgp
Description: PGP signature


Reply to: