Skip to Content.
Sympa Menu

baslinux - Re: [BL] /lib/cpp error compiling in BL2 with libc-2.2.5 upgrade

baslinux AT lists.ibiblio.org

Subject: Baslinux mailing list

List archive

Chronological Thread  
  • From: sindi keesan <keesan AT sdf.lonestar.org>
  • To: baslinux AT lists.ibiblio.org
  • Subject: Re: [BL] /lib/cpp error compiling in BL2 with libc-2.2.5 upgrade
  • Date: Thu, 5 Jan 2006 01:47:27 +0000 (UTC)

On Wed, 4 Jan 2006, David Moberg wrote:
Just execute:
ln -sf /usr/bin/cpp /lib/cpp

What normally makes this link?

Usually, the doinst.sh script that comes with the package.
egcs? I did not reinstall that, just glibc and linuxinc.

Many packages containing cpp will not make this link for you.

I probably broke the link myself since I had it on another computer.

You should be able to compile it. Maybe there is a configuration file that
you can edit to build the shared library?

I will try to find one. The shared libraries were built by default for
libjpeg and libpng. I think for zlib there was a 'configure' (Not at
that computer now).

Try ./configure --help. Look for an option such as 'enable-shared'.
Or look through zlib's README or INSTALL files.

I read the Makefile and it said to ./configure -s to make the shared library and that worked perfectly, as did make install.

I now have never versions in /usr/local/lib of
libjpeg, libpng libpng12 libtiff and libz (and also an mplayer directory with a vidix subdirectory that I don't know what to do with yet).

I have libtiff.so.3.6.1 from April 26, 2005 (not yet 3.8.0, which I need to compile). I wonder where it came from.

May I delete older versions in /usr/lib?


To switch compilers do I need gcc-2.95.3 and gcc-g++-2.95.3? Anything
else from SW81?

I don't think so. You do not need gcc-g++-2.95.3 unless you plan to
compile C++ programs.

After running ./configure, the libtiff Makefile refers to g++ (CXX=g++).
HAVE_CXX_FALSE = #
HAVE_CXX_TRUE =

Does this mean I do or do not have g++?
It also referrs to autoconfi and autorun and other things which I presume
it determined the presence of when I ran configure such as i586.

I then tried to compile libtiff and ./configure passed cpp and everything else. But then make ran for a little while and gave me a lot of warnings and parse errors and things in tiff_dirread.c, and then exited with:
make[2]: *** [tif_dirread.lo] Error 1

and it left /src/tiff/libtiff.

This directory has a lot of triplets of files in it, up through tif_direinfo.c .lo and .o, in alphabetical order, but only tif_dirread.o and .loT (it exited before making an .lo and then an .o which is use to make the .so and .a?) so it seems to have gotten stuck on making tif_dirread.lo. The .loT file has only a few lines in #.

What do I do next, try the SW91 compiler? Compile without this one file?

Is there any reason for anyone to install the SW71 compiler (egcs) instead of gcc-2.95.3 or .4 or .5, other than having it on the CD?


What do you mean by development libraries?

Look in slakware/d1 or slackware/d. Those are development library
packages. Instead of compiling everything from source, you can use
these. For example, get jpeg6.tgz to build something that needs
libjpeg.

MANIFEST.gz lists libjpeg.a (same size as what I compiled) and libjpeg.so.62.0.0, which I have in /usr/lib already (probably installed so that links2 and zgv would work). Apparently version 6b, which I downloaded and compiled, though it is from 27-Mar-1998, is the latest stable version and there was no need to download the source code and compile it.

For some reason I was unable to compile the libjpeg.so anyway.
There is nothing about 'shared' in the Makefile.
'make install-libs' installs only libjpeg.a and a few .h files.
Why might the .so file not have been compiled?

I had libpng.so.3.1.2.5 and just compiled 3.1.2.8 I have libtiff.so.3.6.1 and want 3.8.0 from Nov 3 2005.
(I may have compiled these while compiling ghostscript last April).

I am not compiling for stock BL2 but for upgraded to glibc 2.2.5, which is
what I needed for Opera or precompiled xpdf or precompiled curl and
openssl.

OK. So you might want to use SW81 development libraries for tiff, png,
etc. unless you want this netpbm binary package to work with SW71
libs.

I would like it to work with SW71 that has glibc.2.2.5 upgrade.

Do I need the latest libtiff for multipage tiffs? I read the changlog for 3.7.4 > 3.8.0 and they don't mention that, but they fixed a few bugs.

Even if an older libtiff will work, I should fix whatever is wrong with my setup to make compiling work on other things later.

Please advise how to compile libtiff.
------------------
I am trying now to compile netpbm with the older libtiff 3.6.1

Netpbm configure 'cannot find the link library for SVGALIB'. I have installed the svgalib package and have /usr/lib/svgalib so I typed that in as the location.
-----------------------
'make' cannot find asm/errno.h

I fixed this with:

ln -s /usr/src/linux-2.2.16/include/asm /usr/include/asm

Should I have simply linked:
ln -s /usr/src/linux-2.2.16/include /usr/include

I vaguely recall breaking this link a year or two ago and fixing it on the computer I was compiling on (where the hard drive died) but I thought reinstalling linuxinc should have fixed it here.
---------------------------------------------------------------
---------------------------------------------------------------
Now it exited with a different error regarding [ilbmtoppm.o]

/tmp/ccGeilCG.s: Assembler messages:
/tmp/ccGeilCG.s:2533: no such 386 instruction: 'filds'
(ditto) 2540 (ditto).

I found 80 hits for 'no such 386 instruction: 'filds'.

Various people got similar error messages related to Assembler and


/tmp/cc??????.s:????: Error: no such 386 instruction: 'filds'

Someone's suggested explanation and solution:
'C compiler churned out the assembler code for the architecture that Assembler can't digest. Try to use -mcpu=i686 -march=i586'
(This did not work for someone compiling LFS).

Someone else had trouble compiling gimp on a K6 II 350 but their friend compiled it okay on a PII.

Another person, using gcc-2.95.1 and binutils (for Assembler), compiled perfectly on a PII, but on a PI 'it seems like nothing will compile anymore'. The suggested solution, putting DEFAULT_ASSEMBLER=/usr/bin/as (as is the assembler) before configure statements, did not help them. (Redhat 6.0).

Someone else's solution was to use different RPM source code.

I can test this on the PII, but most of my computers are PI (AMD K6 II).

Same problem with Redhat 6.1 and egcs 2.91.66. Compiler/assembler mismatch was a suggested diagnosis.

David, which 'as' did you use?
SW7.1 has 'as' 2.9.1.0.25 and SW8.1 has 2.12.9.0.9

SW71 'as' is only 168K - can I just upgrade that one file and add the
(unsymlinked) dependency libbfd-*.so? How do I extract a file with tar?

SW71 contribs has binutils 2.9.5.0.42, 1.2MB
SW81 binutils is 2.3MB, compressed and I have the CD.

Sindi




Archive powered by MHonArc 2.6.24.

Top of Page