Jens Seidel schrieb:
> I remember that on a 64 bit platform javahl was not found by default by
> Subclipse in /usr/lib64/ which is one of the default linker paths on
> this system (there was an entry in /etc/ld.so.conf). As far as I
> remember it was explained on this list that java behaves differently
> and doesn't follow ld's configuration.
I'm not sure, but maybe the javahl libs are loaded by doing something
like System#loadLibrary()/Runtime#getRuntim#loadLibrary() and these Java
methods only look into the paths in java.library.path (Mark will know,
if this really is true or not). And if java.library.path did't contain
/usr/lib64 this directory would be left out when looking for the javahl
libs.
This, provided it's true, would explain things - if it wasn't
contradicted by the fact that on my 64-bit Hardy system /usr/lib64 is
just a symlink to /usr/lib, which, by default, *is* contained in
java.library.path.
So, maybe a better explanation for what you saw might be: it had nothing
to do with which directories were searched or not for the javahl lib but
with the fact that Subclipse 1.4 needs Subversion 1.5 but Hardy only
provides 1.4. But I'm just guessing here.
Anyway: I don't think it's really important if what I wrote above is
correct or simply a pile of crap.
I think the important point (on which we agree, as I see it) is that you
have to somehow point the mechanism that loads the javahl lib to the
directory which contains the 1.5 svn/svnjavahl libs. Whether one does it
using LD_LIBRARY_PATH or java.library.path is a matter of taste and needs.
Reagrds
mks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
Received on 2008-08-15 14:27:07 CEST