After some investigation I think I see the problem. I have little
experience with dynamic linking under any UNIX, but I this looks odd:
kwalitee:/disk/0/subversion/run/lib> ldd libsvn_client-1.so.0.0
libsvn_client-1.so.0.0:
/disk/0/subversion/run/lib/libsvn_wc-1.so.0.0 (?)
/disk/0/subversion/run/lib/libsvn_ra-1.so.0.0 (?)
/disk/0/subversion/run/lib/libsvn_delta-1.so.0.0 (?)
/disk/0/subversion/run/lib/libsvn_subr-1.so.0.0 (?)
/disk/0/subversion/run/lib/libsvn_auth-1.so.0.0 (?)
/disk/0/subversion/run/lib/libaprutil-0.so.9.2 (?)
/usr/local/lib/libexpat.so.3.0 (?)
/disk/0/subversion/run/lib/libapr-0.so.9.2 (?)
-lm.0 => ? (?)
kwalitee:/disk/0/subversion/run/lib> ldd libsvn_subr-1.so.0.0
libsvn_subr-1.so.0.0:
-laprutil-0.9 => ? (?)
-lexpat.3 => ? (?)
-lapr-0.9 => ? (?)
-lm.0 => ? (?)
I am wondering if the names "-lapr-0.9" are really a command line option
taken to be a filename? If so, this is definately a configure problem.
Notice how for libsvn_client above the proper path for libpr is there.
However, for libsvn_subr, it looks like the linker command line got passed
as a filename!
Here is the libtool command used to compile shared objects:
/bin/sh /disk/0/subversion/build/work/subversion-0.20.1/libtool
--silent --mode=compile
gcc -D_POSIX_THREADS -g -O2 -pthread
-DNEON_ZLIB -DNEON_SSL
-I./subversion/include
-I.
-I/disk/0/subversion/build/work/subversion-0.20.1/neon/src
-I/disk/0/subversion/run/include/neon
-I/disk/0/subversion/run/include
-I/disk/0/subversion/run/include
-I/disk/0/subversion/run/include
-I/disk/0/subversion/run/include
-I/usr/local/include
-o subversion/libsvn_auth/auth.lo
-c subversion/libsvn_auth/auth.c
(I wonder why the SVN include path is included so often)
Here is the link step from my build of Subversion. Does anything look
blatantly wrong?
cd subversion/libsvn_subr && /bin/sh
/disk/0/subversion/build/work/subversion-0.20.1/libtool --silent
--mode=link gcc -g -O2 -pthread -DNEON_ZLIB -DNEON_SSL
-L/disk/0/subversion/run/lib -L/usr/local/lib
-rpath /disk/0/subversion/run/lib
-o libsvn_subr-1.la
cmdline.lo config.lo config_file.lo config_win.lo error.lo getdate.lo
hash.lo io.lo md5.lo opt.lo path.lo pool.lo quoprint.lo sorts.lo
stream.lo subst.lo svn_base64.lo svn_string.lo target.lo time.lo utf.lo
validate.lo xml.lo /disk/0/subversion/run/lib/libaprutil-0.la -ldb
-lexpat /disk/0/subversion/run/lib/libapr-0.la -lm -lresolv
*** Warning: linker path does not have real file for library -lresolv.
*** I have the capability to make that library automatically link in
*** when you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libresolv and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/lib/libresolv.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
I'm also not sure about that error message. OpenBSD does not seem to have
a shared version of the resolver:
# ls -l /usr/lib/libres*
-r--r--r-- 1 root bin 172 Oct 3 21:35 /usr/lib/libresolv.a
-r--r--r-- 1 root bin 280 Oct 3 21:35 /usr/lib/libresolv_p.a
Not quite sure how to handle that or what even uses the resolver library
(couldn't neon just statically link against libresolv?)
I can't see where the wrong filename "-lapr-0.9" is coming from. Could the
libtool that is provided with SVN and Apache (2.0.44) be broken?
I don't have a natvie libtool on the box -- would installing one help?
L8r,
Mark G.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 30 23:43:31 2003