You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
barracuda156 opened this issue
Jul 5, 2024
· 2 comments
Labels
defectunison fails to meet its specification (but doesn't crash; see also "crash")macOSspecific to macOSwontfixmaintainers choose not to work on this, but PR would still be considered
Looks like it uses uname -m or its equivalent, which returns Power Macintosh. This is incorrect for detecting the arch; instead, standard Xcode arguments can be used. -arch flag takes the arch of the build, not the cpu family of the machine (which is irrelevant, since it may not be a valid arch flag at all, like in this case, or may differ from build arch).
The text was updated successfully, but these errors were encountered:
@barracuda156 Please give the requested details for a bug report: unison version (and for something like this, please make that "today's git master" even though latest release and up-to-date master are likely the same), hardware type, os version, xcode version. mac is quite complicated and there seem to have been a lot of incompatible changes and deprecations over the years. I am not sure we have a clear statement of what we might consider in scope; the default assumption is "systems receiving ongoing maintenance from the OS provider". But, if something can be done better in a way which does no harm, I am open to reviewing a PR.
It is also perhaps useful to look at the POSIX requirements for uname. A number of systems also implement -p which NetBSD documents to return the machine processor architecture name. However, Apple seems to choose to return i386 for systems that are operating as x86_64.
All that said, use of uname -m is sort of a bug, although it's also buggy of xcode not to be set up to take uname output to do what people want.
I think it comes down to finding an expression to tell xcode to build for the build host's CPU family, but that can't be uname -p because of Apple's buggy use of i386 as the answer.
It could be that we run up against Apple bugs once understood, in which case I'll ask you to file them with Apple. They don't get a pass just because people expect them to be intractable :-)
gdt
added
defect
unison fails to meet its specification (but doesn't crash; see also "crash")
wontfix
maintainers choose not to work on this, but PR would still be considered
macOS
specific to macOS
labels
Jul 5, 2024
defectunison fails to meet its specification (but doesn't crash; see also "crash")macOSspecific to macOSwontfixmaintainers choose not to work on this, but PR would still be considered
Looks like it uses
uname -m
or its equivalent, which returnsPower Macintosh
. This is incorrect for detecting the arch; instead, standard Xcode arguments can be used.-arch
flag takes the arch of the build, not the cpu family of the machine (which is irrelevant, since it may not be a valid arch flag at all, like in this case, or may differ from build arch).The text was updated successfully, but these errors were encountered: