+ LDFLAGS='-L/usr/lib -L/lib'
Why?
Because all of the 32-bit libs are in /lib and /usr/lib. The native
64-bit libs are in /lib64 and /usr/lib64 (which is the system default).
The system is fully multilib, i686 and x86_64 on a running 64-bit system.
If you rerun the libtool command with --sile
On Thu, Nov 24, 2011 at 4:00 PM, Daniel Shahaf wrote:
> While reviewing r1205726 I came across this pearl:
>
> reps-strings.c- /* Make a list of all the rep's we need to
> undeltify this range.
> reps-strings.c- We'll have to read them within this trail
> anyway, so we might
cmpil...@apache.org wrote on Thu, Nov 24, 2011 at 05:45:25 -:
> Author: cmpilato
> Date: Thu Nov 24 05:45:24 2011
> New Revision: 1205726
>
> URL: http://svn.apache.org/viewvc?rev=1205726&view=rev
> Log:
> Plug a memory leak in the fs-base deltification logic. Twice in a
> decade I've seen th
While reviewing r1205726 I came across this pearl:
reps-strings.c- /* Make a list of all the rep's we need to undeltify
this range.
reps-strings.c- We'll have to read them within this trail anyway,
so we might
reps-strings.c- as well do it once and up front. */
r
I took the liberty to clarify the purpose of contrib/client-side/emacs/
vc-svn.el - to provide for a working vc-mode in Emacs 21 - since it
has occasionally been used when it shouldn't, confusing the user. The
file now also clearly states that new development should go in the
Emacs tree inst
svn_fs_base__retry_txn() is a while(1) loop that calls
begin_trail(pool) in every iteration. The latter function callocates
a struct trail_t out of POOL.
Is there a memory growth issue here? Will the number of iterations of
the while(1) loop be small or bounded? If not, should we avoid repeated
appzer0 writes:
> + LDFLAGS='-L/usr/lib -L/lib'
Why?
> libtool: install: (cd /tmp/subversion-1.7.1/subversion/libsvn_delta;
> /bin/sh /tmp/subversion-1.7.1/libtool --tag CC --silent --mode=relink
> gcc -m32 -O2 -march=i686 -pipe -pthread -D_LARGEFILE64_SOURCE -DNE_LFS
> -Werror=implicit-functi
Hello,
My distro is a full multilib capable system, it has 32-bits libs in /lib
and /usr/lib and 64-bit libs in /lib64 and /usr/lib64. Subversion build
system has never complained before, as I have an exotic multilib distro
but it now fails (1.7.1), especially the 32-bit build :
Below are th
Philip Martin writes:
> I'm not 100%
> sure whether we need second one as well as the first one: I suspect that
> the first alone is not enough, but so far I've failed to come up with a
> test case to prove that.
I can't get valgrind to trigger but if I extend the test case like this:
Index: su
On Tue, Nov 22, 2011 at 10:17 AM, Alexander Kitaev wrote:
> Hello All,
>
> Let me introduce our new project: SubGit (http://subgit.com/).
> SubGit is a free tool for smooth migration from Subversion to Git. As
> well as from Git to Subversion. Without git-svn insanity.
> It works like this:
You'v
"C. Michael Pilato" writes:
> On 11/24/2011 09:39 AM, Philip Martin wrote:
>> Philip Martin writes:
>>
>>> $ valgrind -q .libs/lt-locks-test 4 --fs-type bdb
>>> ==15971== Invalid read of size 1
>>
>> I've fixed this particular case by r1205839 with an early return. I
>> also committed r120584
On 11/24/2011 09:39 AM, Philip Martin wrote:
> Philip Martin writes:
>
>> $ valgrind -q .libs/lt-locks-test 4 --fs-type bdb
>> ==15971== Invalid read of size 1
>
> I've fixed this particular case by r1205839 with an early return. I
> also committed r1205848 which I think fixes the underlying pr
Philip Martin writes:
> $ valgrind -q .libs/lt-locks-test 4 --fs-type bdb
> ==15971== Invalid read of size 1
I've fixed this particular case by r1205839 with an early return. I
also committed r1205848 which I think fixes the underlying problem.
--
uberSVN: Apache Subversion Made Easy
http://w
$ valgrind -q .libs/lt-locks-test 4 --fs-type bdb
==15971== Invalid read of size 1
==15971==at 0x4C25CF3: strncmp (mc_replace_strmem.c:398)
==15971==by 0x652BA6A: svn_fs_bdb__locks_get (locks-table.c:257)
==15971==by 0x653A0F0: txn_body_get_locks (lock.c:440)
==15971==by 0x654125E:
Dmitry Batrak writes:
> The following command:
>
> svn log
> https://svn.apache.org/repos/asf/subversion/branches/gnome-keyring/subversion/bindings/javahl@871338
> -r 870558:871338 -g
>
> returns a number of irrelevant revisions (in particular, 870728,
> 870496, 869828) in the 'main' line of the
15 matches
Mail list logo
