Re: subversion 1.2.0 "make check" does not operate correctly under certain circumstances

I agree that that is what is apprently happending. When I detrimined that the "make check" was loading the wrong libraries I put in a bug report (2313) but it was closed because I did not discuss it here on the dev list. There is a long chain on the user list.

   "make check" needs to insure it is loading the correct libraries and insure it is loading libraries from the build tree it is being run from. As most folks are going to install in /usr/local and not as I did in /usr/local/subversion-1.2.0., when the tests fail most people will not install the newer version. I in fact did not install 1.2.0rc4 because it would not pass the tests. When 1.2.0 failed the tests as well I almost opted to not install it either but decided to see if I could figure out why it was not passing the tests.

   This is a bug, a minor one, but has the potential to cause people from upgrading since the self tests fail. My initial thought was the rc4 version was buggy and not ready to be released.

    Don

Philip Martin wrote:
> Donald R Laster Jr <laster@dlaster.com> writes:
>
>
>>The 1.2.0 "make check" used the wrong libraries if another version is
>>installed in a location such as /usr/local. I originally installed
>>subversion 1.1.4 in /usr/local. When 1.2.0 was released I
>>"reinstalled" 1.1.4 into /usr/ local/subversion-1.1.4 but forgot to
>>remove the libraries from /usr/ local/lib. When I ran the "make
>>check" in the 1.2.0 directories the "make check" appears to have used
>>the 1.1.4 libraries that were sitting in /usr/local/lib. Whem I
>>reinstalled subversion 1.1.4 in /usr/local/subversion-1.1.4 and
>>subversion 1.2.0 in /usr/local/subversion-1.2.0 and insure no
>>subversion lbiraries were left in /usr/local/lib both sets of "make
>>check" ran correctly.
>
>
> I think this is because you configured subversion using --enable-dso.
>
> You can verify that the build is using libraries from within the build
> tree by running:
>
> $ ldd subversion/clients/cmdline/.libs/lt-svn | grep libsvn
>
> This should show the libraries being picked up from the build area.
>
> I think official libtool way to run the command would be:
> $ ./libtool --mode=execute ldd subversion/clients/cmdline/svn
> but using .libs/lt-svn directly works for me.
>
> Since you used --enable-dso additional libraries get loaded at
> runtime, to see what gets loaded use:
>
> $ strace -etrace=open subversion/clients/cmdline/.libs/lt-svn 2>&1 | grep libsvn_ra-1
>
> I expect this will show libraries being loaded from outside the build
> area. The exact set of paths searched for --enable-dso libraries
> depends on how your system is configured. It may be possible to use
> LD_LIBRARY_PATH to change this, try adding:
>
> /path/to/build/dir/subversion/libsvn_ra_local/.libs
>
> to LD_LIBRARY_PATH and repeat the strace command to see if it works.
> You will probably need to add libsvn_fs_fs as well, and possibly
> libsvn_ra_dav, libsvn_ra_svn and libsvn_fs_base, to get the regression
> tests to pass.
>
> Using LD_LIBRARY_PATH didn't work on --enable-dso libraries the last
> time I tried it on my machine, which means there is no way to make
> --enable-dso regression tests work without first installing
> Subversion.
>

-- 
===========================================================================
Donald R. Laster Jr. 
Senior Consulting Engineer
DOT4 Inc.
25 Heidl Ave                                              
West Long Branch, NJ 07764      
Email : laster@dlaster.com
        dlaster@dot4.com
IM:     drljrus (AIM/Yahoo)
Phones: (732) 263-9235 (Evening)
        (732) 263-9236 (Office)
        (732) 539-5658 (Cell)
        (732) 263-9280 (Fax)
===========================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org