You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Barry Scott <ba...@barrys-emacs.org> on 2003/05/14 19:28:30 UTC

Re: Problems building on OpenBSD

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