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

Re: Building 1.9.3 on OS X - problems with @loader_path

From: Branko Čibej <brane_at_apache.org>
Date: Thu, 17 Dec 2015 21:06:06 +0100

On 17.12.2015 10:25, Thomas Singer wrote:
> Hello,
>
> We are having a script that builds SVN 1.9 for us on OS X 10.7.
> Yesterday I've ran it for SVN 1.9.3 successfully. But when running
> "otool -L libsvnjavahl-1.jnilib" I've got following output:
>
>> libsvnjavahl-1.jnilib:
>> @loader_path/libsvnjavahl-1.0.0.0.dylib (compatibility version
>> 1.0.0, current version 1.0.0)
>> @loader_path/libstdc++.6.dylib (compatibility version 7.0.0,
>> current version 52.0.0)
>> @loader_path/libsvn_repos-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libsvn_fs-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libsvn_fs_fs-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libsvn_fs_x-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libsvn_fs_util-1.0.dylib (compatibility version
>> 1.0.0, current version 1.0.0)
>> /usr/lib/libsvn_delta-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> /usr/lib/libsvn_subr-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current
>> version 1.2.8)
>> /usr/lib/libsvn_client-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> /usr/lib/libsvn_wc-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> /usr/lib/libsvn_ra-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> /usr/lib/libsvn_ra_local-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> /usr/lib/libsvn_ra_svn-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> /usr/lib/libsvn_ra_serf-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> /Users/syntevo/svn/svn-tmp/usr/lib/libserf-1.dylib (compatibility
>> version 1.3.0, current version 1.3.0)
>> /usr/lib/libsvn_diff-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> /Users/syntevo/svn/svn-tmp/usr/lib/libaprutil-1.0.dylib
>> (compatibility version 6.0.0, current version 6.3.0)
>> /Users/syntevo/svn/svn-tmp/usr/lib/libapr-1.0.dylib
>> (compatibility version 6.0.0, current version 6.0.0)
>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
>> (compatibility version 150.0.0, current version 635.21.0)
>> /System/Library/Frameworks/Security.framework/Versions/A/Security
>> (compatibility version 1.0.0, current version 55148.6.0)
>> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
>> (compatibility version 1.0.0, current version 53.0.0)
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 159.1.0)
>
> After this caused problems with launching (we unpack the libraries to
> a temporary directory), I've rebuild again with exactly the same
> script and now "otool -L libsvnjavahl-1.jnilib" produces the expected
> output (all libraries with the @loader_path/ prefix):
>
>> libsvnjavahl-1.jnilib:
>> @loader_path/libsvnjavahl-1.0.0.0.dylib (compatibility version
>> 1.0.0, current version 1.0.0)
>> @loader_path/libstdc++.6.dylib (compatibility version 7.0.0,
>> current version 52.0.0)
>> @loader_path/libsvn_repos-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libsvn_fs-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libsvn_fs_fs-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libsvn_fs_x-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libsvn_fs_util-1.0.dylib (compatibility version
>> 1.0.0, current version 1.0.0)
>> @loader_path/libsvn_delta-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libsvn_subr-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libz.1.dylib (compatibility version 1.0.0, current
>> version 1.2.8)
>> @loader_path/libsvn_client-1.0.dylib (compatibility version
>> 1.0.0, current version 1.0.0)
>> @loader_path/libsvn_wc-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libsvn_ra-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libsvn_ra_local-1.0.dylib (compatibility version
>> 1.0.0, current version 1.0.0)
>> @loader_path/libsvn_ra_svn-1.0.dylib (compatibility version
>> 1.0.0, current version 1.0.0)
>> @loader_path/libsvn_ra_serf-1.0.dylib (compatibility version
>> 1.0.0, current version 1.0.0)
>> @loader_path/libserf-1.dylib (compatibility version 1.3.0,
>> current version 1.3.0)
>> @loader_path/libsvn_diff-1.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> @loader_path/libaprutil-1.0.dylib (compatibility version 6.0.0,
>> current version 6.3.0)
>> @loader_path/libapr-1.0.dylib (compatibility version 6.0.0,
>> current version 6.0.0)
>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
>> (compatibility version 150.0.0, current version 635.21.0)
>> /System/Library/Frameworks/Security.framework/Versions/A/Security
>> (compatibility version 1.0.0, current version 55148.6.0)
>> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
>> (compatibility version 1.0.0, current version 53.0.0)
>> @loader_path/libSystem.B.dylib (compatibility version 1.0.0,
>> current version 159.1.0)
>
> I want to avoid such differences when building the next time. Does
> somebody has any clue what could have gone wrong the first time build?

I remember that prefixing the rpaths with @loader_path is a hack to work
around OSX limitations that is part of the SmartSVN build; it has
nothing to do with Subversion.

-- Brane
Received on 2015-12-17 21:06:19 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.