[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: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Tue, 10 Mar 2009 07:43:36 -0500

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
Received on 2009-03-10 13:43:58 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.