This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Depreciate darwin[0-7]


On Sat, Aug 21, 2010 at 07:21:27PM -0700, Mike Stump wrote:
> On Aug 21, 2010, at 5:05 PM, Jack Howarth wrote:
> > How exactly do you propose we make the use of remove-outfile conditional?
> 
> The standard way:
> 
> :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4)
> 
> For example means 10.4.x....
> 
> If you want just 10.5 or later:
> 
> %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5) 
> 
> is a typical line that will do this.  For -lm, the dynamic check is better than the static check, as then SDKs work just fine.
> 
> > Also, the existing version-compare() is insufficient because it only
> > allows assignments and not the nested calling of another spec function.
> 
> Ah, but we can unconditionally remove -lm, that's not such a big deal.  We just _must_ add it back to the link line, at the proper spot, if we're dealing with deployment before x.  It was the unconditional removal of -lm from the link line that was bad.  Of course, better would be to extend out support in version compare so that is it logically composable, so that one can just wrap the entire thing inside a version compare.

Mike,
   Isn't libm effectively added with -lmx by...

#undef  LIB_SPEC
#define LIB_SPEC "%{!static:\
  %:version-compare(!< 10.3 mmacosx-version-min= -lmx)\
  -lSystem}"

in gcc/config/rs6000/darwin7.h? The remove-output on -lm won't touch that. This just
leaves darwin6 which seems absurdly old to try to support. We are moving into the
time frame when Xcode releases were insufficient and a separate odcctools package
was required. I haven't heard of any users building gcc on darwin6 for quite some time.
              Jack

> 
> > Also do we really know that darwin6 and darwin7 are functional (ie
> > reasonably pass the testsuite)?
> 
> Yes.  All the breakage would be fairly recent and only should involved a small number of issues.
> 
> > It is unclear to me how libgcc_ext can properly function on systems that predate versioned libgcc releases.  The entire mechanism of selecting symbols in libgcc_ext is based on support for versioned libgcc stubs.
> 
> As for that, yes, that support required a minimum deployment target.
> 
> We talked about this when the _ext work went in; on older systems, one has to use stub libraries (or real libraries).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]