Malcolm Rowe wrote:
> On Tue, Sep 19, 2006 at 07:03:30PM +0530, Kamesh Jayachandran wrote:
>
>> I failed to understand the neon issue here, I did not do any research on
>> it yet.
>>
>
> Max's note is fairly clear:
>
> # This is a workaround for a libtool bug, which manifests on Linux and similar
> # ELF platforms, when linking to an installed Neon, and there are old
> # Subversion libraries in the same directory as the installed Neon.
>
> As noted there, if you link to an already-installed Neon (i.e. you're
> _not_ using an in-tree version), libtool will place the path to
> the installed Neon before the path to the not-yet-installed copies
> of the Subversion libraries. Since the Subversion libraries are
> usually installed in the same place as Neon, this causes the resulting
> executables to pick up the installed Subversion libraries rather than
> the just-compiled ones.
>
> This bug in libtool can be worked around by working out the transitive
> dependencies ourselves, since that the only point where the bug occurs.
>
>
>> If it was the problem it should be the problem with every other shared
>> lib right?
>> Like 'bdb' et al. we did not have any such dependency of 'bdb' with each
>> binary with a main function.
>>
>
> You're right, from the explanation above, it should also be a problem
> with BDB. I can't explain why it's not.
>
>
>> From my bare understanding of the issue, it might have got to do with
>> 'neon' dir under $abs_src_dir of subversion kind of build.
>> As sqlite is never entertained from the $abs_srcdir of subversion we
>> need not bother about this.
>>
>>
>
> I don't think that it necessarily involves a source build of Neon -
> quite the opposite.
>
> Regards,
> Malcolm
>
>
I could reproduce the same problem with my libtool 1.5.6.
And I have a different solution to the issue, I am working on seeings
its effectiveness in different cases.
Basically moving the libsvn_ra to end of libs fixes the issue.
I am just experimenting with many such indirect 3rd party lib references
simultaneously by a 'exe'.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 22 13:59:16 2006