Problems building en-openoffice.org-GB-3.1.1 from ports
Mike Clarke
jmc-freebsd2 at milibyte.co.uk
Sat Jan 2 23:49:53 UTC 2010
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
More information about the freebsd-questions
mailing list