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? -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ ------------------------------------------------------------------------------ _______________________________________________ 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
