keeping source trees

Jesse Tie Ten Quee tie at
Tue Jun 6 19:45:07 PDT 2000


> I'm wondering how important it is to keep around the source trees for the
> various packages I've installed. The kernel source tree makes sense, since
> there are obviously other programs that make use of some of these header
> files. I also found while installing openssh that it looked for a header
> file from another package (I forget which one, off hand). But generally
> speaking, can these be deleted, or will they be needed?

There is little reason to keep the src trees around (except the
kernel's) unless you like too or have more space then brains (j/k :).

OpenSSH either has a issue or my system does (i don't think it's OpenSSH)

I originally installed 2.1.0, since then i've upgraded to 2.1.0p1, 2.1.0p2
and 2.1.0p3 about 5 minutes ago.

Each time it has a problem with Zlib's header files which are located at
/usr/local/include/[zlib.h, zconf.h], the offender is compress.c (line 21,
#include "zlib.h")

At first i though it was the include statement, where you really should be
using <header.h> instead of "header.h" for system wide header files
(IMHO), but that didn't help, so i just copy'd the
/usr/local/include/zlib.h to the src dir and reran make and everything
worked fine.

I've noticed this all the time on my server, for all 2.1.x releases.

but i began thinking and started playing with it...

cd /usr/include;
ln -s ../local/include/zlib.h
ln -s ../local/include/zconf.h

and tried again (2.1.0p3), now this time it did find the header files and
compiled just fine...

So either OpenSSH Makefile(s) are messed up... i didn't install Zlib
properly... or my system isn't looking in /usr/local/include for header

Anyone want to enlightent me? or even your thoughs... *g*


Jesse Tie Ten Quee - tie at - tie at

Mail archive:
IRC access: server: port: 6667 channel: #LFS
News Reader access:
Unsubscribe: email lfs-discuss-request at and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)

More information about the lfs-dev mailing list