Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Mike Stump]

On Nov 18, 2016, at 3:13 AM, Iain Sandoe  wrote:
> 
> Thanks, at least I’m not going completely crazy ;-)

I'll just note for completeness that Jeff also couldn't explain a failure of 
your latest patch.  If you run into one, let me know.

> OK now for trunk?

Ok.

> open branches?

Ok.

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Iain Sandoe]

> On 17 Nov 2016, at 21:19, Jeff Law  wrote:
> 
> On 11/08/2016 05:49 PM, Iain Sandoe wrote:
>> 
>>> On 8 Nov 2016, at 13:39, Mike Stump  wrote:
>>> 
>>> On Nov 8, 2016, at 1:05 PM, Iain Sandoe 
>>> wrote:
 
 Simple for the simple case is already part of my patch, but
 capability for the expert and non-simple case is also present,
>>> 
>>> I'm trying to ask a specific question, what does the patch allow
>>> that can't be done otherwise?  Kinda a trivial question, and I
>>> don't see any answer.
>>> 
>>> I'm not looking for, it allows it to work, or it makes the expert
>>> case work.  I'm look for the specific question, and the specific
>>> information you want, and why ld -v doesn't get it.
>> 
>> ld -v gets it when you can execute ld. It doesn’t get it when the
>> $host ld is not executable on $build.
> Exactly!
> 
>> Providing the option to give the version allows that without
>> requiring the complexity of other (possibly valid) solutions.  If you
>> know that you’re building (my patched) ld64-253.9 for powerpc-darwin9
>> (crossed from x86-64-darwin14) it’s easy, just put —with-ld64=253.9
>> ..
>> 
>> I think we’ve debated this enough - I’m OK with keeping my extra
>> facility locally and will resubmit the patch with it removed in due
>> course, Iain
> Your call. But ISTM the ability to specify the linker version or even better, 
> its behaviour is a notable improvement for these crosses.

Thanks, at least I’m not going completely crazy ;-)

However, I’d already revised the patch to take the approach Mike wanted, and 
thus didn’t add the documentation that Joseph noted was missing.  It takes 
quite a while to re-test this across the Darwin patch, so I’m going to put 
forward the amended patch (as Mike wanted it) and we can discuss ways to deal 
with native and Canadian crosses later.

FWIW, it’s possible (but rather kludgy) with the attached patch to override 
gcc_gc_ld64_version on the make line to build a native/Canadian cross with a 
“non-standard” ld64 version (I did at least build a native X powerpc-darwin9 on 
x86_64-darwin14 which was not a brick).

OK now for trunk?
open branches?
Iain

gcc/
* configure.ac (with-ld64): New var, set for Darwin, set on
detection of ld64, gcc_cv_ld64_export_dynamic: New, New test.
* darwin.h: Use LD64_HAS_DYNAMIC export. DEF_LD64: New, define.
* darwin10.h(DEF_LD64): Update for this target version.
* darwin12.h(LINK_GCC_C_SEQUENCE_SPEC): Remove rdynamic test.
(DEF_LD64): Update for this target version.




PR71767-part2-revised.patch
Description: Binary data

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Jeff Law]

On 11/08/2016 05:49 PM, Iain Sandoe wrote:



On 8 Nov 2016, at 13:39, Mike Stump  wrote:

On Nov 8, 2016, at 1:05 PM, Iain Sandoe 
wrote:


Simple for the simple case is already part of my patch, but
capability for the expert and non-simple case is also present,


I'm trying to ask a specific question, what does the patch allow
that can't be done otherwise?  Kinda a trivial question, and I
don't see any answer.

I'm not looking for, it allows it to work, or it makes the expert
case work.  I'm look for the specific question, and the specific
information you want, and why ld -v doesn't get it.


ld -v gets it when you can execute ld. It doesn’t get it when the
$host ld is not executable on $build.

Exactly!


Providing the option to give the version allows that without
requiring the complexity of other (possibly valid) solutions.  If you
know that you’re building (my patched) ld64-253.9 for powerpc-darwin9
(crossed from x86-64-darwin14) it’s easy, just put —with-ld64=253.9
..

