From: ujlh@pool.info.sunyit.edu (James Henrickson) Subject: Re: find 3.7 and fileutils 3.3 uploaded Date: 31 Jul 1992 06:23:11 GMT
In article <1992Jul29.193543.1119@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>In article <dirkst.712335866@messua>, dirkst@messua.informatik.rwth-aachen.de (Dirk Steinberg) writes:
>
>| We should always use the latest official gcc release shared images for
>| uploading binaries. Starting from next release, these will be based on
>| jump-tables anyway. If you really want, you can include /lib/libc.2.2.2
>
> But uploading binaries based on shared libraries makes them break as
>soon as you upgrade your gcc. Your thought about .a files was better,
>because gcc is relatively small, and you can trim the compiler and still
>use the linker if you're all that tight for disk.
Speaking of shared libraries... :)
The biggest problem I have seen so far is the unavailability of older
shared libs. Say a new Linux user has the 2.2.2 shared libs and
downloads a binary from tsx-11 or banjo (or anywhere else for that matter)
that was compiled for an older shared lib. The user then tries to run
the program and gets a "Can't find lib ----" message, posts a frequently
asked question, and assumes that the binary is broken. We could prevent
a lot of problems by keeping the older shared libs available and adding
something about this to the FAQ.
I realize that using multiple versions of shared libs uses more memory
(and makes them not-so-shared!), but sometimes it is a necessary evil.
Personally, I'm gathering the source code for EVERYTHING so a compiler
change won't result in still another shared lib residing in memory
after I recompile. :)
-- Jim H. * * James L. Henrickson ujlh@sunyit.edu * "Yet another Jim in the Linux world." :-)