This is the mail archive of the 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 08:40:55PM -0700, Mike Stump wrote:
> On Aug 21, 2010, at 7:50 PM, Jack Howarth wrote:
> > 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.
> > 
> >  Isn't libm effectively added with -lmx by...
> Oh, I was just using it as an example, I glanced at the entire list of removed libraries, and realized that we could hack in -lm (-lmx), if it were just that one library, given all the others, it would be better to not remove them.
> > This just leaves darwin6 which seems absurdly old to try to support.
> Why?  In general, as work goes in that can't work on darwin(n-1), it also can't work on darwin6.  You get support for darwin6 for free.  It isn't unreasonable to keep n-1 working, and once you do that, then support for all past systems is usually trivial.  This is by design.
> > time frame when Xcode releases were insufficient and a separate odcctools package was required.
> Those people still building on those systems already have that package, or can download it as pointed out the in the documentation.  That hasn't changes in years.
> > I haven't heard of any users building gcc on darwin6 for quite some time.
> Me either, and I've not thought about it in quite some time either.
> So, for example, the outfile stuff, if it is only appropriate for darwin6 or later, it can go into darwin.h, if only appropriate for darwin7, darwin7.h, darwin8 or later, darwin8.h, darwin9 or later, darwin9.h, darwin10 or later, darwin10.h....  Now, if the work went into darwin.h instead of darwin10.h, that is a logical two line fix.

   On reflection, it appears that no solution will be viable except for the
proper one of adding a version-compare-specfunc spec function which can call
other spec functions within itself. I considered other alternatives like...

Index: config/darwin.h
--- config/darwin.h	(revision 163460)
+++ config/darwin.h	(working copy)
@@ -301,11 +301,8 @@
    'Z' and 'no' prefixes). Note that options taking arguments may appear
    multiple times on a command line with different arguments each time,
    so put a * after their names so all of them get passed.  */
-#define LINK_SPEC  \
+#define CORE_LINK_SPEC  \
   "%{static}%{!static:-dynamic} \
-   %:remove-outfile(-ldl) \
-   %:remove-outfile(-lm) \
-   %:remove-outfile(-lpthread) \
    %{fgnu-runtime: %{static|static-libgcc: \
                      %:replace-outfile(-lobjc libobjc-gnu.a%s); \
                     :%:replace-outfile(-lobjc -lobjc-gnu ) } }\
@@ -386,6 +383,7 @@
    %{whatsloaded} %{dylinker_install_name*} \
    %{dylinker} %{Mach} "
 /* Machine dependent libraries.  */
Index: config/darwin9.h
--- config/darwin9.h	(revision 163460)
+++ config/darwin9.h	(working copy)
@@ -33,6 +33,20 @@
 /* libSystem contains unwind information for signal frames.  */
+#undef LINK_SPEC
+#define LINK_SPEC \
+   "%{!nodefaultlibs: %:remove-outfile(-lc) } \
+   %:remove-outfile(-ldbm) \
+   %:remove-outfile(-ldl) \
+   %:remove-outfile(-linfo) \
+   %:remove-outfile(-lm) \
+   %:remove-outfile(-lpoll) \
+   %:remove-outfile(-lproc) \
+   %:remove-outfile(-lpthread) \
+   %:remove-outfile(-lrpcsvc) \
   do {									\

but this is only a partial solution. The decision on using remove-outfile needs
to be applied at run time based on the SDK in use.
   I suspect we should be okay with the limited (-ldl, -lm and -lpthread) pruning
as long as the obsolete darwins are passed -lmx. That set of remove-outfile calls
is sufficient to resolve the linkage order issues within FSF gcc build itself.

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