On Nov 7, 2016, at 10:40 AM, Jeff Law <l...@redhat.com> wrote: > > On 11/07/2016 10:48 AM, Mike Stump wrote: >> 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. >> > 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.
