Recent install problems.

[Oleg Sharoiko]

Hello!

I've also faced installation problem, mentioned recently on this list. As far 
as I can understand it's not yet solved. In this case my information can 
provide some help. The problem arises because lzip coredumps during the build 
process. I suppose it coredumps because it appears to be built against two 
different threading libs:

wolf, /usr/ports/editors/openoffice-1.1 # env LD_LIBRARY_PATH=/usr/ports/editors/openoffice-1.1/work/OOo_1.1.3_src/solver/645/unxfbsd.pro/lib ldd work/OOo_1.1.3_src/scptools/unxfbsd.pro/bin/lzip | grep pth
         libpthread.so.1 => /usr/lib/libpthread.so.1 (0x29fa2000)
wolf, /usr/ports/editors/openoffice-1.1 # env LD_LIBRARY_PATH=/usr/ports/editors/openoffice-1.1/work/OOo_1.1.3_src/solver/645/unxfbsd.pro/lib ldd work/OOo_1.1.3_src/scptools/unxfbsd.pro/bin/lzip | grep c_r
         libc_r.so.5 => /usr/lib/libc_r.so.5 (0x2891e000)

Putting

libpthread.so libc_r.so
libpthread.so.1 libc_r.so.5

into /etc/libmap.conf (as a quick workaround) solved the problem. I had to 
remobe work/.build_done* and ran make once again.

Installed openoffice binary is also linked against both libc_r and libpthread. 
I couldn't start it without pthread->c_r or c_r->pthread mapping (the second 
one also works for me). Don't know if it matters, but libs in 
/usr/local/OpenOffice.org1.1.3/program/ refer to libpthread only, libc_r seems 
to be a direct dependecy of soffice.bin and lzip binaries. In my 
work/OOo_1.1.3_src/FreeBSDEnv.Set I have setenv PTHREAD_LIBS "-pthread" I'll 
now try rebuilding openoffice with setenv PTHREAD_LIBS "-lpthread" I'm not 
sure wether it will help or not, and I also do not know what should be the 
correct vaule of PTHREAD_LIBS.

Some additional information: my system compiler and gcc32 use different 
threading libs for -pthread switch. I think this is the real source of the 
problem.

wolf, ~/src/test > gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728
wolf, ~/src/test > gcc -Wall -pedantic -pthread test_pth.c -o test_pth
wolf, ~/src/test > ldd test_pth
test_pth:
         libpthread.so.1 => /usr/lib/libpthread.so.1 (0x28081000)
         libc.so.5 => /lib/libc.so.5 (0x280a7000)

wolf, ~/src/test > gcc32 -v
Reading specs from /usr/local/lib/gcc-lib/i386-portbld-freebsd5.3/3.2.3/specs
Configured with: ./..//gcc-3.2.3/configure --disable-nls 
--with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd5.3/3.2.3/include/g++-v3 
--with-system-zlib 
--includedir=/usr/local/lib/gcc-lib/i386-portbld-freebsd5.3/3.2.3/include/Java 
--disable-shared --prefix=/usr/local i386-portbld-freebsd5.3
Thread model: posix
gcc version 3.2.3
wolf, ~/src/test > gcc32 -Wall -pedantic -pthread test_pth.c -o test_pth
wolf, ~/src/test > ldd test_pth
test_pth:
         libc_r.so.5 => /usr/lib/libc_r.so.5 (0x28081000)
         libc.so.5 => /lib/libc.so.5 (0x280a5000)

This doesn't happen on my another freebsd box, where gcc and gcc32 use same 
libs. I'll try to find why one of gcc32 uses libc_r.

p.s. I'm not on the list, so if you want to reply me keep my e-mail on To: or 
Cc: line.

-- 
Oleg Sharoiko.
Software and Network Engineer
Computer Center of Rostov State University.