Re: llvm35/clang35 validation requires @rpath acceptance in shlib validation
Alexander Hansen <[email protected]>
| Newsgroups | gmane.os.apple.fink.devel |
|---|---|
| Message-ID | <[email protected]> |
> On Nov 11, 2014, at 11:59 AM, Alexander Hansen <[email protected]> wrote: > >> >> On Nov 9, 2014, at 7:56 AM, Alexander Hansen <[email protected]> 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 <[email protected]> >>>>>> 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 [email protected] List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel