When I think "march" I think of the string I pass to the compiler to explicitly get 32 or 64 bit. For clang on macOS, I say "x86_64" and for 32 bit I say "i386".
It's fine if deken uses the different string, I was more trying to clarify my understanding. Ideally, I'd prefer if those string matched but I can also understand the underscore in "x86_64" is not ideal for the filename parsing.
On Apr 30, 2018, at 10:14 AM, pd-dev-request@lists.iem.at wrote:
When compiler on macOS, it's DEFINITELY x86_64. Isn't it the same in MinGW?
could you clarify how you define "it"?
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 2018-04-30 10:29, Dan Wilcox wrote:
When I think "march" I think of the string I pass to the compiler to explicitly get 32 or 64 bit. For clang on macOS, I say "x86_64" and for 32 bit I say "i386".
It's fine if deken uses the different string, I was more trying to clarify my understanding. Ideally, I'd prefer if those string matched but I can also understand the underscore in "x86_64" is not ideal for the filename parsing.
thanks for the clarification.
the thing with "march" is, that this string is just a gcc flag (also available to clang). afaict, the flag meaningless on other compilers, like MSVC, and the same architecture is named differently on other compilers as well ("x64" on msvc).
so the point was to get a march identifier that is independent of my or your current toolset.
and to stand on the shoulder of giants (Debian, that is).
gmfsdt IOhannes
-
Dan Wilcox -
IOhannes m zmoelnig