On Mon, May 03, 2010 at 03:04:34PM -0400, Alexander Hansen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 5/3/10 2:45 PM, Jack Howarth wrote:
> > On Mon, May 03, 2010 at 08:22:55PM +0200, Jean-François Mertens wrote:
> >>
> >> On 03 May 2010, at 20:10, Alexander Hansen wrote:
> >>
> >>> Peter reminded me on IRC that the original motivation behind having a
> >>> 'gcc' package was to provide a "current FSF compiler" at runtime for
> >>> packages that needed an FSF compiler tool but didn't care what version
> >>> it was. That's different than trying to automatically update
> >>> anything.
> >>
> >> Sure.
> >> And there was no suggestion of any sort to "automatically update
> >> things",
> >> I only wrote that the scheme might help users to automatically update
> >> their gcc.
> >> As I wrote, the normal situation remains :
> >> Bdep: gcc4N-compiler
> >> Dep: gcc4N-shlibs
> >> (This way deps and bdeps never involve conflicts)
> >>
> >> JF
> >
> > JF,
> > However then the question is why expend the effort? Your average
> > program will have to have link in the either libgcc_s or libgcc_ext
> > from FSF gcc. In those cases, the BuildDepends on gcc would be useless
> > without a mechanism in fink to automatically *tag* the Depends of the
> > package with the appropriate gcc4x-shlibs. Otherwise the practical
> > applications of the BuildDepends gcc are very limited and we would
> > likely spend most of our time explaining the details of this issue.
> > Lastly, you really can't reliably escape from depending on
> > libgcc_ext for gcc45 and later. The compiler will expect to have
> > access to the additional symbols provided there (such as the emutls
> > symbols, etc). Iain Sandoe went out of his way (with Mike Stump)
> > to make certain that all of the symbols in libgcc_s.10.4/10.5 came
> > from the system copy of libgcc_s (FSF gcc 4.5 doesn't even build those stubs
> > any more) but that the additional symbols were always present
> > from the FSF libgc_s via the versioned libgcc_ext.10.4/10.5 stubs.
> > This is why on Leopard gcc 4.5 links as...
> >
> > /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)
> >
> > First all of the libgcc symbols present in the system libgcc_s are resolved
> > via
> > the system libgcc_s.10.5 stub and then all of the remaining symbols from the
> > FSF libgcc_s are resolved via the libgcc_ext.10.5 stub. Hence the linkage
> > order.
> > Jack
>
> I think we're straying afield. We're not talking about BuildDepends:
> gcc here. We're talking about (I believe):
>
> 1) Allowing multiple gccN-compiler packages to coexist, and maintain
> their gccN-shlibs.
> 2) Ordinarily packages will Depend: gcc4N and BuildDepend:
> gcc4N-compiler (assuming that's where the headers reside--I'm a bit hazy
> on the final division here)
> 3) A convenience package for _runtime_ use by packages that don't build
> against a gccN but simply _use_ one of its compilers (e.g. gfortran)
> without caring what version it is, so that such packages didn't have to
> stipulate a particular gccN.
>
> I don't think BuildDepends: gcc was ever entertained (except possibly in
> ultra-rare cases where packages somehow don't link to the gccN libs).
The current packaging that I have on fink tracking for gcc44-4.4.4-1000
and gcc45-4.5.0-1001 uses the following approach. The main package is still
gcc4x but contains only symlinks for the compilers and the manpages under
the old compiler names (gcc-4, etc). This package builds, like MacPorts,
gcc4x with a suffix (in our case -fsf-4.x). The main gcc4x package also has
a PostInstScript that uses update-alternatives to install the info page
symlinks in %p/share/info as well as the symlinks for the overlapping
man3 pages for libffi. The gcc4x-shlibs package still exists but there
is now a second split-off for gcc4x-compiler which contains all of the
files in...
bin/*-fsf-4.5
lib/gcc4.5
share/man/man1/*-fsf-4.5.1
share/man/man3/*-fsf-4.5.3
share/man/man7/*-fsf-4.5.7
The actual info pages are now installed with --infodir=%p/lib/gcc4.5/info
and thus reside in the gcc4x-compiler package. The main gcc4x package
still has...
Conflicts: gcc42, gcc43, gcc44, gcc46
Replaces: gcc42, gcc43, gcc44, gcc46
but Depends on %N-compiler (= %v-%r) whereas the gcc4x-compiler package
has...
Depends: %N-shlibs (= %v-%r)
This approach requires no changes to current packages but allows them
the option to BuildDepends on gcc4x-compiler rather than gcc4x as
long as they explicitly access the compilers via the -fsf-4.x suffixed
names OR use the old names but from within the %p/lib/gcc4.x/bin path.
I think I've bent over backwards to be compatible here.
Jack
> - --
> Alexander Hansen
> Fink User Liaison
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvfHkIACgkQB8UpO3rKjQ/5FACcCFqdQpsQAzZYHslad3vYVV9l
> ZfgAn0SvFyhrDyduhyYs7/SWVAb1dIg/
> =Qf+E
> -----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
