Baslinux mailing list

[sindi keesan <keesan AT sdf.lonestar.org>]

On Tue, 3 Jan 2006, David Moberg wrote:

> sindi keesan wrote:
> > libtiff ./configure says:
> > /lib/cpp fails sanity check
> >
> > I don't have any /lib/cpp nor does SW71 MANIFEST.gz.
> > Does this mean I am missing a package, that is not found in SW71?
>
> It probably wants you to link /usr/bin/cpp (which you should
> have, provided that gcc is installed) to /lib/cpp.
>
> Just execute:
> ln -sf /usr/bin/cpp  /lib/cpp
>
> > I presume cpp is c++, which is related to g++ (gnu c++).
>
> Actually, it is the C PreProcessor, but it is used for C, C++,
> and Objective-C. A good C tutorial will tell you how it works.

What normally makes this link?
I had it already on my other computer, but it was gone on this one.

I made this link and then ./configure for libtiff displayed a couple of 
pages of messages ending in

C preprocessor /lib/cpp fails sanity check.

Netpbm will not compile properly on 2.95.6, says the README, but it did 
not mention problems with 2.95.3, which I should try next.

> > SW71 also has gcc 2.95.2, which has a g++ bug, so I am not using it.
> > Does egcs have the same bug?
>
> Maybe not, but it probably has other bugs. Most modern source
> code requires gcc-2.95.3.
>
> > SW81 has a gcc 2.95.3 and a separate gcc-g++-2.95.3
> > Should I use these instead?
>
> Yes. Or at least keep them on a CD in case you need them.
SW81 install CD.

> > libpng and libjpeg compiled properly
> >
> > zlib did not
> > make test (as instructed in the README or INSTALL)
> > exited with an error message:
> >
> > In file included from /usr/include/bits/posix1_lim.h:126,
> >                 from /usr/include/limits.h:144,
> >                 from
> > /usr/lib/gcc-lib/i386-slackware-linux/egcs-2.91.66/include/limits.h:117
> > (two more lines like this)
> >                  from crc32.c:36
> > /usr/include/bits/local_lim.h:36 linux/limits.h.  No such file or
> > directory.
> > make: *** [crc32.o] Error 1
> >
> > Three .h files appear to be looking for a linux/limits.h to which I may
> > not have a pointer.  I have several files named limits.h including
> > /usr/src/linux-2.2.16/include/linux/limits.h

> > Did I mess up a symlink to the linux/limits.h that it can't find?
> > (I can't have messed up two badly since libpng and libjpeg did compile).>> I 
> > just reinstalled linuxinc.tgz which did not help.  Also glibc-2.2.5.
> > First, make a backup of /usr/include (if you mess up the links,
> you will end up with a dead compiler). Then remove
> /usr/include/linux:

I have a backup of my entire BL2 on another partition now.

> rm -rf /usr/include/linux

I did not have any /usr/include/linux to remove.  What package normally 
makes this link, which I probably broke at one point trying to shrink 
glibc?  It was not made by glibc 2.2.5 or linuxinc when I reinstalled 
them.

> Now set up a new symlink:
>
> ln -s /usr/src/linux-2.2.16/include/linux /usr/include/linux

Could I instead of rm -rf and ln -s, just ln -sf?

> It should now stop complaining about limits.h. Hopefully, there
> will be no more error messages. If there are any, please post
> them here.

It did not complain at all, and 'make test' made a bunch of files ending 
in .h and one libz.a.  Make install installed libz.a to /usr/local/lib, and 
zlib.h and zconf.h (but not the others) to /usr/local/include.

It then looked like it did the following:
rm -f libz.so libz.so.1 (removed those symlinks)
ln -s libz.so.1.2.3  libz.so
ln -s libz.so.1.2.3 libz.so.1

But I don't have libz.so.1.2.3 even in this zlib-compiling directory.

I have a /usr/lib/libz.so.1.1.3 to which is symlinked libz.so.1 (it was 
not removed for some reason) and there is no libz.so.1.2.3 anywhere on my 
computer, including the directory where I just compiled libz.  I think the 
libz people are assuming you have a more recent linux that comes with this 
file, instead of providing it for you to compile.

BL2 libz.so.1.1.3 is 62776 bytes.
BL3 libz.so.1.1.3 is 61089 bytes.

It looks like you compiled statically except for libnetpbm, libc and libm.
libpng.a 232K, libjpeg.a 164k, libz.a 79K

I would rather provide a package with the .so libraries since they are 
also used by other programs (such as zgv and delilinux links2 with svgalib 
support, but the BL3 links2 is statically compiled; so is ghostscript, I 
think).

libz.so.1.2.3 ?60-70K   libz.a 79K
WHERE DO I FIND THIS?  I could compile statically with libz.a since
it is small, I guess.

libpng.so .. 232K       libpng12.a  232K
libpng12.so... 225K     libpng.a sylinked to libpng12.a
libjpeg.so 127K         libjpeg.a 164K

(These other .so libraries were generated when I compiled libpng and 
libjpeg - why was zlib.so not also produced, did I goof somewhere?).

I will also need libtiff.  I have libtiff.so.3.6.1 in /usr//locallib/ 
already and an 3.4 /usr/lib/ (should I be deleting these older versions of 
libraries when I add newer ones in /usr/local?).  I have version 3.8.0
source code and will try to compile libtiff.so.3.8.0.  Older versions of 
netpbm (and maybe of libtiff) can't handle multipage tiffs.

> > David, which compiler did you use for BL3 netpbm?
>
> gcc 2.95.3. It is the minimum recommended version for building
> Linux 2.4, MPlayer, and several other packages.
>
> If you eventually want to compile netpbm on BL3, remember that
> you need to use 'make -k' instead of 'make'. You will get tons
> of error messages, but some of the netpbm programs will still
> build.

I have the version you made for BL3 already, and have not run into any 
programs I want that are not in there.  Do you recall which ones would not 
compile?

> You need to do this because many of the netpbm programs will not
> compile with libc5. But some of them will, so 'make -k' will
> try to compile everything, instead of stopping when it
> encounters an error.
>
> If a program (that you can't live without) fails to compile, you
> can use uClibc or glibc and statically compile, or copy glibc
> from BL2, or try to edit the source code so that it will compile
> with libc5.

I have already installed SW81 glibc in BL3 so can use a glibc-based 
dynamically compiled package.  My static version of lynx would work 
offline with libc5 but not online.

> David

Let me know what to do about the zlib.so.1.2.3 file (where to look for it, 
or whether and how to just use zlib.a, which is 79K, or the older 
zlib.so.1.1.3) and I will install gcc 2.95.3 and try again to compile 
libtiff.

I think I got some of these libraries from SW71 and may have compiled the 
others a year ago for gs.

The .a libraries are incorporated in static versions, dynamic versions use 
.so, what are the .h files used for?  Do I need them in a dynamically 
compiled version?

Sindi