I think we’ve debated this enough - I’m OK with keeping my extra
facility locally and will resubmit the patch with it removed in due
course, Iain
Your call. But ISTM the ability to specify the linker version or even 
better, its behaviour is a notable improvement for these crosses.


jeff

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Iain Sandoe]

> On 8 Nov 2016, at 13:39, Mike Stump  wrote:
> 
> On Nov 8, 2016, at 1:05 PM, Iain Sandoe  wrote:
>> 
>> Simple for the simple case is already part of my patch, but capability for 
>> the expert and non-simple case is also present,
> 
> I'm trying to ask a specific question, what does the patch allow that can't 
> be done otherwise?  Kinda a trivial question, and I don't see any answer.
> 
> I'm not looking for, it allows it to work, or it makes the expert case work.  
> I'm look for the specific question, and the specific information you want, 
> and why ld -v doesn't get it.

ld -v gets it when you can execute ld.
It doesn’t get it when the $host ld is not executable on $build.
Providing the option to give the version allows that without requiring the 
complexity of other (possibly valid) solutions.  If you know that you’re 
building (my patched) ld64-253.9 for powerpc-darwin9 (crossed from 
x86-64-darwin14) it’s easy, just put —with-ld64=253.9 .. 

I think we’ve debated this enough - I’m OK with keeping my extra facility 
locally and will resubmit the patch with it removed in due course,
Iain

> 
> For example, there is a host you are thinking of, there is a  build system 
> you are think of, there is a target you are thinking of.  There is a set of 
> software you have, likely a particular Xcode release.  There are binaries 
> that you might have built up for it, there might be headers you grab from 
> some place, libraries or SDKs from another place.  This might be done for 
> quick debugging a darwin problem on a linux host, but without the full 
> ability to generate a tool chain, it might be to support a full tool chain.
> 
> I want it to work, without specifying the it, doesn't let me see what problem 
> you are solving.
> 
> I read through the PR listed, and it seems to just list a typical 
> x86_64-apple-darwin12.6.0 native port.  That really isn't rocket science is 
> it?  I mean, we see the wanting from the build tools directly.  So, the 
> change isn't to support that, is it?
> 

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Mike Stump]

On Nov 8, 2016, at 1:05 PM, Iain Sandoe  wrote:
> 
> Simple for the simple case is already part of my patch, but capability for 
> the expert and non-simple case is also present,

I'm trying to ask a specific question, what does the patch allow that can't be 
done otherwise?  Kinda a trivial question, and I don't see any answer.

I'm not looking for, it allows it to work, or it makes the expert case work.  
I'm look for the specific question, and the specific information you want, and 
why ld -v doesn't get it.

For example, there is a host you are thinking of, there is a  build system you 
are think of, there is a target you are thinking of.  There is a set of 
software you have, likely a particular Xcode release.  There are binaries that 
you might have built up for it, there might be headers you grab from some 
place, libraries or SDKs from another place.  This might be done for quick 
debugging a darwin problem on a linux host, but without the full ability to 
generate a tool chain, it might be to support a full tool chain.

I want it to work, without specifying the it, doesn't let me see what problem 
you are solving.

I read through the PR listed, and it seems to just list a typical 
x86_64-apple-darwin12.6.0 native port.  That really isn't rocket science is it? 
 I mean, we see the wanting from the build tools directly.  So, the change 
isn't to support that, is it?

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Iain Sandoe]

> On 8 Nov 2016, at 10:27, Mike Stump  wrote:
> 
> On Nov 8, 2016, at 8:31 AM, Iain Sandoe  wrote:
>> 
>>> On 8 Nov 2016, at 08:18, Mike Stump  wrote:
>>> 
>>> On Nov 7, 2016, at 6:33 PM, Iain Sandoe  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% - 

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Mike Stump]

