> 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. -- 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