Philip Martin wrote on 3/28/2006 7:02 PM:
> Sviatoslav Sviridov <firstname.lastname@example.org> writes:
>> I've got the same errors with 1.3.1 that I've reported once for 1.3.0:
> To avoid others having to look it up: those are reports of the
> regression tests failing.
>> But now I've identified that this problem is caused by "--enable dso"
>> option for configure script. I'm using "--enable dso" since
>> subversion-1.2.0, and it was 1.3.0 when I faced with problems for the
>> first time.
>> So, I know the workaround for this now, but if this option is still
>> supported, it should be fixed, I think.
> When using --enable-dso the modules get loaded from the install dir
> rather than the build dir, and the regression tests are likely to fail
> if the installed modules are incompatible with the new build. The
> regression tests should work if run after installation, but that's
> not always practical.
In my case build is preformed in a clean chrooted environment created
from scratch. There are only packages required for building subversion
installed. That means no modules from previous versions available.
(Though you are correct, some time in the past I also noted that
installed modules were used.)
I also use other trick to make all libraries available for dlopen():
LDLP=`find subversion -type d -name .libs|while read dir; do echo
"$PWD/$dir"; done|xargs echo|tr ' ' ':'`
and all tests are called like:
LD_LIBRARY_PATH="$LDLP" make FS_TYPE=fsfs check
Are there other directories that should be added to LD_LIBRARY_PATH?
So with '--enable dso':
- all checks for FS_TYPE=fsfs passed
- checks for FS_TYPE=bdb passed except one: repos_test failed
- perl bindings tests passed except '6ra'
- all ruby tests passed
- javahl tests failed
Received on Tue Mar 28 18:32:26 2006