Description of problem: When using subclipse, the svnkit client is never available, and the javahl backend disappears after the workspace has been restarted once. Concretely, here's what I'm seeing: 1. Start eclipse with a totally new workspace directory (i.e., let it create the directory) 2. Go to Window - Preferences - Team - SVN 3. Under SVN Interface, the Client pulldown has two entries: - JavaHL (JNI) 1.6.1 (r37116) - SVNKit (Pure Java) Not Available 4. Close Eclipse and re-open it with the same workspace 5. Go to the same preference page ... and the first entry has now changed to "JavaHL (JNI) Not Available" !!! This means that I really can't use subclipse at the moment ... Version-Release number of selected component (if applicable): eclipse-subclipse-1.6.0-1.fc11.noarch eclipse-svnkit-1.2.3-1.fc11.noarch subversion-javahl-1.6.1-4.fc11.x86_64 eclipse-platform-3.4.2-9.fc11.x86_64 NB: This is on x86_64, if that makes any difference ...
Just one thing to mention, SVNKit is disabled by upstream developers until it implements SVN 1.6 features, the only available option that can be used is JavaHL with subclipse 1.6 Do you see any message related to this bug on $workspace/.metadata/.log. Can you try running "eclipse -clean"
Unfortunately, I can see no relevant messages in the log file, and once the workspace gets into this state, "eclipse -clean" doesn't make anything better.
Hmm, looks like some errors are getting logged sometimes. Doesn't look too useful though: !ENTRY org.tigris.subversion.subclipse.core 4 0 2009-04-20 16:39:12.229 !MESSAGE Unable to load default SVN Client !STACK 1 org.tigris.subversion.subclipse.core.SVNException: Unable to load default SVN Client at org.tigris.subversion.subclipse.core.SVNException.wrapException(SVNException.java:85) at org.tigris.subversion.subclipse.core.status.StatusCacheManager.refreshStatus(StatusCacheManager.java:289) at org.tigris.subversion.subclipse.core.resourcesListeners.FileModificationManager.refreshStatus(FileModificationManager.java:179) at org.tigris.subversion.subclipse.core.resourcesListeners.FileModificationManager.resourceChanged(FileModificationManager.java:128) at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:288) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:282) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:148) at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:313) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1022) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1809) at org.eclipse.core.internal.events.NotificationManager$NotifyJob.run(NotificationManager.java:39) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: org.tigris.subversion.subclipse.core.SVNException: Unable to load default SVN Client at org.tigris.subversion.subclipse.core.SVNClientManager.getAdapter(SVNClientManager.java:146) at org.tigris.subversion.subclipse.core.SVNClientManager.getSVNClient(SVNClientManager.java:90) at org.tigris.subversion.subclipse.core.SVNProviderPlugin.getSVNClient(SVNProviderPlugin.java:424) at org.tigris.subversion.subclipse.core.status.NonRecursiveStatusUpdateStrategy.statusesToUpdate(NonRecursiveStatusUpdateStrategy.java:53) at org.tigris.subversion.subclipse.core.status.StatusCacheManager.refreshStatus(StatusCacheManager.java:264) ... 11 more !SUBENTRY 1 org.tigris.subversion.subclipse.core 4 -6 2009-04-20 16:39:12.231 !MESSAGE Unable to load default SVN Client !STACK 1 org.tigris.subversion.subclipse.core.SVNException: Unable to load default SVN Client at org.tigris.subversion.subclipse.core.SVNClientManager.getAdapter(SVNClientManager.java:146) at org.tigris.subversion.subclipse.core.SVNClientManager.getSVNClient(SVNClientManager.java:90) at org.tigris.subversion.subclipse.core.SVNProviderPlugin.getSVNClient(SVNProviderPlugin.java:424) at org.tigris.subversion.subclipse.core.status.NonRecursiveStatusUpdateStrategy.statusesToUpdate(NonRecursiveStatusUpdateStrategy.java:53) at org.tigris.subversion.subclipse.core.status.StatusCacheManager.refreshStatus(StatusCacheManager.java:264) at org.tigris.subversion.subclipse.core.resourcesListeners.FileModificationManager.refreshStatus(FileModificationManager.java:179) at org.tigris.subversion.subclipse.core.resourcesListeners.FileModificationManager.resourceChanged(FileModificationManager.java:128) at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:288) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:282) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:148) at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:313) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1022) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1809) at org.eclipse.core.internal.events.NotificationManager$NotifyJob.run(NotificationManager.java:39) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) !SUBENTRY 2 org.tigris.subversion.subclipse.core 4 -6 2009-04-20 16:39:12.231 !MESSAGE Unable to load default SVN Client
If I update to subversion 1.6.1, svn becomes broken in Eclipse, with the trace in #3. There are no apparent workarounds (other than reverting to 1.6.0), and it always happens.
Extra information: here's the actual error from subclipse, which I modified to print out its errors. The most interesting line is highlighted with !!!!: Failed to load JavaHL Library. These are the errors that were encountered: no libsvnjavahl-1 in java.library.path !!!!!! /usr/lib64/libsvnjavahl-1.so.0.0.0: /usr/lib64/libsvnjavahl-1.so.0.0.0: undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE no svnjavahl in java.library.path java.library.path = /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/usr/lib64/xulrunner-1.9.1:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib So it looks like libsvnjavahl-1.so is somehow badly linked. Checking with "ldd -r" gives the following output (sorry for the verbosity): % ldd -r /usr/lib64/libsvnjavahl-1.so.0.0.0 undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: __cxa_pure_virtual (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZTVSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZTVSt15basic_stringbufIcSt11char_traitsIcESaIcEE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZTTSt14basic_ofstreamIcSt11char_traitsIcEE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZTVSt9basic_iosIcSt11char_traitsIcEE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSs4_Rep20_S_empty_rep_storageE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt14basic_ofstreamIcSt11char_traitsIcEED1Ev (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt8ios_base4InitD1Ev (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZTVSt15basic_streambufIcSt11char_traitsIcEE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZTVSt14basic_ofstreamIcSt11char_traitsIcEE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZTTSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: __gxx_personality_v0 (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED1Ev (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNKSt15basic_stringbufIcSt11char_traitsIcESaIcEE3strEv (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt15_List_node_base4hookEPS_ (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: __cxa_begin_catch (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSs4_Rep10_M_destroyERKSaIcE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _Znwm (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSo3putEc (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSs6assignEPKcm (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt8ios_baseC2Ev (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNKSs7compareERKSs (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZdlPv (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSo9_M_insertIlEERSoT_ (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZSt18_Rb_tree_decrementPKSt18_Rb_tree_node_base (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZSt16__throw_bad_castv (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSsC1EPKcRKSaIcE (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt6localeC1Ev (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSsD1Ev (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNKSt5ctypeIcE13_M_widen_initEv (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_ (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt13basic_filebufIcSt11char_traitsIcEED1Ev (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSo5flushEv (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: __cxa_end_catch (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt13basic_filebufIcSt11char_traitsIcEE4openEPKcSt13_Ios_Openmode (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt6localeD1Ev (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt8ios_base4InitC1Ev (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSs6assignEPKc (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSs6assignERKSs (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt13basic_filebufIcSt11char_traitsIcEE5closeEv (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt9basic_iosIcSt11char_traitsIcEE5clearESt12_Ios_Iostate (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt13basic_filebufIcSt11char_traitsIcEEC1Ev (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSolsEi (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: __cxa_rethrow (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSt9basic_iosIcSt11char_traitsIcEED2Ev (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSsC1ERKSs (/usr/lib64/libsvnjavahl-1.so.0.0.0) undefined symbol: _ZNSs6appendEPKcm (/usr/lib64/libsvnjavahl-1.so.0.0.0) linux-vdso.so.1 => (0x00007fff501fe000) libsvn_client-1.so.0 => /usr/lib64/libsvn_client-1.so.0 (0x00007f3347c97000) libsvn_wc-1.so.0 => /usr/lib64/libsvn_wc-1.so.0 (0x00007f3347a4f000) libsvn_ra-1.so.0 => /usr/lib64/libsvn_ra-1.so.0 (0x00007f3347844000) libsvn_ra_local-1.so.0 => /usr/lib64/libsvn_ra_local-1.so.0 (0x00007f334763c000) libsvn_repos-1.so.0 => /usr/lib64/libsvn_repos-1.so.0 (0x00007f3347413000) libsvn_ra_svn-1.so.0 => /usr/lib64/libsvn_ra_svn-1.so.0 (0x00007f33471fb000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f3346fe1000) libsvn_ra_neon-1.so.0 => /usr/lib64/libsvn_ra_neon-1.so.0 (0x00007f3346dbd000) libsvn_diff-1.so.0 => /usr/lib64/libsvn_diff-1.so.0 (0x00007f3346bb1000) libsvn_fs-1.so.0 => /usr/lib64/libsvn_fs-1.so.0 (0x00007f33469aa000) libsvn_fs_fs-1.so.0 => /usr/lib64/libsvn_fs_fs-1.so.0 (0x00007f3346783000) libsvn_fs_base-1.so.0 => /usr/lib64/libsvn_fs_base-1.so.0 (0x00007f3346553000) libsvn_delta-1.so.0 => /usr/lib64/libsvn_delta-1.so.0 (0x00007f3346348000) libsvn_fs_util-1.so.0 => /usr/lib64/libsvn_fs_util-1.so.0 (0x00007f3346146000) libsvn_subr-1.so.0 => /usr/lib64/libsvn_subr-1.so.0 (0x00007f3345ef4000) libz.so.1 => /lib64/libz.so.1 (0x00007f3345cdf000) libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00007f3345a56000) libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00007f3345832000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f33455fb000) libdb-4.7.so => /lib64/libdb-4.7.so (0x00007f3345289000) libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f3345060000) libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00007f3344e35000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3344c19000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f3344a14000) libneon.so.27 => /usr/lib64/libneon.so.27 (0x00007f33447ee000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f33445d4000) libc.so.6 => /lib64/libc.so.6 (0x00007f3344263000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f3344049000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f3343e44000) libfreebl3.so => /lib64/libfreebl3.so (0x00007f3343be5000) /lib64/ld-linux-x86-64.so.2 (0x0000003ee2a00000) libgnutls.so.26 => /usr/lib64/libgnutls.so.26 (0x00007f334393a000) libpakchois.so.0 => /usr/lib64/libpakchois.so.0 (0x00007f3343735000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f3343509000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f3343269000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f3343043000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f3342e40000) libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x00007f3342c2e000) libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00007f33429bb000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f33427b8000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f33425ae000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f33423ac000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f334218d000) %
As an experiment, I rebuilt subversion with one line added to the spec file: export EXTRA_LDFLAGS=-lstdc++ (NB: this is obviously not the correct real fix, but just a check of what the actual underlying problem is) I didn't try installing the resulting RPM, but at least the generated libsvnjavahl-1.so file no longer has any errors under ldd -r. So it seems that this is actually the underlying problem.
I asked about this on the subversion-dev list here: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2093203 The one response was so far from someone who said that it was properly linked on his system, so it looks like it's something to do with the Fedora build system.
*** Bug 500661 has been marked as a duplicate of this bug. ***
This is really bad. Joe, can we please get this fixed as a zero day update for F-11?
FYI, I'm now using a locally-built copy of subversion with the EXTRA_LDFLAGS line I mentioned in comment #6, and subclipse is working fine. So even if that's not the most elegant solution, it does seem to fix the immediate problem.
make x86_64 fails for me in subversion/F-11 with the check-rpaths stuff. Am I doing something wrong?
(In reply to comment #11) > make x86_64 fails for me in subversion/F-11 with the check-rpaths stuff. Am I > doing something wrong? Huh, weird -- I did exactly that yesterday, and it built for me (although the subversion test suite is SLLLOOOOWWW).
I see the problem.
Please try this build: http://koji.fedoraproject.org/koji/buildinfo?buildID=102124 the link line looks for javahl looks correct now; the RPATH issues should also be fixed.
I've confirmed that I can start and close Eclipse multiple times and each time the JavaHL preference for Subclipse is present. Also, ldd shows no missing symbols. I'm doing a re-build now just to verify your rpath fix but I assume since it built in koji that that's fixed as well. Thanks, Joe! Are you going to set up a zero-day update?
subversion-1.6.1-5.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/subversion-1.6.1-5.fc11
Works for me, thanks a lot. OTOH, I think you could have skipped testing, since the previous build is broken.
subversion-1.6.1-5.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.