On Thu, May 06, 2010 at 09:33:43AM -0400, Alexander Hansen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 5/6/10 9:29 AM, Jack Howarth wrote:
> > Currently 'fink -m' won't complete on the gcc4x packages because
> > of the warnings...
> >
> > Warning: /sw/lib/gcc4.4/lib/libgcc_s.10.4.dylib ends in .dylib but is not
> > of filetype DYLIB according to otool.
> > Warning: /sw/lib/gcc4.4/lib/libgcc_s.10.5.dylib ends in .dylib but is not
> > of filetype DYLIB according to otool.
> >
> > The operative test here appears to be...
> >
> > if (open(OTOOL, "$otool -hv '$file' |"))
> > {
> > while (my $line = <OTOOL>) {
> > if (my ($type) = $line =~ /MH_MAGIC.*\s+DYLIB\s+/) {
> > if ($filename !~ /\.(dylib|jnilib)$/) {
> > print "Warning: $filename is a DYLIB but it does not end
> > in .dylib or .jnilib.\n";
> > }
> > push(@installed_dylibs, $filename);
> > } elsif ($line =~ /MH_MAGIC/) {
> > if ($filename =~ /\.dylib$/) {
> > print "Warning: $filename ends in .dylib but is not of
> > filetype DYLIB according to otool.\n";
> > }
> > }
> > }
> > close (OTOOL);
> >
> > in Validation.pm. It is puzzling that this fails validation since, we get
> > from otool...
> >
> > otool -hv /sw/lib/gcc4.4/lib/libgcc_s.1.dylib
> > /sw/lib/gcc4.4/lib/libgcc_s.1.dylib:
> > Mach header
> > magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
> > MH_MAGIC_64 X86_64 ALL 0x00 DYLIB 9 1472
> > NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS
> >
> > and for the dylib stub...
> >
> > otool -hv /sw/lib/gcc4.4/lib/libgcc_s.10.4.dylib
> > /sw/lib/gcc4.4/lib/libgcc_s.10.4.dylib:
> > Mach header
> > magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
> > MH_MAGIC_64 X86_64 ALL 0x00 DYLIB_STUB 9 1472
> > NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS
> >
> > Shouldn't the latter be matching the test for a valid form of dylib since
> > the filetype
> > does contain the text DYLIB or is the trailing _STUB confusing the test?
> > Jack
> >
> >
>
> The trailing _STUB isn't handled by the test, which looks for DYLIB
> surrounded on either side by whitespace.
>
Alexander,
Can we fix that? If so, I am currently testing an InfoTest script for
the gcc44-4.4.4-100 and gcc45-4.5.0-1001 packages. It is bad enough when
the current 'fink -m' fails on these packages but if I add an InfoTest
(which I assume will be executed automatically for -m), it will become
even more annoying for end users.
Jack
> - --
> Alexander Hansen
> Fink User Liaison
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvixTcACgkQB8UpO3rKjQ/n/ACeLpWlB4KFlKDsFj2u5z4hSSks
> LXIAnj4u9wNt3dxFdP8GzXiRBPmVwkkm
> =BSl3
> -----END PGP SIGNATURE-----
------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