On Nov 8, 2016, at 8:31 AM, Iain Sandoe  wrote:
> 
>> On 8 Nov 2016, at 08:18, Mike Stump  wrote:
>> 
>> On Nov 7, 2016, at 6:33 PM, Iain Sandoe  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 

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Mike Stump]

On Nov 7, 2016, at 9:15 PM, Iain Sandoe  wrote:
> 
> this is pretty “black belt” stuff - I don’t see most of our users wanting to 
> dive this deeply … 

No, not really.  It is true that newlib and GNU sim needs a few more lines of 
code, but that lines are written for linux and most other posix style systems 
already and can be contributed.  Once they are in, I used a vanishingly small 
change to configure, to put $RUN on the front of some command lines.  RUN="" 
for natives, and RUN=triple-run for selecting the GNU simulator.  In later 
builds, I didn't even do that, I do things like:

  CC=triplet-run\ $install/bin/triplet-gcc CXX=cyclops2e-run\ 
$install/bin/triplet-g++ ../newlib/configure --target=triplet --host=triplet2 
--prefix=$install
  make -j$N CC_FOR_TARGET="triplet-run $install/bin/triplet-gcc"
  make -j$N CC_FOR_TARGET="triplet-run $install/bin/triplet-gcc" install

an an example on how to configure and build up newlib.  Works just fine as is.  
gcc is the same, and just as easy.  For cross natives, don't expect it can be 
much easier, unless I added 2 lines of code into configure that tacked in the 
$RUN by itself.  If that were done, it's literally just a couple of lines, and 
then presto, it is the standard documented build methodology as it exists today.

>> Also, for darwin, in some cases, we can actually run the target or host 
>> programs on the build machine directly.
> 
> I have that (at least weakly) in the patch posted

