Dear Karl,
I'm just shortly explaining some points below (without a complete
answer or patches yet).
On Tue, Nov 5, 2013 at 11:14 PM, Karl Berry wrote:
>
> So, to state the obvious, please write config-patches@gnu.org and cc me,
> explaining the problem with the compiler situation. Please also suggest
> what should be done, since I doubt he will know off the top of his head.
> Preferably also provide an actual patch that works for you.
>
> Specifically, as already noted, there is code in config.guess for the
> case where a compiler is not present (on darwin, and in general):
> if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then
I don't have 10.9, but based on Adam's feedback there should be an
option to explicitly disable the compiler. Maybe like this?
CC=no_compiler_found ./config.guess
A question for Karl: would it be acceptable for TeX Live to set
CC=no_compiler_found before calling config.guess? This would solve the
first half of the problem then. But is this even in accordance to
"good practices" when using config.guess? (It seems to me like a
semi-weird hack that could stop working if config.guess gets
modified.)
> So you need to explain (to Ben, not me) why that is insufficient and
> what to do. If the issue is that Apple's useless stub is exiting
> successfully, then maybe the it would work to check for a non-empty
> $dummy.o resulting from the test compile.
>
> As a separate issue, it would apparently also be nice to discuss with
> Ben how config.guess's results on Macs could be improved in general.
> Aside from the stub compiler breakage, I could not follow the ideas
> being proposed, or not proposed, or what was wrong, or anything else.
I wrote a bit below, but some more pseudocode and a more complete
answer would be in place.
> I don't want to add more warts to our stuff to work around Apple issues.
> (In fact, I'd like to get rid of the wart we have. Maybe config.guess
> could reliably detect our concept of x86_64-darwin, so that we don't
> have to screw around with sw_vers and sysctl. I'm not sure.)
You can already avoid sw_vers by taking into account the complete
string that config.guess returns (darwin11 means 10.7, darwin12 means
10.8, ...), but you still need an "if clause" to prevent 64-bit
binaries on 10.5. (You get the advantage of one system call less and
the disadvantage of slightly less readability and the need for one
more regular expression to extract the darwin version, so the perl
code won't look any nicer at the end.)
You can only avoid calling sysctl if config.guess would be patched
properly. This is a question for Ben: if it would be OK to call sysctl
when the compiler isn't known / when it's disabled.
> If there is some reason why tlmgr needs to do something more that is
> outside the design of config.guess (re Ben's reply about kernel
> vs. userland), I need a comprehensible explanation.
Not necessarily more, but even if config.guess was perfect for its
purpose, tlmgr needs to behave slightly differently.
The role of config.guess should be figuring out what architecture we
are compiling *for* (that could easily be i386 or ppc even on x86_64).
The role of tlmgr's architecture on the other hand should be to
determine what binaries are most suitable for the architecture we are
working on. If computer is capable of running 64-bit, it should always
be x86_64.
But on top of that tlmgr should also claim anything running on 10.5 or
earlier to be universal-darwin instead of x86_64-darwin but that's
only because *our* 64-bit binaries don't work on 10.5, so in that case
one really needs to "overwrite" the decision made by config.guess (if
config.guess would report x86_64 on 10.5).
As Adam already mentioned, tlmgr needs to report the following:
a) on 10.5 and earlier => universal
b) on 10.6 => i386 or x86_64 depending on the return value of
sysctl hw.cpu64bit_capable
c) on 10.7 and later => x86_64
and needs to avoid calling the compiler altogether.
Note that tlmgr currently also calls "sw_vers -productVersion", but
that information is contained in the output of config.guess which
returns something like
x86_64-apple-darwin11.4.2
and that number 11 means "version 10.7". The number 12 is for 10.8, 13
for 10.9 etc. (Calling "sw_vers" could actually be avoided.)
Now ... config.guess is normally used in an environment where the
compiler is known and config.guess often calls the compiler to
determine the type and properties of the compiler, while for tlmgr it
would be really desired to prevent calling the compiler. In
config.guess can be called in such a way that compiler wouldn't be
called under any circumstances, then config.guess could be patched in
such a way that it would check for 64-bitness based on
"sysctl hw.cpu64bit_capable"
and you could then basically avoid the majority of special handling for macs.
But from my understanding config.guess has never really been designed
to be used outside of compiler domain and before any patches are
written it would help to know if it would be acceptable for the
developers to patch config.guess is a way that:
- one could avoid calling the compiler (on request, with a special
flag or environmental variable, not by default)
- if compiler was "disabled", the distinction between i386 and x86_64
would be done based on "sysctl hw.cpu64bit_capable" on 10.5 & 10.6
rather than by checking for "#ifdef __LP64__"
Just to illustrate an example:
Let's say that we have a user on a 64-bit capable 10.6. tlmgr should
then return "x86_64-darwin". But if that same user then tries to
compile an arbitrary software from sources on the very same hardware
and software and specifies either
CXX=powerpc-apple-darwin10-g++-4.0
or
CXXFLAGS="-arch ppc"
then I would expect from config.guess to return
powerpc-apple-darwin10.x.y, not x86_64-apple-darwin10.x.y. (This is
not the case and I consider this a bug in config.guess, actually.)
This kind of information can only be obtained by inspecting what
constants the compiler defines/sees. (Like it is done for "#ifdef
__LP64__", it should also be checked for PPC definitions etc.)
Mojca
_______________________________________________
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches
