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 fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker


On Nov 8, 2016, at 8:31 AM, Iain Sandoe <iain_sandoe@mentor.com> wrote:
> 
>> On 8 Nov 2016, at 08:18, Mike Stump <mikestump@comcast.net> wrote:
>> 
>> On Nov 7, 2016, at 6:33 PM, Iain Sandoe <iain_sandoe@mentor.com> wrote:
>>> 
>>> 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).
>> 
>> A traditional canadian can run the host linker for the target on the build machine with --version (or whatever flag) and capture the version number.  I don't know what setup you have engineered for, since you didn't say.  First question, can you run the host linker for the target on the build machine?  If so, you can directly capture the output.  The next question is, is it the same version as the version that would be used on the host?
> 
> I suppose that one could demand that - and require a build thus.

It is a statement of what we have today, already a requirement.  Sorry you missed the memo.  The problem is software usually changes through time, and the old software can't acquire the features of the new software, so to get those you need the new software, not the old.  If there are no new features, in some rare cases, one might be able to use a range of versions, but the range that would work, would be the range that an expert tested and documented as working.  Absent that, it generally speaking isn't that safe to assume it is safe.  And, when it isn't safe and doesn't work, well, it just doesn't work.  Thinking it will, or hoping it will, won't make it so.  If those features were able to be pushed back into the old software, you're merely reinvent a source distribution of the the new software in different clothes, poorly.

> If we demand that the same version linker is used for all, then perhaps that could work.

More that that, it will just work; by design; and in the cases where that isn't the case, those are bugs that can be worked around or fixed.

> It seems likely that we’ll end up with mis-configures and stuff hard to support with non-expert build folks.

Nope.  Indeed, remember the only reason why we do this, is to make the phrase, it just works, true.  If you are imagining anything else, the flaw is mine in communicating why we do what it is that we do.

>>> 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").
>> 
>> Package managers exist to solve that problem nicely, if someone wants a trivial solution.  They have the ability to scoop up binaries and just copy them onto a machine, solving hard chicken/egg problems.  Other possibilities are scripts that setup everything and release the scripts.
> 
> yes, I’m working on at least the latter (don’t have time to become a package manager).

The thing is, the build scripts have already been written, we're just 'making them work'.

>>> am I missing a point here?
>> 
>> The answer to the two questions above.  The answer to the question, what specific question do you want answered, and what is available to the build machine, specifically to answer that question?
>> 
>> Also, you deflect on the os version to linker version number, but you never said what didn't actually work.  What specifically doesn't work?  This method is trivial and the mapping is direct and expressible in a few lines per version supported.  I still maintain that the only limitation is you must choose exactly 1 version per config triplet; I don't see that as a problem.  If it were, I didn't see you explain the problem.  Even if it is, that problem is solved after the general problem that nothing works today.  By having at least _a_ mapping, you generally solve the problem for most people, most of the time.
> 
> It *requires* that one configures arch-darwinNN .. and doesn’t allow for arch-darwin (to mean anything other than  build=host=target)

No, that's a misunderstanding of my position.  Use the filter, does this mean 'it just works', or not.  If not, then that's not what I mean.

> If we can engineer that a suitable ld64 can be run at configuration time so that the version can be discovered automatically, I’m with you 100% - but the scenarios put forward seem very complex for typical folks,

A linker is a requirement of a build, this isn't supposed to be opaque.  A linker means you can run it.  Again, not exactly rocket science.  What would be rocket science is doing a build with no linker and no compiler, and no internet connection.  Further, this isn't a new requirement, it's been around for a while.

> What would you prefer to replace this patch with?

  ld_vers=$($ld -v | sed -n 's/.*ld64-//p')

sorry if that isn't obvious.

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