Derrick, you are indeed d man.
Success has been achieved. JavaHL is installed.
My methods were an amalgam of yours and mine.
It was not necessary to download the tarball from subversion.org. The
source that came out of the source rpm was perfectly adequate.
Setting the --PREFIX on the configure was very important. Since java
was not located within the system of redhat rpms, it was necessary to
disconnect totally from that system. To that end, building javahl in a
subdirectory of my home dir was essential. There were still some build
errors when the installer tried to copy some files into /usr/lib, but
these were libs pertaining to subversion itself, not javahl and I'd
already installed subversion, and that did not prove to be a problem.
And of course it is necessary to launch Eclipse with a script (I
previously wasn't doing that - I used a gnome launcher pointing at the
binary), and to modify that script to change the LD_LIBRARY_PATH. There
is nothing that cannot be solved with adding a level of indirection.
Going forward, it would be a boon to others if the source rpm install
could somehow be modified to build javahl. In order to do so, it will
be necessary to get around the seeming requirement that java has been
installed within the /usr/lib hierarchy. Since I prefer the Sun JDKs to
anything that I've seen RedHat release in an RPM, I install java under
/usr/local. For most things, it's just easier that way. I'm sure I'm
not the only one. This all falls apart with subversion/javahl, which
sits at the intersection point between java and linux.
However, that may go against the whole RPM concept. If not, if there is
a way around that, it would be good if the source rpms could be
rewritten to support this kind of deployment. I'd be happy to supply
any information to anyone who wants to make that effort.
Steve Cohen wrote:
> Thanks, again, Derrick.
> Well, I haven't tried it your way, yet.
>
> With all the differences between your setup and mine, I think the only
> one that matters is that you have installed java on your system as a
> "locally-built package" which has enabled it to be placed under /usr/lib
> while mine sits under /usr/local. I've asked the creators of the
> java-package package if there is anything similar for RedHat. Possibly,
> there may be significant differences between Debian's libtool and
> RedHat's that may be playing a role as well.
>
> JAVA_HOME for the purposes here is just a convenient way for configure
> to look for the jdk.
>
> I tried one variant on my way. I created a symlink to
> /usr/local/j2sdk1.4.2 under /usr/lib. Configure wasn't fooled by this
> trickery. I think it calls pwd to find out its current location
> whenever it needs this.
>
> So now, I am off to trying your way. Maybe by specifying a totally
> separate build environment, I can get this to work.
>
>
>
> Derrick Hudson wrote:
>
>> Hey, good timing! Just last night I was reading your thread from
>> earlier in the week. My experience with the command-line wrapper
>> implementation has been really unacceptable. Earlier today I decided
>> to try installing the javahl interface and I was successful.
>>
>> On Sat, Feb 12, 2005 at 04:49:44PM -0600, Steve Cohen wrote:
>> | OK, let's start fresh. I posted this earlier but in a way that may
>> have | been too verbose. I'm trying to install javahl with no luck
>> onto a RH9 | system.
>> | | My JAVA_HOME is /usr/local/j2sdk1.4.2. It's a Sun JDK, installed
>> in | /usr/local precisely because it was installed outside of the
>> redhat RPM | system.
>> | | I've installed eclipse 3.0. It works fine with this java
>> configuration.
>> | | I've installed subversion-1.13 via src rpm (from David Summers).
>> It | works. This rpm does not install javahl.
>>
>> Ok, so far so good. I use debian, but the concept is the same.
>>
>> | I still have the BUILD directory with all the makefiles, configure |
>> scripts, etc.
>> | | I've installed subeclipse. It works - albeit slowly.
>> | | From this configuration, I can run make-javahl and it works.
>> | I cannot run install-javahl. It tries to install the libraries into
>> | /usr/local/lib producing error message from libtool:
>> | | libtool: install: error: cannot install `libsvn_delta-1.la' to a |
>> directory not ending in /usr/lib
>>
>> This is odd, I think, but it may be something with redhat's libtool.
>> Libraries can be installed anywhere you please. In order for the
>> library to be useful, it must be able to be found by the linker ('ld')
>> for the process that you want to use it. I'll explain this better
>> later on.
>>
>> [...]
>> | How can we configure this to load javaHL under my system? It seems
>> a | shame to have come all this way only to fail because of an install
>> script.
>>
>> Here is what I did, and why:
>>
>> $ mkdir subclipse
>> $ cd subclipse
>> $ wget http://subversion.tigris.org/tarballs/subversion-1.1.3.tar.gz
>> $ tar -zxvf subversion-1.1.3.tar.gz
>> $ cd subversion-1.1.3
>>
>> First I created a new directory to work in. I downloaded and unpacked
>> the source directly from the subversion team.
>>
>> $ ./configure --prefix=$HOME/opt/subversion --enable-javahl \
>> --with-jdk=/usr/lib/j2sdk1.5-sun/ \
>> --without-apache --without-swig
>> $ make && make javahl && make install && make install-javahl
>>
>> Then I configured, built and installed the software.
>>
>>
>> Some background information pertaining to my choice of paths:
>> + my system is debian
>> + subversion is installed from the vendor-supplied package
>> + Java is a installed from a locally-built package containing the
>> Sun JDK (it it just a handy mechanism debian has for this
>> situation
>> similar to their kernel package builder;
>> http://packages.debian.org/unstable/misc/java-package)
>> + I don't have $JAVA_HOME set; instead I just rely on $PATH to
>> find the right 'java', and for any application that really
>> needs $JAVA_HOME I use a shell script to set the right one for
>> that application (ie some might use 1.4 while others use 1.5)
>> + eclipse is installed locally in /opt
>> + subclipse was installed in ~/.eclipse by eclipse' update manager
>> + I did all of the javahl building and installing as a non-root user
>>
>>
>> The first key to making this work is the parameters to 'configure'.
>>
>> First I tell it where I want it to install the end result. I
>> chose a dedicated directory in my home directory. This keeps it
>> out of the way of the packaging system and keeps it self-contained
>> so I can easily remove it when I want to (for example when I
>> upgrade).
>>
>> Second I tell it where to find the java to build with. I haven't
>> tried, but I suspect that the library will only work with the java
>> it was compiled with. (yes, this means that I must rebuild when I
>> upgrade to java 1.6)
>>
>> Third I told configure not to use any apache or swig. I don't
>> know if that really matters or not, but since I already have all
>> of subversion from my vendor-supplied packages I really don't need
>> anything extra from this build.
>>
>> Finally, I have several "-dev" packages installed on my system. I
>> don't know which one(s) other than libc6-dev that subversion needs
>> when building. I just know that I didn't need any I didn't
>> already have.
>> Once configure has configured the build system to do what you want,
>> let it run. The 'install' and 'install-javahl' targets copy the
>> libraries and everything needed at runtime into the directory
>> specified to configure's --prefix argument. Yes this builds and
>> installs a 'svn' and 'svnadmin', etc, that you don't need. This isn't
>> a problem with my choice of --prefix because they are not in my $PATH
>> and will never be used.
>>
>>
>> Finally, I need to enable eclipse to find the javahl library that I
>> now have. I already have a shell script in ~/bin (which is in my
>> $PATH) to run eclipse. I simply added two more lines to that script.
>> The script is essentially as follows :
>>
>> #!/bin/bash
>>
>> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/opt/subversion/lib
>> export
>> CLASSPATH=$CLASSPATH:$HOME/opt/subversion/lib/svn-javahl/svn-javahl.jar
>>
>> exec /opt/eclipse-3.0.1/eclipse \
>> -data ~/projects/eclipse \
>> -vm /usr/lib/j2sdk1.5-sun/bin/java
>>
>> The first key is to set $LD_LIBRARY_PATH so that the linker will be
>> able to find libsvnjavahl-1.so. Read the manpage for 'ld.so' for more
>> information on the linker and how it finds libraries.
>>
>> The second key is to set $CLASSPATH so that java will find the java
>> portion of javahl.
>>
>> Finally it runs eclipse with the necessary parameters.
>>
>>
>>
>> I hope this information helps. If I've provided too much detail and
>> created additional confusion then please ask for further
>> clarification. (be sure to Cc me because I don't check this list very
>> often at all)
>>
>> -D
>>
>>
>> PS Below is some more background information on C and linux
>> distributions:
>>
>> A side note on -dev packages: the C and C++ build
>> environments require certain files (header files) that are not
>> needed at runtime. Distributions choose to provide the
>> binaries and the headers separately so people who don't do any
>> compiling or development don't need to install the headers.
>>
>> With a working knowledge of C's build and runtime environments and
>> your OS's packaging system it would probably be fairly easy, or at
>> least straightforward, to modify the spec file of the srpm you
>> used so that it builds javahl and includes it in the binary rpm.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
>
Received on Mon Feb 14 04:13:45 2005