On Nov 7, 2016, at 9:15 PM, Iain Sandoe <i...@codesourcery.com> 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 when it can (an in-tree build) and makes decisions at > least as a fall-back on that (so precedent) - we can’t do that for ld64 > (there’s no equivalent in-tree build) but we _can_ tell configure when we > know, We can, that's not the question, the question is why would we want to when we already know the answer? >> 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. > > This is OK for professional toolchain folks, but it’s a complex set of > operations c.f. “obtaining the relevant installation for the desired host”. $ apt install darwin-gcc if you want it. Or, if you don't like that: $ wget .../install-darwin-gcc $ install-darwin-gcc Pretty simple, no?
