[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: shared build problems

From: David Summers <david_at_summersoft.fay.ar.us>
Date: 2001-11-26 17:25:02 CET

I'm beginning to wonder if it has anything to do with either APXS or
LIBTOOL installing the modules.

I built a recent (494) version of subversion with RedHat 7.1. It worked
fine there. I copied the RPM over to RedHat 7.2 and it did *not* work
there, but when I switched to root on RedHat 7.2, it *did* work(!).

I then built the RPM on Redhat 7.2 and it *did* work.

I haven't tracked it down yet but maybe that will begin giving us clues so
we can squash this bug.

On this subject, I'm working on a script to just copy the
/usr/lib/apache/libmod_dav_svn.la and
/usr/lib/apache/libmod_dav_svn.so during installation instead of modifying
them somehow so that "rpm -V subversion-server" doesn't show up modified files.

   - David Summers

 On 26 Nov 2001, Yoshiki Hayashi wrote:

> Karl Fogel <kfogel@newton.ch.collab.net> writes:
>
> > This is long, but if you understand our configuration system and
> > libtool pretty well, please read the whole thing -- your expertise is
> > needed. :-)
>
> I don't think I'm of much help since all I can say is it
> works here, but I'll try anyway. :-)
>
> > floss$ su
> > floss# /usr/local/bin/cleanup.sh
> > [... this cleans libsvn_*, etc, out of /usr/local/lib ...]
> > floss# exit
> > floss$ cd top-of-my-subversion-working-copy
> > floss$ svn up
> > floss$ make distclean
> > floss$ ./autogen.sh
> > floss$ ./configure --enable-maintainer-mode \
> > --with-berkeley-db=/usr/local/BerkeleyDB.3.3
> > floss$ make
>
> I followed the same course to build svn and it still works
> for me. I checked out fresh copy of Subversion tree and
> manually applied --enable-dso patch.
>
> > Only ra_dav libraries were installed; no ra, no ra_local. Where are
> > they? Let's ask the working copy:
> >
> > floss$ ls -l subversion/libsvn_ra/.libs
> > [... output abbreviated for readability ...]
> > total 88
> > -rw-r--r-- 38596 libsvn_ra.a
> > lrwxrwxrwx 15 libsvn_ra.la -> ../libsvn_ra.la
> > -rw-r--r-- 1012 libsvn_ra.lai
> > lrwxrwxrwx 18 libsvn_ra.so -> libsvn_ra.so.0.0.0
> > lrwxrwxrwx 18 libsvn_ra.so.0 -> libsvn_ra.so.0.0.0
> > -rwxr-xr-x 43424 libsvn_ra.so.0.0.0U*
> > floss$ ls -l subversion/libsvn_ra_local/.libs
> > [... output abbreviated for readability ...]
> > total 268
> > -rw-r--r-- 173500 libsvn_ra_local.a
> > lrwxrwxrwx 21 libsvn_ra_local.la -> ../libsvn_ra_local.la
> > -rw-r--r-- 941 libsvn_ra_local.lai
> > lrwxrwxrwx 24 libsvn_ra_local.so -> libsvn_ra_local.so.0.0.0
> > lrwxrwxrwx 24 libsvn_ra_local.so.0 -> libsvn_ra_local.so.0.0.0
> > -rwxr-xr-x 85957 libsvn_ra_local.so.0.0.0U*
> >
> > Well, those symbolic links look messed up -- they're pointing to
> > .so.0.0.0 files that don't exist. There are those files with "U"
> > appended to their names; not sure what that's about. Maybe this is
> > all proper libtool behavior, and I just am not sufficiently familiar
> > with it to know?
>
> I get this:
>
> [penny@u svn]$ ls -l subversion/libsvn_ra/.libs/
> total 95
> -rw-rw-r-- 44532 Nov 26 16:53 libsvn_ra.a
> lrwxrwxrwx 15 Nov 26 16:53 libsvn_ra.la -> ../libsvn_ra.la
> -rw-rw-r-- 1022 Nov 26 16:53 libsvn_ra.lai
> lrwxrwxrwx 18 Nov 26 16:53 libsvn_ra.so -> libsvn_ra.so.0.0.0
> lrwxrwxrwx 18 Nov 26 16:53 libsvn_ra.so.0 -> libsvn_ra.so.0.0.0
> -rwxrwxr-x 48752 Nov 26 16:53 libsvn_ra.so.0.0.0
>
> > --------------------------------------------------------------------------
> > For plain ra:
> > --------------------------------------------------------------------------
> >
> > cd subversion/libsvn_ra ; /bin/sh /home/kfogel/src/subversion/libtool --mode=install /home/kfogel/src/subversion/ac-helpers/install-sh -c libsvn_ra.la /usr/local/lib/libsvn_ra.la
> > libtool: install: warning: relinking `libsvn_ra.la'
> > cd /home/kfogel/src/subversion/subversion/libsvn_ra; /bin/sh /home/kfogel/src/subversion/libtool --mode=relink gcc -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -g -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread -DNEON_ZLIB -Wpointer-arith -Wwrite-strings -Wshadow -DSVN_DEBUG -DAP_DEBUG -I./subversion/include -I. -I/home/kfogel/src/subversion/apr/include -I/include -I/home/kfogel/src/subversion/neon/src -I./expat-lite -I/usr/local/BerkeleyDB.3.3/include -rpath /usr/local/lib -o libsvn_ra.la ra_loader.lo /home/kfogel/src/subversion/subversion/libsvn_ra_dav/libsvn_ra_dav.la /home/kfogel/src/subversion/neon/src/libneon.la -L/usr/local/lib -lz /home/kfogel/src/subversion/subversion/libsvn_ra_local/libsvn_ra_local.la /home/kfogel/src/subversion/subversion/libsvn_repos/libsvn_repos.la /home/kfogel/src/subversion/subversion/libsvn_fs/libsvn_fs.la -L/usr/local/BerkeleyDB.3.3/lib -ldb -lm -lcrypt -lnsl -ldl
> > gcc -shared ra_loader.lo -Wl,--rpath -Wl,/usr/local/lib -L/home/kfogel/src/subversion/subversion/libsvn_subr/.libs -L/home/kfogel/src/subversion/subversion/libsvn_delta/.libs -L/usr/local/BerkeleyDB.3.3/lib -L/home/kfogel/src/subversion/subversion/libsvn_fs/.libs -L/home/kfogel/src/subversion/subversion/libsvn_repos/.libs -L/home/kfogel/src/subversion/neon/src/.libs -L/usr/local/lib -lsvn_ra_dav -lneon -lz -lsvn_ra_local -lsvn_repos -lsvn_fs -ldb -lm -lcrypt -lnsl -ldl -Wl,-soname -Wl,libsvn_ra.so.0 -o .libs/libsvn_ra.so.0.0.0
> > /usr/bin/ld: cannot find -lsvn_ra_dav
> > collect2: ld returned 1 exit status
> > libtool: install: error: relink `libsvn_ra.la' with the above command before installing it
>
> It looks like libtool is not working correctly. I don't
> have 'U' appended to library name and have no link error. I
> think 'U' is the cause of the problem but I don't know why
> it occurs and I don't know how to fix it. :-(
>
> cd subversion/libsvn_ra ; /bin/sh /home/penny/work/tmp/svn/libtool --mode=install /home/penny/work/tmp/svn/ac-helpers/install-sh -c libsvn_ra.la /usr/local/lib/libsvn_ra.la
> libtool: install: warning: relinking `libsvn_ra.la'
> cd /home/penny/work/tmp/svn/subversion/libsvn_ra; /bin/sh /home/penny/work/tmp/svn/libtool --mode=relink gcc -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -g -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread -DNEON_ZLIB -Wpointer-arith -Wwrite-strings -Wshadow -DSVN_DEBUG -DAP_DEBUG -I./subversion/include -I. -I/include -I/home/penny/work/tmp/svn/neon/src -I./expat-lite -I/usr/local/BerkeleyDB.3.3/include -rpath /usr/local/lib -o libsvn_ra.la ra_loader.lo /home/penny/work/tmp/svn/subversion/libsvn_ra_dav/libsvn_ra_dav.la /home/penny/work/tmp/svn/neon/src/libneon.la -L/usr/local/lib -lz /home/penny/work/tmp/svn/subversion/libsvn_ra_local/libsvn_ra_local.la /home/penny/work/tmp/svn/subversion/libsvn_repos/libsvn_repos.la /home/penny/work/tmp/svn/subversion/libsvn_fs/libsvn_fs.la -L/usr/local/BerkeleyDB.3.3/lib -ldb -lm -lcrypt -lnsl -ldl
> gcc -shared ra_loader.lo -Wl,--rpath -Wl,/usr/local/lib -L/home/penny/work/tmp/svn/subversion/libsvn_subr/.libs -L/home/penny/work/tmp/svn/subversion/libsvn_delta/.libs -L/usr/local/BerkeleyDB.3.3/lib -L/home/penny/work/tmp/svn/subversion/libsvn_fs/.libs -L/home/penny/work/tmp/svn/subversion/libsvn_repos/.libs -L/home/penny/work/tmp/svn/neon/src/.libs -L/usr/local/lib -lsvn_ra_dav -lneon -lz -lsvn_ra_local -lsvn_repos -lsvn_fs -ldb -lm -lcrypt -lnsl -ldl -Wl,-soname -Wl,libsvn_ra.so.0 -o .libs/libsvn_ra.so.0.0.0
> /home/penny/work/tmp/svn/ac-helpers/install-sh -c .libs/libsvn_ra.so.0.0.0T /usr/local/lib/libsvn_ra.so.0.0.0
> (cd /usr/local/lib && rm -f libsvn_ra.so.0 && ln -s libsvn_ra.so.0.0.0 libsvn_ra.so.0)
> (cd /usr/local/lib && rm -f libsvn_ra.so && ln -s libsvn_ra.so.0.0.0 libsvn_ra.so)
> /home/penny/work/tmp/svn/ac-helpers/install-sh -c .libs/libsvn_ra.lai /usr/local/lib/libsvn_ra.la
> /home/penny/work/tmp/svn/ac-helpers/install-sh -c .libs/libsvn_ra.a /usr/local/lib/libsvn_ra.a
> ranlib /usr/local/lib/libsvn_ra.a
> chmod 644 /usr/local/lib/libsvn_ra.a
>
> > Okay, now we get ra_dav, but still no ra_local. We've seen this
> > phenomenon before, where ra_local doesn't get included in a shared
> > build, but I can't remember the cause. Does anyone recall?
>
> The only cause I remember is that the BerkelyDB library is
> not on your LD_LIBRARY_PATH or /etc/ld.so.conf but it's not
> likely in your environment.
>
> > floss$ libtool --version
> > ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52)
> > floss$ autoconf --version
> > autoconf (GNU Autoconf) 2.52
> > [...]
> > floss$
>
> Hmm. I'm using exactly the same tool (Debian unstable,
> right?). Weird.
>
> [penny@u svn]$ libtool --version
> ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52)
> [penny@u svn]$ autoconf --version
> autoconf (GNU Autoconf) 2.52
> [...]
>
>

-- 
David Wayne Summers          "Linux: Because reboots are for upgrades!"
david_at_summersoft.fay.ar.us   PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint =  C0 E0 4F 50 DD A9 B6 2B  60 A1 31 7E D2 28 6D A8 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:49 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.