Subject: Re: could not determine version of /usr/lib/libpthread.so
To: None <tech-pkg@netbsd.org>
From: Jeremy C. Reed <reed@reedmedia.net>
List: tech-pkg
Date: 09/26/2003 19:12:42
How can I make the mk/buildlink2/fake-la magic force use of a shared
library (instead of static)?
(I carbon-copied this to the originator of PR #22052.)
Please see below ...
On Thu, 25 Sep 2003, Jeremy C. Reed wrote:
> pkgsrc/mk/buildlink2/fake-la made
> /tmp/pkgsrc/x11/qt3-libs/work.puget/.buildlink/lib/libpthread.la
> which contained just:
>
> could not determine version of /usr/lib/libpthread.so
I see that PR #22052 has a fix for this. Can someone look at PR #22052?
Nevertheless, using the patch from that PR while building openldap, I am
still getting the following. (And I have more comments and
troubleshooting below.)
> cc -O2 -I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include
> -Wl,-R/usr/lib -o dtest dtest.o
> -L/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib
> ./.libs/liblber.a ../../libraries/liblutil/liblutil.a -lresolv -ldl
> /usr/lib/libdb2.a /usr/lib/libpthread.a -lrt
> ./.libs/liblber.a(sockbuf.o)(.text+0xf8b): In function `sb_debug_read':
> : `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead
> ./.libs/liblber.a(sockbuf.o)(.text+0xf82): In function `sb_debug_read':
> : `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead
> /tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib/libpthread.a(ptw-write.o)(.text+0x25):
> In function `write':
> : undefined reference to `__syscall_error'
> /tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib/libpthread.a(ptw-write.o)(.text+0x55):
> In function `write':
> : undefined reference to `__syscall_error'
> ....
> (.text+0xaad): In function `__pthread_reset_main_thread':
> : undefined reference to `_h_errno'
> /tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib/libpthread.a(pthread.o)(.text+0xab8):
> In function `__pthread_reset_main_thread':
> : undefined reference to `_res'
> ....
> /tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib/libpthread.a(ptw-open.o)(.text+0x55):
> In function `open':
> : undefined reference to `__syscall_error'
> collect2: ld returned 1 exit status
Also, I built openldap using same configure scripts and CPPFLAGS without
pkgsrc, it builds successfully -- with my /usr/lib/libpthread.so moved out
of the way and a symlink instead.
And with the original /usr/lib/libpthread.so file back in place. (This is
the file with the OUTPUT_FORMAT and GROUP lines as shown in PR and my
previous posting.) I did a new ./configure and then built openldap. It
successfully built with libpthread.so.0 listed as a shared object. (Again
this is without pkgsrc.)
The error (that happened with pkgsrc):
/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib/libpthread.a(ptw-write.
o)(.text+0x25): In function `__libc_write':
__libc_write: undefined reference to `__syscall_error'
never happened (when building witout pkgsrc).
So I compare the pkgsrc with my non-pkgsrc build ...
My source build did:
cc -g -O2 -I../../include -I../../include -I/usr/include/db4/
-I/usr/include/db2/ -c dtest.c
/bin/sh /home/reed/openldap/openldap-2.1.22/libtool --mode=link cc -static
-g -O2 -o dtest dtest.o liblber.la ../../libraries/liblutil/liblutil.a
-lresolv -ldl
cc -g -O2 -o dtest dtest.o ./.libs/liblber.a
../../libraries/liblutil/liblutil.a -lresolv -ldl
My pkgsrc/databases/openldap/work.puget/.work.log has:
==> Fixed liblber.la
==> Fixed ./.libs/liblber.lai
/usr/bin/cc -O2
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include -
I../../include -I../../include
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include/db4
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include /db2
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include/db2
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include/db4
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include/db2
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include/db2
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include -c dtest.c
/usr/bin/libtool --mode=link cc -static -O2
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include
-L/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib -Wl,-R/usr/lib
-o dtest dtest.o liblber.la ../../libraries/liblutil/liblutil.a -lresolv
-ldl -ldb2 -lpthread -lrt
/usr/bin/cc -O2
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include
-Wl,-R/usr/lib -o dtest dtest.o
-L/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib
./.libs/liblber.a ../../libraries/liblutil/liblutil.a -lresolv -ldl
/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib/libdb2.a
/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib/libpthread.a -lrt
/usr/bin/libtool --mode=link cc -static -O2
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include
-L/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib -Wl,-R/usr/lib
-o dtest dtest.o liblber.la ../../libraries/liblutil/liblutil.a -lresolv
-ldl -ldb2 -lpthread -lrt
/usr/bin/cc -O2
-I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include
-Wl,-R/usr/lib -o dtest dtest.o
-L/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib
./.libs/liblber.a ../../libraries/liblutil/liblutil.a -lresolv -ldl
/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib/libdb2.a
/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib/libpthread.a -lrt
I don't know why the .work.log had this repeated. I also captured the
pkgsrc output:
/bin/sh /tmp/pkgsrc/databases/openldap/work.puget/openldap-2.1.22/libtool
--mode=link cc -static -O2 -I/usr/include -L/usr/lib -Wl,-R/usr/lib -o
dtest dtest.o liblber.la ../../libraries/liblutil/liblutil.a -lresolv
-ldl -ldb2 -lpthread -lrt
cc -O2 -I/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/include
-Wl,-R/usr/lib -o dtest dtest.o
-L/tmp/pkgsrc/databases/openldap/work.puget/.buildlink/lib
./.libs/liblber.a ../../libraries/liblutil/liblutil.a -lresolv -ldl
/usr/lib/libdb2.a /usr/lib/libpthread.a -lrt
The problem appears to be that it is forcing it to link to
/usr/lib/libpthread.a. My other good dtest doesn't appear to be built with
it. How can I tell? (Maybe some switch with objdump??)
Note that my previous email and PR #22052 say:
Use the shared library, but some functions are only in the
static library, so try that secondarily.
So my errors are probably referring to those "some functions" that are
missing.
How can I make it use the shared library?
Thank you for listening ...
Jeremy C. Reed
http://bsd.reedmedia.net/