Hey gstein -- :)
I've got a consistent link error when building
`libsvn_ra_dav/tests/ra-dav-test':
------
gmake[4]: Entering directory `/usr/home/sussman/projects/subversion/subversion/libsvn_ra_dav/tests'
/bin/sh ../../../libtool --silent --mode=link gcc -pthread -o
ra-dav-test ra-dav-test.o ../libsvn_ra_dav.la
../../libsvn_wc/libsvn_wc.la ../../libsvn_delta/libsvn_delta.la
../../libsvn_subr/libsvn_subr.la ../../libsvn_string/libsvn_string.la
../../../neon/libneon.la ../../../apr/libapr.a /usr/libexec/elf/ld:
cannot open -lexpat: No such file or directory
------
Looking at the Makefile.am for this executable, I noticed that
../../../expat-lite/libexpat.la is a dependency. *However*, I don't
think this is a problem, since other test binaries depend on this
library and link with no problem.
Instead, I think the key problem here is that ra-dav-test is the first
binary to depend on libneon.la. I notice that when I compile neon,
the final link libtool link-line ends with "-L../expat-lite -lexpat".
AFAIK, this is the only time a "direct" library dependency has been
specified anywhere in our tree. Up till now, everything has Just
Worked through some fuzzy magic of libtool gluing libraries together.
I suspect the solution to this problem is a matter of making neon also
use libtool to describe its dependency on libexpat.la, rather than
"-lexpat". I'm not sure if this an issue for Joe Orton, or some
integration issue.
In any case, libsvn_ra_dav is the penultimate directory that builds
when running `make' from the top of the tree, so this problem isn't
critical. It's not blocking any work on delta or wc stuff. :)
BTW, I'm using neon-0.7.3. This happens on both FreeBSD and Linux
with neon-0.7.3, but *NOT* with neon-0.7.2 !
Received on Sat Oct 21 14:36:08 2006