If you can do that, then you can run:
$ /usr/bin/ld -v
@(#)PROGRAM:ld  PROJECT:ld64-274.1
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h 
armv6m armv7k armv7m armv7em (tvOS)
LTO support using: LLVM version 8.0.0, (clang-800.0.42.1)
TAPI support using: Apple TAPI version 1.30

$ ld -v
@(#)PROGRAM:ld  PROJECT:ld64-264.3.102
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m 
armv7k arm64 (tvOS)
LTO support using: LLVM version 3.8.1

and get a flavor of ld directly, no?  Isn't the version number you want 
something like 274.1 and 264.3.102?  I can write the sed to get that if you 
want.

  $ld -v

is the program I used to get the above, and I'm assuming that you can figure 
out how to set $ld.  This also works for natives, just as well, as can be seen 
above, as those two are the usual native commands.`

> .. and produce the situation where we can never have a c++11 compiler on 
> powerpc-darwin9,

No, I never said that and never would accept that limitation.  If someone 
wanted to contribute patches to do that, I'd approve them.  If they wanted help 
and advice on how to make it happen, I'm there.  You are imagining limitations 
that don't exist.  I have envisioned, a world where everything just works and 
getting there is trivial.  Just takes a few well placed patches.

> because the “required ld64” doesn’t support it (OK. maybe we don’t care about 
> that) but supposing we can now have symbol aliasses with modern ld64 (I think 
> we can) - would we want to prevent a 10.6 from using that?

Nope.

> So, I am strongly against the situation where we fix the capability of the 
> toolchain on some assumption of externally-available tools predicated on the 
> system revision.

We aren't.  It is only a notion of what the meaning of a particular configure 
line is.  If you want it to mean,  blow chunks, then you are wrong for that 
choice.  If you want it to mean, it just works, then we are on the same page.  
So, my question to you is, what happen when you don't give the linker version 
on the configure line?  Does it blow chunks or just work?  If it just works, 
why would you want to provide the flag?  If it blow chunks, then you now 
understand completely why I oppose that.

> The intent of my patch is to move away from this to a situation where we use 
> configuration tests to determine the capability from the tools [when we can 
> run them] and on the basis of their version(s) when we are configuring in a 
> cross scenario.

No, it is backward progress.  You would require infinite argument lists for 
infinite complexity and infinite ways for breakage given how hard it is to 
formulate those arguments.  This is against the autoconf/configure spirit.  
That spirit is no infinite argument list for infinite complexity, and 
everything just works.

When I say my cross native build is:

   ../newlib/configure --target=triplet --prefix=$install
  make && make install

Do you see why it must be right?  There just is no possibility that it is 
wrong.  Further, it is this today, tomorrow, yesterday and next century, by 
design.  I resist the configure flag because you said you can run ld, and as 
I've shown, -v will get us the information I think you seek, directly, no 
configure flag.  You can not said that you can't run it, and you have not said 
why the information you seek isn't in the output found.

> Actually, there’s a bunch of configury in GCC that picks up the version of 
> binutils components 

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Iain Sandoe]

> On 8 Nov 2016, at 08:18, Mike Stump  wrote:
> 
> On Nov 7, 2016, at 6:33 PM, Iain Sandoe  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.

So I build x86_64-darwin14 X powerpc-darwin9
and then a native host  build = x86_64-darwin14 host = target = powerpc-darwin9
If we demand that the same version linker is used for all, then perhaps that 
could work.

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

>> 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).
> 
>> 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) - but really we 
should be able to build arch-darwin wit config flags including 
-mmacosx-version-min= to be deployable on any darwin > than the specified min.  
I actually do this for day job toolchains, it’s not purely hypothetical.  Since 
darwin toolchains are all supposed to be “just works” cross ones.

> For example, if you target 10.0, there is no new features from an Xcode that 
> was from 10.11.6 timeframe.  The only way to get those features, would be to 
> run a newer ld64, and, if you are doing that, then you likely have enough 
> sources to run ld directly.  And if you are running it directly, then you can 
> just ask it what version it is.

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,

What would you prefer to replace this patch with?
Iain

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Mike Stump]

On Nov 7, 2016, at 6:33 PM, Iain Sandoe  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’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.

> 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.

For example, if you target 10.0, there is no new features from an Xcode that 
was from 10.11.6 timeframe.  The only way to get those features, would be to 
run a newer ld64, and, if you are doing that, then you likely have enough 
sources to run ld directly.  And if you are running it directly, then you can 
just ask it what version it is.

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Iain Sandoe]

> On 7 Nov 2016, at 13:53, Mike Stump  wrote:
> 
> On Nov 7, 2016, at 10:40 AM, Jeff Law  wrote:
>> 
>> On 11/07/2016 10:48 AM, Mike Stump wrote:
>>> On Nov 6, 2016, at 11:39 AM, Iain Sandoe  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.
>>> 
>> But how is that supposed to work in a cross environment when he can't 
>> directly query the linker's behavior?
> 
> :-)  So, the two most obvious solutions would be the programs that need to 
> exist for a build, are portable and ported to run on a system that the build 
> can use, or one can have a forwarding stub from a system the build uses to 
> machine that can host the software that is less portable.  I've done both 
> before, both work fine.  Portable software can also include things like 
> simulators to run software under simulation on the local machine (or on a 
> machine the forwarding stub links to).  I've done that as well.  For example, 
> I've done native bootstraps of gcc on my non-bootstrappable cross compiler by 
> running everything under GNU sim for bootstrap and enhancing the GNU sim 
> stubs to include a few more system calls that bootstrap uses.  :-) read/write 
> already work, once just needs readdir and a few others.

this is pretty “black belt” stuff - I don’t see most of our users wanting to 
dive this deeply … 
> 
> Also, for darwin, in some cases, we can actually run the target or host 
> programs on the build machine directly.

I have that (at least weakly) in the patch posted - reluctant to add more 
smarts to make it cover more cases unless it’s proven useful.

> 
>> In an ideal world we could trivially query the linker's behavior prior to 
>> invocation.  But we don't have that kind of infrastructure in place.
> 
> There are cases that just work.  If you have a forwarding stub for the cross, 
> then you can just run it as usual.  If you have a BINFMT style simulator on 
> the local machine, again, you can just run it.  And on darwin, there are 
> cases where you can run target and/or host programs on the build machine 
> directly.
> 
> For darwin, I can't tell if he wants the runtime property of the target 
> system for programs that will be linked on it, or a behavior of the local 
> linker that will do the deed.  For the local linker, that can be queried 
> directly. For the target system, we can know it's behavior by knowing what 
> the target is.  We already know what the target is from the macosxversion 
> flag, which embodies the dynamic linker. Also, for any specific version of 
> macosx, there can have a table of what version of ld64 it has on it, by fiat. 
>  We can say, if you want to target such a system, you should use the latest 
> Xcode that supported that system.  This can reduce complexities and simplify 
> our lives.

.. and produce the situation where we can never have a c++11 compiler on 
powerpc-darwin9, because the “required ld64” doesn’t support it (OK. maybe we 
don’t care about that) but supposing we can now have symbol aliasses with 
modern ld64 (I think we can) - would we want to prevent a 10.6 from using that?

So, I am strongly against the situation where we fix the capability of the 
toolchain on some assumption of externally-available tools predicated on the 
system revision.

The intent of my patch is to move away from this to a situation where we use 
configuration tests to determine the capability from the tools [when we can run 
them] and on the basis of their version(s) when we are configuring in a cross 
scenario.

>> ISTM the way to go is to have a configure test to try and DTRT automatically 
>> for native builds and a flag to set for crosses (or potentially override the 
>> configure test).
> 
> 
> Sure, if it can't be known.
> 
> For example, if you have the target include directory, you don't to have 
> flags for questions that can be answered by the target headers.  Ditto the 
> libraries.  My question is what is the specific question we are asking?  
> Additionally answering things on the basis of version numbers isn't quite in 
> the GNU spirit.  I'm not opposed to it, but, it is slightly better to form 
> the actual question if possible.

Actually, there’s a bunch 

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Iain Sandoe]

> On 7 Nov 2016, at 13:53, Mike Stump  wrote:
> 
> On Nov 7, 2016, at 10:40 AM, Jeff Law  wrote:
>> 
>> On 11/07/2016 10:48 AM, Mike Stump wrote:
>>> On Nov 6, 2016, at 11:39 AM, Iain Sandoe  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.
>>> 
>> But how is that supposed to work in a cross environment when he can't 
>> directly query the linker's behavior?
> 
> :-)  So, the two most obvious solutions would be the programs that need to 
> exist for a build, are portable and ported to run on a system that the build 
> can use, or one can have a forwarding stub from a system the build uses to 
> machine that can host the software that is less portable.  I've done both 
> before, both work fine.  Portable software can also include things like 
> simulators to run software under simulation on the local machine (or on a 
> machine the forwarding stub links to).  I've done that as well.  For example, 
> I've done native bootstraps of gcc on my non-bootstrappable cross compiler by 
> running everything under GNU sim for bootstrap and enhancing the GNU sim 
> stubs to include a few more system calls that bootstrap uses.  :-) read/write 
> already work, once just needs readdir and a few others.

this is pretty “black belt” stuff - I don’t see most of our users wanting to 
dive this deeply … 
> 
> Also, for darwin, in some cases, we can actually run the target or host 
> programs on the build machine directly.

I have that (at least weakly) in the patch posted - reluctant to add more 
smarts to make it cover more cases unless it’s proven useful.

> 
>> In an ideal world we could trivially query the linker's behavior prior to 
>> invocation.  But we don't have that kind of infrastructure in place.
> 
> There are cases that just work.  If you have a forwarding stub for the cross, 
> then you can just run it as usual.  If you have a BINFMT style simulator on 
> the local machine, again, you can just run it.  And on darwin, there are 
> cases where you can run target and/or host programs on the build machine 
> directly.
> 
> For darwin, I can't tell if he wants the runtime property of the target 
> system for programs that will be linked on it, or a behavior of the local 
> linker that will do the deed.  For the local linker, that can be queried 
> directly. For the target system, we can know it's behavior by knowing what 
> the target is.  We already know what the target is from the macosxversion 
> flag, which embodies the dynamic linker. Also, for any specific version of 
> macosx, there can have a table of what version of ld64 it has on it, by fiat. 
>  We can say, if you want to target such a system, you should use the latest 
> Xcode that supported that system.  This can reduce complexities and simplify 
> our lives.

.. and produce the situation where we can never have a c++11 compiler on 
powerpc-darwin9, because the “required ld64” doesn’t support it (OK. maybe we 
don’t care about that) but supposing we can now have symbol aliasses with 
modern ld64 (I think we can) - would we want to prevent a 10.6 from using that?

So, I am strongly against the situation where we fix the capability of the 
toolchain on some assumption of externally-available tools predicated on the 
system revision.

The intent of my patch is to move away from this to a situation where we use 
configuration tests to determine the capability from the tools [when we can run 
them] and on the basis of their version(s) when we are configuring in a cross 
scenario.

>> ISTM the way to go is to have a configure test to try and DTRT automatically 
>> for native builds and a flag to set for crosses (or potentially override the 
>> configure test).
> 
> 
> Sure, if it can't be known.
> 
> For example, if you have the target include directory, you don't to have 
> flags for questions that can be answered by the target headers.  Ditto the 
> libraries.  My question is what is the specific question we are asking?  
> Additionally answering things on the basis of version numbers isn't quite in 
> the GNU spirit.  I'm not opposed to it, but, it is slightly better to form 
> the actual question if possible.

Actually, there’s a bunch 

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Iain Sandoe]

> On 7 Nov 2016, at 13:56, Mike Stump  wrote:
> 
> On Nov 7, 2016, at 9:59 AM, Iain Sandoe  wrote:
>> 
>>> On 7 Nov 2016, at 09:51, Mike Stump  wrote:
>>> 
>>> [ possible dup ]
>>> 
 Begin forwarded message:
 
 From: Mike Stump 
 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 
 Cc: GCC Patches , Jeff Law 
 
 On Nov 6, 2016, at 11:39 AM, Iain Sandoe  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

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Mike Stump]

On Nov 7, 2016, at 9:59 AM, Iain Sandoe  wrote:
> 
>> On 7 Nov 2016, at 09:51, Mike Stump  wrote:
>> 
>> [ possible dup ]
>> 
>>> Begin forwarded message:
>>> 
>>> From: Mike Stump 
>>> 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 
>>> Cc: GCC Patches , Jeff Law 
>>> 
>>> On Nov 6, 2016, at 11:39 AM, Iain Sandoe  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.

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Mike Stump]

On Nov 7, 2016, at 10:40 AM, Jeff Law  wrote:
> 
> On 11/07/2016 10:48 AM, Mike Stump wrote:
>> On Nov 6, 2016, at 11:39 AM, Iain Sandoe  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.
>> 
> But how is that supposed to work in a cross environment when he can't 
> directly query the linker's behavior?

:-)  So, the two most obvious solutions would be the programs that need to 
exist for a build, are portable and ported to run on a system that the build 
can use, or one can have a forwarding stub from a system the build uses to 
machine that can host the software that is less portable.  I've done both 
before, both work fine.  Portable software can also include things like 
simulators to run software under simulation on the local machine (or on a 
machine the forwarding stub links to).  I've done that as well.  For example, 
I've done native bootstraps of gcc on my non-bootstrappable cross compiler by 
running everything under GNU sim for bootstrap and enhancing the GNU sim stubs 
to include a few more system calls that bootstrap uses.  :-)  read/write 
already work, once just needs readdir and a few others.

Also, for darwin, in some cases, we can actually run the target or host 
programs on the build machine directly.

> In an ideal world we could trivially query the linker's behavior prior to 
> invocation.  But we don't have that kind of infrastructure in place.

There are cases that just work.  If you have a forwarding stub for the cross, 
then you can just run it as usual.  If you have a BINFMT style simulator on the 
local machine, again, you can just run it.  And on darwin, there are cases 
where you can run target and/or host programs on the build machine directly.

For darwin, I can't tell if he wants the runtime property of the target system 
for programs that will be linked on it, or a behavior of the local linker that 
will do the deed.  For the local linker, that can be queried directly.  For the 
target system, we can know it's behavior by knowing what the target is.  We 
already know what the target is from the macosxversion flag, which embodies the 
dynamic linker. Also, for any specific version of macosx, there can have a 
table of what version of ld64 it has on it, by fiat.  We can say, if you want 
to target such a system, you should use the latest Xcode that supported that 
system.  This can reduce complexities and simplify our lives.

> ISTM the way to go is to have a configure test to try and DTRT automatically 
> for native builds and a flag to set for crosses (or potentially override the 
> configure test).


Sure, if it can't be known.

For example, if you have the target include directory, you don't to have flags 
for questions that can be answered by the target headers.  Ditto the libraries. 
 My question is what is the specific question we are asking?  Additionally 
answering things on the basis of version numbers isn't quite in the GNU spirit. 
 I'm not opposed to it, but, it is slightly better to form the actual question 
if possible.

In complex canadian cross scenarios, we might well want to grab the source to 
ld64 and compile it up, just as we would any other software for canadian 
environments.

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Jack Howarth]

Iain,
 It certainly looks like you dropped a file here. The proposed
ChangeLog shows...

* config.in: Likewise.

but the previously proposed hunk from...

diff --git a/gcc/config.in b/gcc/config.in
index a736de3..a7ff3ee 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -1934,6 +1934,18 @@
 #endif


+/* Define to 1 if ld64 supports '-export_dynamic'. */
+#ifndef USED_FOR_TARGET
+#undef LD64_HAS_EXPORT_DYNAMIC
+#endif
+
+
+/* Define to ld64 version. */
+#ifndef USED_FOR_TARGET
+#undef LD64_VERSION
+#endif
+
+
 /* Define to the linker option to ignore unused dependencies. */
 #ifndef USED_FOR_TARGET
 #undef LD_AS_NEEDED_OPTION

from PR71767-vs-240230 has gone missing. The current patch still
produces a compiler which triggers warnings of...

warning: section "__textcoal_nt" is deprecated

during the bootstrap until that hunk of the original patch is restored.
Jack

On Sun, Nov 6, 2016 at 2:39 PM, Iain Sandoe  wrote:
> Hi Folks,
>
> 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.
>
> This adds an option --with-ld64[=version] that allows the configurer to 
> specify that the Darwin ld64 linker is in use.  If the version is given then 
> that will be used to determine the capabilities of the linker in native and 
> canadian crosses.  For Darwin targets this flag will default to "on", since 
> such targets require an ld64-compatible linker.
>
> If a DEFAULT_LINKER is set via --with-ld= then this will also be tested to 
> see if it is ld64.
>
> The ld64 version is determined (unless overridden by --with-ld64=version) and 
> this is exported for use in setting a default value for -mtarget-linker 
> (needed for run-time code-gen changes to section choices).
>
> In this initial patch, support for -rdynamic is converted to be detected at 
> config time, or by the ld64 version if that is explicitly given (as an 
> example of usage).
>
> OK for trunk?
> OK for open branches?
> Iain
>
> gcc/
>
> 2016-11-06  Iain Sandoe  
>
>PR target/71767
> * configure.ac (with-ld64): New arg-with.  gcc_ld64_version: New,
> new test.  gcc_cv_ld64_export_dynamic: New, New test.
> * configure: Regenerate.
> * config.in: Likewise.
> * darwin.h: Use LD64_HAS_DYNAMIC export. DEF_LD64: New, define.
> * darwin10.h(DEF_LD64): Update for this target version.
> * darwin12.h(LINK_GCC_C_SEQUENCE_SPEC): Remove rdynamic test.
> (DEF_LD64): Update for this target version.
> ---
>  gcc/config/darwin.h   | 16 ++-
>  gcc/config/darwin10.h |  5 
>  gcc/config/darwin12.h |  7 -
>  gcc/configure.ac  | 74 
> +++
>  4 files changed, 100 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
> index 045f70b..541bcb3 100644
> --- a/gcc/config/darwin.h
> +++ b/gcc/config/darwin.h
> @@ -165,6 +165,12 @@ extern GTY(()) int darwin_ms_struct;
> specifying the handling of options understood by generic Unix
> linkers, and for positional arguments like libraries.  */
>
> +#if LD64_HAS_EXPORT_DYNAMIC
> +#define DARWIN_EXPORT_DYNAMIC " %{rdynamic:-export_dynamic}"
> +#else
> +#define DARWIN_EXPORT_DYNAMIC " %{rdynamic: %nrdynamic is not supported}"
> +#endif
> +
>  #define LINK_COMMAND_SPEC_A \
> "%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
>  %(linker)" \
> @@ -185,7 +191,9 @@ extern GTY(()) int darwin_ms_struct;
>  %{!nostdlib:%{!nodefaultlibs:\
>%{%:sanitize(address): -lasan } \
>%{%:sanitize(undefined): -lubsan } \
> -  %(link_ssp) %(link_gcc_c_sequence)\
> +  %(link_ssp) \
> +  " DARWIN_EXPORT_DYNAMIC " % +  %(link_gcc_c_sequence) \
>  }}\
>  %{!nostdlib:%{!nostartfiles:%E}} %{T*} %{F*} }}}"
>
> @@ -932,4 +940,10 @@ extern void darwin_driver_init (unsigned int *,struct 
> cl_decoded_option **);
> fall-back default.  */
>  #define DEF_MIN_OSX_VERSION "10.5"
>
> +#ifndef LD64_VERSION
> +#define LD64_VERSION "85.2"
> +#else
> +#define DEF_LD64 LD64_VERSION
> +#endif
> +
>  #endif /* CONFIG_DARWIN_H */
> diff --git a/gcc/config/darwin10.h b/gcc/config/darwin10.h
> index 5829d78..a81fbdc 100644
> --- a/gcc/config/darwin10.h
> +++ b/gcc/config/darwin10.h
> @@ -32,3 +32,8 @@ along with GCC; see the file COPYING3.  If not see
>
>  #undef DEF_MIN_OSX_VERSION
>  #define DEF_MIN_OSX_VERSION "10.6"
> +
> +#ifndef LD64_VERSION
> +#undef DEF_LD64
> +#define DEF_LD64 "97.7"
> +#endif
> diff --git a/gcc/config/darwin12.h b/gcc/config/darwin12.h
> index e366982..f88e2a4 100644
> --- a/gcc/config/darwin12.h
> +++ b/gcc/config/darwin12.h
> @@ -21,10 +21,15 @@ along with GCC; see the file COPYING3.  If not see
>  #undef  LINK_GCC_C_SEQUENCE_SPEC
>  #define LINK_GCC_C_SEQUENCE_SPEC \
>  "%:version-compare(>= 10.6 mmacosx-version-min= 

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Jeff Law]

On 11/07/2016 10:48 AM, Mike Stump wrote:

On Nov 6, 2016, at 11:39 AM, Iain Sandoe  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.

But how is that supposed to work in a cross environment when he can't 
directly query the linker's behavior?


In an ideal world we could trivially query the linker's behavior prior 
to invocation.  But we don't have that kind of infrastructure in place.


ISTM the way to go is to have a configure test to try and DTRT 
automatically for native builds and a flag to set for crosses (or 
potentially override the configure test).



Jeff

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Joseph Myers]

On Sun, 6 Nov 2016, Iain Sandoe wrote:

> This adds an option --with-ld64[=version] that allows the configurer to 

New configure options should be documented in install.texi.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Iain Sandoe]

> On 7 Nov 2016, at 09:51, Mike Stump  wrote:
> 
> [ possible dup ]
> 
>> Begin forwarded message:
>> 
>> From: Mike Stump 
>> 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 
>> Cc: GCC Patches , Jeff Law 
>> 
>> On Nov 6, 2016, at 11:39 AM, Iain Sandoe  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
Iain

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Mike Stump]

On Nov 6, 2016, at 11:39 AM, Iain Sandoe  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.