[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Broken output of gen_make.py

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 11 Mar 2009 13:56:55 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.