> On 7 Nov 2016, at 13:56, Mike Stump <mikest...@comcast.net> wrote: > > On Nov 7, 2016, at 9:59 AM, Iain Sandoe <iain_san...@mentor.com> wrote: >> >>> On 7 Nov 2016, at 09:51, Mike Stump <mikest...@comcast.net> wrote: >>> >>> [ possible dup ] >>> >>>> Begin forwarded message: >>>> >>>> From: Mike Stump <m...@mrs.kithrup.com> >>>> Subject: Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 >>>> to be detected as Darwin's linker >>>> Date: November 7, 2016 at 9:48:53 AM PST >>>> To: Iain Sandoe <iain_san...@mentor.com> >>>> Cc: GCC Patches <gcc-patches@gcc.gnu.org>, Jeff Law <l...@redhat.com> >>>> >>>> On Nov 6, 2016, at 11:39 AM, Iain Sandoe <iain_san...@mentor.com> wrote: >>>>> This is an initial patch in a series that converts Darwin's configury to >>>>> detect ld64 features, rather than the current process of hard-coding them >>>>> on target system version. >>>> >>>> So, I really do hate to ask, but does this have to be a config option? >>>> Normally, we'd just have configure examine things by itself. For canadian >>>> crosses, there should be enough state present to key off of directly, >>>> specially if they are wired up to work. >>>> >>>> I've rather have the thing that doesn't just work without that config >>>> flag, just work. I'd like to think I can figure how how to make it just >>>> work, if given an idea of what doesn't actually work. >>>> >>>> Essentially, you do the operation that doesn't work, detect it failed to >>>> work, then the you know it didn't work. >> >> Well, if you can run the tool, that’s fine - I wanted to cover the base >> where we have a native or canadian that’s using a newer ld64 than is >> installed by the ‘last available xcode’ on a given platform - which is the >> common case (since the older versions of ld64 in particular don’t really >> support the features we want, they def. won’t support building LLVM for ex.). >> >> I am *really really* trying to get away from the assumption that darwinNN >> implies some ld64 capability - because that’s just wrong, really - makes way >> too many assuptions. I also want to get to the “end game” that we just >> configure *-*-darwin and use the cross-capability of the toolchain (we’re a >> ways away from that upstream, but my local patch set acheives it at least >> for 5.4 and 6.2). >> >> It’s true that adding configure options is not #1 choice in life - but I >> think darwin is getting to the stage where there are too many choices to >> cover without. >> >> Open to alternate suggestions, of course > > But, you didn't actually tell me the question that you're interested in. It > is that question that I'm curious about.
a) right now, we need to know the target linker version - while it’s not impossible to try and conjure up some test to see if a linker we can run supports coalesced sections or not, the configury code and complexity needed to support that would exceed what I’m proposing at present (and still would not cover the native and canadian cases). - IMO it’s reasonable to decide on coalesced section availability based on the linker version and is at least correct (where deciding on the basis of system revision is wishful thinking at best). I’m not debating the various solutions in your reply to Jeff - but honestly I wonder how many of them are realistically in reach of the typical end-user (I have done most of them at one stage or another, but I wonder how many would be stopped dead by “first find and build ld64, which itself needs a c++11 compiler and BTW needs you to build libLTO.dylib .. which needs you to build at least LLVM itself"). b) Given the speed of various older hardware, it’s an objective to get to the stage where we can build reliable native crosses (it seems that there are also people trying to do canadian - despite the trickiness). c) it’s a high priority on my list to make it possible for Linux folks to be able to build a Darwin cross toolchain, I think that will help a lot with triage of issues In short, I expect more use of cross and native crosses in the future… .. so: case 1. self-hosted build=host=target, ld64 = xcode whatever - no problem; we query live. case 2. build != host but build arch == host arch- well, sometimes we can run the host tools (I’ve put that in my patch). case 3. build != host, build arch != host arch .. I don’t believe there’s any more concise way of expressing the necessary data than passing the linker version to configure (there’s really no place one can go and look for its capability). So - I agree that there are lots of possible solutions, the question is are there any that are less configury / lower maintenance (and accessible to our users)? am I missing a point here? Iain
