> On Nov 11, 2014, at 11:59 AM, Alexander Hansen <alexanderk.han...@gmail.com>
> wrote:
>
>>
>> On Nov 9, 2014, at 7:56 AM, Alexander Hansen <alexanderk.han...@gmail.com>
>> wrote:
>>
>> On 11/8/14, 5:23 PM, Alexander Hansen wrote:
>>> On 11/8/14, 3:33 PM, David Fang wrote:
>>>> On Sat, 8 Nov 2014, Alexander Hansen wrote:
>>>>
>>>>> On 11/8/14, 1:03 PM, David Fang wrote:
>>>>>> Alex,
>>>>>>
>>>>>>> On Nov 4, 2014, at 11:07 AM, David Fang <f...@csl.cornell.edu>
>>>>>> wrote:
>>>>>>>>> Hi all,
>>>>>>>> Sitting in my experimental tree is a draft of llvm35's
>>>>>> packaging
>>>>>>>> that bootstraps (much like its predecessor llvm34), but fails
>>>>>> Shlib
>>>>>>>> validation because the install_names for shlibs all start with
>>>>>> @rpath
>>>>>>>> (or
>>>>>>>> on older darwin @executable_path or @loader_path). This was a
>>>>>>>> decision by
>>>>>>>> upstream build maintainers that allows this package to be
>>>>>>>> binary-relocatable, even though fink makes no such guarantees
>>>>>> about > > its
>>>>>>>> packages -- fink's remain in fixed install locations.
>>>>>>>> dmacks and akh began to look into a patch that would allow this
>>>>>> to > > pass
>>>>>>>> validation. Can you guys comment on the status/issues/obstacles?
>>>>>>>> Such a fix would unblock llvm35 from hitting dists.
>>>>>>>>>> Thanks!
>>>>>>>>>> Fang
>>>>>>>>>> --
>>>>>>>> David Fang
>>>>>>>> http://www.csl.cornell.edu/~fang/
>>>>>>>>>>> Here?s the change I injected thus far:
>>>>>>>> diff --git a/perlmod/Fink/Validation.pm
>>>>>> b/perlmod/Fink/Validation.pm
>>>>>>> index 29fc4ab..a5010dd 100644
>>>>>>> --- a/perlmod/Fink/Validation.pm
>>>>>>> +++ b/perlmod/Fink/Validation.pm
>>>>>>> @@ -2198,12 +2198,12 @@ sub _validate_dpkg {
>>>>>>> <OTOOL>; # skip first line
>>>>>>> my ($libname,
>>>>>> $compat_version)
>>>>>>> = <OTOOL> =~ /^\s*(\S+)\s*\(compatibility version ([\d\.]+)/;
>>>>>>> close (OTOOL);
>>>>>>> - if ($libname !~ /^\//) {
>>>>>>> + if (($libname !~ /^\//) and
>>>>>>> ($libname !~ /\@.*path\//)) {
>>>>>>> print "Error: package
>>>>>>> contains the shared library\n";
>>>>>>> print "
>>>>>>> $dylib\n";
>>>>>>> print " but the
>>>>>>> corresponding install_name\n";
>>>>>>> print "
>>>>>>> $libname\n";
>>>>>>> - print " is not
>>>>>>> an absolute pathname.\n";
>>>>>>> + print " is not
>>>>>>> an absolute pathname or runtime path.\n";
>>>>>>> $looks_good = 0;
>>>>>>> } elsif (not exists
>>>>>>> $deb_shlibs->{$libname}) {
>>>>>>> $libname =~
>>>>>>> s/^$basepath/%p/;
>>>>>>>> And the validator moves on:
>>>>>>>> Validating .deb file
>>>>>>> /sw/fink/debs/polly35-shlibs_3.5.0-0_darwin-x86_64.deb...
>>>>>>> Error: package contains the shared library
>>>>>>> /sw/opt/llvm-3.5/lib/libPolly.dylib
>>>>>>> but the corresponding install_name and compatibility_version
>>>>>>> @rpath/libPolly.dylib 0.0.0
>>>>>>> are not listed in the Shlibs field. See the packaging manual.
>>>>>>
>>>>>> Thanks for working on this patch.
>>>>>> I'm a little puzzled about the libPolly error, since my .info file
>>>>>> has:
>>>>>>
>>>>>> Package: polly35-shlibs
>>>>>> ...
>>>>>> Files: <<
>>>>>> opt/llvm-3.5/lib/LLVMPolly.so
>>>>>> opt/llvm-3.5/lib/libPolly*.dylib
>>>>>> <<
>>>>>> DocFiles: tools/polly/LICENSE.txt tools/polly/CREDITS.txt
>>>>>> Shlibs: <<
>>>>>> !% p/opt/llvm-3.5/lib/LLVMPolly.so
>>>>>> !% p/opt/llvm-3.5/lib/libPolly.dylib
>>>>>> <<
>>>>>>
>>>>>> Am I missing some obvious fix?
>>>>>>
>>>>>> Fang
>>>>>>
>>>>>
>>>>> I assumed that it was because Shlibs entries refer to the
>>>>> install_name, which happens not to map onto the filename when using
>>>>> @rpath and friends. Maybe
>>>>>
>>>>> Shlibs: <<
>>>>> !@ rpath/LLVMPolly.so
>>>>> !@ rpath/LLVMPolly.dylib
>>>>> <<
>>>>>
>>>>> would do the job. I'll check that.
>>>>
>>>> Did any of the other split-offs trigger that diagnostic? All shlib
>>>> split-offs follow the same form.
>>>>
>>>
>>> Yeah, they all did.
>>>
>>
>> Now, having put @rpath/foo.dylib in the relevant places, I've been able to
>> find the next place where there's a problem:
>>
>> Fiona-2:upstream_fink hansen$ fink validate
>> /sw/fink/debs/clang35-shlibs_3.5.0-0_darwin-x86_64.deb
>> Validating .deb file
>> /sw/fink/debs/clang35-shlibs_3.5.0-0_darwin-x86_64.deb...
>> Error: Shlibs field specifies file '@rpath/libclang.3.5.dylib', but it does
>> not exist!
>> Error: Shlibs field specifies file '@rpath/libiomp5.dylib', but it does not
>> exist!
>>
>> Maybe in the case where we have @rpath or other such variable we'll want
>> simply to find the dylib, since the whole point of @rpath is that the
>> libraries don't need to know where they are except relative to the
>> executable, right?
>
>
> Upon further thought, this would be problematic to implement, since we could
> be looking for libraries which are outside of the .deb that we’re validating.
>
>
It’d help if I could actually remember what the problem is. :-) The specific
issue in question occurs when iterating over the entries in a Shlibs field, so
the relevant libraries had best be contained in that .deb.
--
Alexander Hansen, Ph.D.
Fink User Liaison
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel