| Message ID | 20100822000546.GA22227@bromo.med.uc.edu |
|---|---|
| State | New |
| Headers | show |
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. > 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).
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).
On Aug 21, 2010, at 5:05 PM, Jack Howarth wrote: > On Sat, Aug 21, 2010 at 03:38:37PM -0700, Mike Stump wrote: >> On Aug 20, 2010, at 8:53 PM, Jack Howarth wrote: >>> The attached patch depreciates darwin7 and earlier. These darwin releases >>> only support stabs and haven't been properly maintained in quite some >>> time. >> >> ? Last time I ran darwin7 it worked just fine and it wasn't that long ago. I don't believe it works any worse today does it? In fact, last time I ran darwin6 it worked just fine as I recall. >> >>> Okay for gcc trunk after adding any required documentation changes to the patch? >> >> I don't think darwin1 - darwin5 are worth saving anymore, and don't care if they go, so that part of the patch would be fine. darwin6 worked, last I knew and doesn't pose much a burden. Likewise I don't think keeping support for 7 in the tree is burdensome, indeed the size of the below patch is rather small. If someone accidentally breaks support for 6 or 7, it usually is trivial to get it to work again. So, for example, the recent patches to rip out -lm, those should be inside a target os conditional of 10.4 or later. If that were missing, should be trivial to add it. I just don't see the value in removing what amounts to a single line to support darwin7. >> > > Mike, > How exactly do you propose we make the use of remove-outfile conditional? > Adding... > > Index: gcc/config/darwin.h > =================================================================== > --- gcc/config/darwin.h (revision 163449) > +++ gcc/config/darwin.h (working copy) > @@ -303,9 +303,17 @@ > so put a * after their names so all of them get passed. */ > #define LINK_SPEC \ > "%{static}%{!static:-dynamic} \ > +#if __MACH__ && (__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1040) > + %{!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) \ > +#endif > %{fgnu-runtime: %{static|static-libgcc: \ > %:replace-outfile(-lobjc libobjc-gnu.a%s); \ > :%:replace-outfile(-lobjc -lobjc-gnu ) } }\ Oh, worst case scenario, something like: darwin.h: > #define LINK_SPEC \ > "%{static}%{!static:-dynamic} \ > + %{!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) \ > %{fgnu-runtime: %{static|static-libgcc: \ > %:replace-outfile(-lobjc libobjc-gnu.a%s); \ > :%:replace-outfile(-lobjc -lobjc-gnu ) } }\ and #undef LINK_SPEC > #define LINK_SPEC \ > "%{static}%{!static:-dynamic} \ > %{fgnu-runtime: %{static|static-libgcc: \ > %:replace-outfile(-lobjc libobjc-gnu.a%s); \ > :%:replace-outfile(-lobjc -lobjc-gnu ) } }\ in darwin9.h. On newer system, remove-outfile, and on older systems, it removes. Kinda simple and straightforward. Anyway, this doesn't work well with SDKs, but having it work without SDK support is better than having it not work. If someone cared more, they could enhance version-compare to work better...
On Sat, Aug 21, 2010 at 07:51:43PM -0700, Mike Stump wrote: > > in darwin9.h. On newer system, remove-outfile, and on older systems, it removes. Kinda simple and straightforward. Anyway, this doesn't work well with SDKs, but having it work without SDK support is better than having it not work. If someone cared more, they could enhance version-compare to work better... Mike, I'm still confused about the potential SDK breakage. Looking at... http://books.google.com/books?id=09xjqE4nvqAC&pg=PA218&lpg=PA218&dq=10.3+libSystem+symlinks&source=bl&ots=e0IbeKedng&sig=iuu7LIX63QxWYuGvSKWTBhA6iIk&hl=en&ei=T5lwTODKLYT78AagsrG8Cw&sa=X&oi=book_result&ct=result&resnum=7&ved=0CCoQ6AEwBg#v=onepage&q&f=false for Panther, I see libSystem described as containing libc, libinfo, libkvm, libpoll, libpthreadm, librpcsvc, libdbm and libdl which are provided as symlinks to libSystem (page 217). So only building for the 10.2 (darwin6) SDK would be an issue. Putting darwin6 out of its misery would solve that issue and frankly building for the 10.2 SDK under 10.3 in the early 21st century is rather a geek trick. Jack
On Sat, Aug 21, 2010 at 11:37:13PM -0400, Jack Howarth wrote: > On Sat, Aug 21, 2010 at 07:51:43PM -0700, Mike Stump wrote: > > > > in darwin9.h. On newer system, remove-outfile, and on older systems, it removes. Kinda simple and straightforward. Anyway, this doesn't work well with SDKs, but having it work without SDK support is better than having it not work. If someone cared more, they could enhance version-compare to work better... > > Mike, > I'm still confused about the potential SDK breakage. Looking at... > > http://books.google.com/books?id=09xjqE4nvqAC&pg=PA218&lpg=PA218&dq=10.3+libSystem+symlinks&source=bl&ots=e0IbeKedng&sig=iuu7LIX63QxWYuGvSKWTBhA6iIk&hl=en&ei=T5lwTODKLYT78AagsrG8Cw&sa=X&oi=book_result&ct=result&resnum=7&ved=0CCoQ6AEwBg#v=onepage&q&f=false > > for Panther, I see libSystem described as containing libc, libinfo, libkvm, libpoll, libpthreadm, librpcsvc, > libdbm and libdl which are provided as symlinks to libSystem (page 217). So only building for the > 10.2 (darwin6) SDK would be an issue. Putting darwin6 out of its misery would solve that issue and frankly > building for the 10.2 SDK under 10.3 in the early 21st century is rather a geek trick. > Jack Mike, Wrong URL... http://books.google.com/books?id=itAU-HCoD7EC&pg=PA141&lpg=PA141&dq=Panther+libSystem&source=bl&ots=BANVJbNcCl&sig=6MdcPGKQRYxFKhlU4s7SShxMpCc&hl=en&ei=yptwTKO-OMOC8gbkivnkCw&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBIQ6AEwAA#v=onepage&q=Panther%20libSystem&f=false Jack
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 Sat, Aug 21, 2010 at 08:40:55PM -0700, Mike Stump wrote: > > 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. Mike, The only problem is that the actual definition of LINK_SPEC is rather large so we will be duplicating a signficant chunk of code. Perhaps adding a variant of the version_compare spec function that can call another spec function would be the cleanest approach. Jack
On Aug 21, 2010, at 8:52 PM, Jack Howarth wrote:
> The only problem is that the actual definition of LINK_SPEC is rather large
Yeah, programming by #define isn't ideal, but that's the current model gcc uses for so many things. As we move to C++, maybe someone might replace it with something cleaner/better. Anyway, I don't see a problem cutting and pasting in this instance. One could try their hand at factoring it out it they have a better solution.
On 22 Aug 2010, at 17:17, Mike Stump wrote: > On Aug 21, 2010, at 8:52 PM, Jack Howarth wrote: >> The only problem is that the actual definition of LINK_SPEC is >> rather large > > Yeah, programming by #define isn't ideal, but that's the current > model gcc uses for so many things. As we move to C++, maybe someone > might replace it with something cleaner/better. Anyway, I don't see > a problem cutting and pasting in this instance. One could try their > hand at factoring it out it they have a better solution. it can most likely be factored, as I did recently with LINK_COMMAND_SPEC, I'll take a shufftie at darwin7 on an old machine sometime.. ... in the meantime I wouldn't spend much effort on it .. cheers, Iain
On Sun, Aug 22, 2010 at 09:17:53AM -0700, Mike Stump wrote: > On Aug 21, 2010, at 8:52 PM, Jack Howarth wrote: > > The only problem is that the actual definition of LINK_SPEC is rather large > > Yeah, programming by #define isn't ideal, but that's the current model gcc uses for so many things. As we move to C++, maybe someone might replace it with something cleaner/better. Anyway, I don't see a problem cutting and pasting in this instance. One could try their hand at factoring it out it they have a better solution. Mike Per my subsequent message, the duplication of LINK_SPEC really doesn't solve the issue. It effectively hard codes the remove-outfile usage for a given darwin release to the default SDK of that release. This isn't really enough granularity. Only a proper version-compare-specfunc, which can call remove-outfile, would solve this issue such that remove-outfile is applied appropriately depending on the current SDK in use. It may be best to just leave the list of linkages pruned by remove-outfile to just those that impact the FSF gcc build itself (-ldl, -lm and -lpthread) and adjust the obsolete darwin targets to pass -lmx if needed. Jack ps I have always been puzzled as to why version-compare was added without the obvious companion function to handled passing spec functions rather than assignments.
Index: gcc/config/darwin.h =================================================================== --- gcc/config/darwin.h (revision 163449) +++ gcc/config/darwin.h (working copy) @@ -303,9 +303,17 @@ so put a * after their names so all of them get passed. */ #define LINK_SPEC \ "%{static}%{!static:-dynamic} \ +#if __MACH__ && (__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1040) + %{!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) \ +#endif %{fgnu-runtime: %{static|static-libgcc: \ %:replace-outfile(-lobjc libobjc-gnu.a%s); \ :%:replace-outfile(-lobjc -lobjc-gnu ) } }\