On Mon, May 03, 2010 at 01:31:31PM -0400, Alexander Hansen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 5/3/10 1:12 PM, Jack Howarth wrote:
> > I think there is a fatal flaw with the concept of
> > having every gcc4x package contain a gcc split-off
> > such that the newest available FSF gcc is always used.
> > The packages that BuildDepends on gcc must also Depends
> > on a particular gcc4x-shlibs. How exactly will fink
> > dynamically update the Depends field in the info file
> > to depend on the particular gcc4x release which happens
> > to be building via the BuildDepends on gcc. I simply
> > don't see how this could be done without a major
> > enhancement of fink to provide a mechanism to reset
> > the Depends field from with in the scripts of the
> > info file.
> > Jack
> >
>
> A precedent is "python":
>
> $ fink dumpinfo -fallversions python
> Information about 10108 packages read in 1 seconds.
> allversions:
> b 1:2.4.4-1
> b 1:2.5.4-1
> b 1:2.6.4-1
> bi 1:2.6.4-3
>
> And in that case we _don't_ have packages *depend on 'python' unless
> they need just _a_ python and don't do anything to code a version."
>
> So for packages where none of the libraries from FSF gcc get linked,
> perhaps a BuildDepends on 'gcc' would be OK.
This wlll likely never be the case. For gcc44 and earlier, any executable
created with the FSF gcc compiler will be linked against
%p/lib/gcc4.x/libgcc_s.1.dylib. For gcc45 and later, we now have
an additional libgcc_ext versioned stub which provides all of the
libgcc symbols that postdate the system versioned of the libgcc_s stub.
This means that under Leopard an executable links as...
./a.out:
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
1.0.0)
/sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.1.5)
where the appearance of /usr/lib/libgcc_s.1.dylib provides all of
the symbols from the system /usr/lib/libgcc_s.10.5.dylib versioned stub
whereas the /sw/lib/gcc4.5/lib/libgcc_s.1.dylib entry provides the remaining
symbols listed in the /sw/lib/gcc4.5/lib/libgcc_ext.10.5.dylib
versioned stub for libgcc_ext.
I suspect the whole idea of automated upgrades in the 'system'
FSF gcc compiler package is a bridge too far for fink.
Jack
>
> I'm in agreement with Jack: without automatic shared-library dependency
> updates (and revision updates?) there just does not seem to be a
> feasible shortcut option here except as noted above (and I don't have
> any examples).
> - --
> Alexander Hansen
> Fink User Liaison
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvfCHMACgkQB8UpO3rKjQ+TvwCePClsIg/BSX0tCydFeowjRw3J
> t4gAn3X995tWbS2Lf+DmxTL/nM7ycOzn
> =pE10
> -----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
