I committed a change to how JavaHL loads its libraries in r1089 and 1090.
Basically, it does two things different:
1) It tries to load the 1.1 library name first.
2) On Windows, I put exception handling around each of the "dependent"
libraries so that the process could continue if they are not found. If
the JavaHL library really needs those libraries then it will fail to load
and behavior will remain the same. However, if it does not need any one
of those libraries, the process can still work properly.
Let me know if this causes anyone any problems. I will try it on my Mac
tonight to double-check it.
Thanks
Mark
Cédric Chabanois <cchabanois@no-log.org> wrote on 11/22/2004 05:05:34 PM:
> Please wait for comments from Panagiotis Korros or McClain Looney before
> committing your patch. They added these lines while correcting issue #83
>
> If I remember well, we don't load the libraries just to do extra checks.
> The problem is that (on windows), we deliver the dlls in
> <eclipse>\plugins\org.tigris.subversion.javahl.win32_0.9.22\
> But if we only loaded libsvnjavahl-1, other dlls (libapr ...) would be
> loaded by windows. And windows would not find these dlls because they
> are not in the path (or in current directory, or in the directory of the
> executable (java.exe or eclipse.exe, I don't know) )
>
> Windows is the only platform for which we deliver the dynamic libraries
> needed (because it is easy)
>
> Cédric
> <mailto:pkorros@tigris.org>
>
> >I am working with a custom build of JavaHL where I do not need
BerkeleyDB.
> > In this case, Subclipse fails to load the JavaHL library, because it
is
> >doing its own dependency checking.
> >
> >I do not see any value in the extra checks that were added to the
> >Subclipse. Perhaps, if when a particular library failed to load it
showed
> >an error message with a reference to that specific library, there could
be
> >some benefit to this, but in general I do not think it is a good idea.
On
> >some platforms, JavaHL could be entirely statically linked. The
trapping
> >of the error in loading the JavaHL library itself should be sufficient
to
> >get what is needed from this feature.
> >
> >I also changed the order in which it tries to load the JavaHL
libraries.
> >The first value it tries is the current name of the library in
Subversion
> >1.1, at least on Windows.
> >
> >If no one has any objections, I will commit this tomorrow.
> >
> >Thanks
> >
> >Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Nov 25 07:08:44 2004