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

sindi keesan keesan at sdf.lonestar.org
Wed Jan 4 20:47:27 EST 2006


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



More information about the BasLinux mailing list