Hello,
Having just spent a week pinging back and forth with the chaps at cenqua, it seems you should be made aware of the following issue when building svn 1.4 from source.
Running the top level "configure --help" tells me that shared library builds are enabled by default. However if you check the configure script for neon, it defaults to shared libs being disabled.
For svn 1.3.2 the top level configure "did the right thing" - i.e. it forced neon to build with shared libraries. However for some reason the svn 1.4 release doesn't. You can easily see this by checking the difference in the config.log files in the neon directory between the two releases.
This causes mayhem when you (for example) use the javahl bindings, as the libsvn_ra_dav so is incomplete (though no build error/warning) as it can't link to the specified libneon.so (as it wasn't built). The error only occurs when actually using/loading the java bindings and usually ends up being something like "libsvn_ra_dav-1.so.0: undefined symbol: gss_delete_sec_context".
The workaround is simply to include "--enable-shared" as an option to configure, but I see a number of people have already fallen over this (on the fisheye forum) and I think there was also someone with similar problems with the Perl bindings. So please can someone comment on why this default behaviour changed from v1.3.2 and whether it will be re-instated for v1.4.
regards
Phil.
--------------------------------------------------------
--------------------------------------------------------
Register now *at no cost* for ConfigCon™ Silicon Valley 2006 that takes place October 30, 31 at the Santa Clara Hyatt Regency/Santa Clara Convention Center. Titled "Trends in 21st Century IC Design" the free event offers 10 keynotes and 20+ technology breakout presentations from companies throughout the ecosystem of configurable SoC design. www.configcon.com
Unless otherwise expressly stated, this message does not create or vary any contractual relationship between you and ARC International. The contents of this e-mail may be confidential and if you have received it in error, please delete it from your system, destroy any hard copies and telephone the above number. Incoming emails to ARC may be subject to monitoring other than by the addressee. EL
Received on Sun Oct 15 21:45:33 2006