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