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