Problems building en-openoffice.org-GB-3.1.1 from ports

[Mike Clarke]

On Saturday 02 January 2010, Matthew Seaman wrote:

> > /usr/local/lib/gcc/i386-portbld-freebsd6.4/3.4.6/libstdc++.so.6
>
> ^^^ Looks like something that was installed under FreeBSD 6.4.

But I installed 8.0 on an empty slice so there wouldn't have been any 
6.4 stuff still lying around.

> Dunno 
>     what in the up-to-date ports tree would need gcc-3.4 since the
> base system is now up to gcc-4.2, and that's quite capable of
> compiling OOo.

Yes gcc-3.4 pulled that in but I don't know how gcc-3.4 got there, 
nothing seems to depend on it.

curlew:/home/mike% pkg_info -Rr gcc-3.4.6_3,1
Information for gcc-3.4.6_3,1:

Depends on:
Dependency: libiconv-1.13.1

> > /usr/local/lib/compat/libstdc++.so.4
>
> ^^^ This is from the compat6x port

It's actually from compat5x which I need for nvidia-driver-96.43.13. For 
some obscure reason that I was never able to solve I could never get X 
to work with my GeForce 6150 chipset on FreeBSD 6.4 with any of the 
more recent Nvidia drivers so I assumed I'd still need to use this 
version. Perhaps it's time to see if the latest driver will work for me 
with 8.0 so that I can get rid of compat5x .

> > /usr/lib/libstdc++.so.6
>
> ^^^ the version from 8.0 base system
>
> libstdc++.so.5 would be part of a 7.x base system, but as you've gone
> to 8.0 by doing a clean install, nothing should be referencing that
> version.  What does 'ldd /usr/local/bin/gperf' tell you?

curlew:/home/mike% ldd /usr/local/bin/gperf
/usr/local/bin/gperf:
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x33ca0000)
        libm.so.4 => not found (0x0)
        libc.so.6 => not found (0x0)
        libm.so.5 => /lib/libm.so.5 (0x33d94000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x33dae000)
        libc.so.7 => /lib/libc.so.7 (0x33db9000)

The two not found lines look a bit worrying, perhaps I'd better rebuild 
gperf.

> At a guess you haven't followed the often repeated advice to
> reinstall /all/ your ports when you do a major version upgrade.  That
> means recompile from source in correct dependency order, or install
> pkgs compiled under 8.0.  Yes, it's tedious.  Yes, it consumes a lot
> of CPU cycles.  But now you understand why this is good advice...

It certainly looks like that but it's not the case here. Being aware of 
the time and disruption needed to rebuild everything I decided not to 
upgrade the existing 6.4 system but to build 8.0 from scratch on a 
spare slice. That way I could install the ports as and when time 
permitted and still be able to reboot back into a fully functional 
system when needed for "production" work.

I've just now run portupgrade -f gperf and things are looking a bit more 
promising. ldd /usr/local/bin/gperf now shows:

/usr/local/bin/gperf:
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x33ca2000)
        libm.so.5 => /lib/libm.so.5 (0x33d96000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x33db0000)
        libc.so.7 => /lib/libc.so.7 (0x33dbb000)

... and the build of OpenOffice ran through the configure stage without 
any problems so I'm keeping my fingers crossed that it'll still be 
compiling tomorrow.

Even if OpenOffice builds OK I think I've still got problems to solve. A 
trawl through /usr/local/bin shows that there's lots of program with 
links to missing libraries. I suspect I'm going to have to do 
portupgrade -af and rebuild all the ports.

-- 
Mike Clarke