Why not still apply the patch until we have something better? It
would at least let the buildbot serve its purpose again.
Mark
On Tue, Mar 10, 2009 at 8:43 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> On Mar 10, 2009, at 3:56 AM, Justin Erenkrantz wrote:
>
>> On Mon, Mar 9, 2009 at 9:54 PM, Hyrum K. Wright
>> <hyrum_wright_at_mail.utexas.edu> wrote:
>>> In investigating the newly-failing in-tree JavaHL tests, I discovered
>>> that some path variables are no longer being set correctly in build-
>>> outputs.mk. Specifically, when using libtool and building shared
>>> libraries, we get paths which look like this:
>>>
>>> libsvn_fs_fs_PATH = subversion/libsvn_fs_fs
>>> libsvn_fs_util_PATH = subversion/libsvn_fs_util
>>> libsvnjavahl_PATH = subversion/bindings/javahl/native
>>>
>>> This happens for the paths to all of our dynamically loaded
>>> libraries. Instead, the above should be set to the following values:
>>>
>>> libsvn_fs_fs_PATH = subversion/libsvn_fs_fs/.libs
>>> libsvn_fs_util_PATH = subversion/libsvn_fs_util/.libs
>>> libsvnjavahl_PATH = subversion/bindings/javahl/native/.libs
>>>
>>> This isn't a problem for the standard build, because we don't
>>> actually
>>> use any of those path variables. We do use libsvnjavahl_PATH, which
>>> is used to set the path to the jni library when running 'make check-
>>> javahl'. Hence the failure.
>>>
>>> I've tried looking into gen-make and friends, but to no avail. Since
>>> this happened around the same time as our change in libtool, I think
>>> that it make be related to that, but I'm not quite familiar enough
>>> with the build system to know the exact cause or the fix. Thoughts?
>>
>> I believe the patch below would solve the immediate issue (I can't
>> build javahl to test), but that's not really 'right' as GNU libtool
>> isn't guaranteed to use '.libs'. GNU libtool isn't consistent -
>> depending upon the configuration - it may or may not stick the
>> intermediate libraries in .libs. This gets back to the whole mess
>> with uninstalled shared libraries that GNU libtool creates - you
>> really aren't supposed to use them until they're installed, but alas,
>> welcome to libtool hell.
>>
>> As for the 'right' solution, perhaps the build system should really do
>> something conditional based if .libs exists. -- justin
>>
>> Index: configure.ac
>> ===================================================================
>> --- configure.ac (revision 36447)
>> +++ configure.ac (working copy)
>> @@ -946,7 +946,7 @@
>> dnl The temporary directory where libtool compiles libsvnjavahl.
>> dnl N.B. objdir is "the name of the directory that contains
>> temporary
>> dnl libtool files" and it is set by libtool.m4
>> - JAVAHL_OBJDIR='$(libsvnjavahl_PATH)'/$objdir
>> + JAVAHL_OBJDIR='$(libsvnjavahl_PATH)'/.libs
>>
>> os_arch=`uname`
>> if test "$os_arch" = "Darwin"; then
>
> This looks like it solves the immediate problem, but I think we both
> agree that it fixes the symptom and not the disease. (Then again,
> libtool is more like terminal cancer...)
>
> -Hyrum
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1302837
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1308840
Received on 2009-03-11 18:57:13 CET