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
------------------------------------------------------------------------------
_______________________________________________
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
