Until OpenBSD uses ELF the ldd output will be a bit (!) wierd. The -lxxx
output is normal.
What happends if you just leave off the -lresolv ? Does it all work?
Barry
At 30-03-2003 16:42, Mark G wrote:
>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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 14 21:29:48 2003