Some testing results from current build
Charles P. Schaum
verbo.solo at sbcglobal.net
Sun Aug 27 17:37:44 UTC 2006
Hi,
I have tested with some success the measures NAKATA, Maho used.
My approach was slightly modified.
First I updated the ports tree.
Then, after replacing NetBSD on my spare box with FreeBSD 6.1-RELEASE
(turn off ACPI on old board) I compared the two:
6.1-RELEASE /usr/lib
libc_r.a
libc_r.so (symlink)
libc_r.so.6 (symlink target)
libc_r_p.a
6-STABLE
libc_r.a
libc_r.so (symlink)
libc_r.so.6 (symlink target)
libc_r_p.a
Same names, so symbols are the issue. The fact that the names are the
same means that across multiple versions one can rename them to
something bogus, e.g.:
libc_r.a.deleted
libc_r.so.deleted (symlink)
libc_r.so.6 (symlink target)
libc_r_p.a.deleted
Note that renaming the symlink target cannot be done; it will only make
a copy. This is no big deal because the build will succeed with just the
three files thus renamed.
This means that a pre-build step of (forgive my bash scripting):
#Toggle libc_r - brute force style
cut-----
if [ -e /usr/lib/libc_r.a ]; then
mv /usr/lib/libc_r.a libc_r.a.OOdeleted
fi
if [ -e /usr/lib/libc_r.so ]; then
mv /usr/lib/libc_r.so libc_r.so.OOdeleted
fi
if [ -e /usr/lib/libc_r_p.a ]; then
mv /usr/lib/libc_r_p.a /usr/lib/libc_r_p.a.OOdeleted
fi
cut-----
and a post-build step of:
cut-----
if [ -e /usr/lib/libc_r.a.OOdeleted ]; then
mv /usr/lib/libc_r.a libc_r.a
fi
if [ -e /usr/lib/libc_r.so.OOdeleted ]; then
mv /usr/lib/libc_r.so libc_r.so
fi
if [ -e /usr/lib/libc_r_p.a.OOdeleted ]; then
mv /usr/lib/libc_r_p.a /usr/lib/libc_r_p.a
fi
cut-----
Such a step will leave the system intact, allow OOo to build and
mitigate any possible need to rebiuld world. Otherwise should the libc_r
thing get on the STABLE list?
Charles
More information about the freebsd-openoffice
mailing list