Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify build.sh to have correct usage statement regarding AMD64/x64 BuildArch #4132

Closed
vindicatorr opened this issue Apr 12, 2015 · 9 comments · Fixed by dotnet/coreclr#707
Closed

Comments

@vindicatorr
Copy link

"x64" -> "amd64"
Otherwise, build fails at 100% with "no rule to make target 'x64'"

./build.sh
Usage()
...

  • Line 6: " echo "BuildArch can be: x64""
  • Line 6: " echo "BuildArch can be: amd64""
    ...
@linquize
Copy link
Contributor

The convention:
On Windows, it is called x64.
But on Linux, it is called amd64.

@vindicatorr
Copy link
Author

I don't know the rationale between the two conventions, but I did specify it was in the "build.sh" file.

@MattWhilden
Copy link
Contributor

We have "AMD64" and "x64" strings all over stuff inside the company... Mostly just accidental with no real hard rules. Am I to understand the convention for unix is "amd64"?

@pgavlin, care to comment?

@kangaroo
Copy link
Contributor

@MattWhilden There is no convention on unix. You'll see x86_64, amd64, and probably some other variants as well.

@MattWhilden
Copy link
Contributor

Thanks for the reply @kangaroo.

Given that, do we just say, "Our convention for this project is x86/x64/ARM etc" or is it better for our scripts to unify some of the various names?

@vindicatorr
Copy link
Author

I'll give my vote for whatever convention is most common in linux at the most basic level (kernel|compiler).
eg.
gcc (-march): https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Submodel-Options.html#Submodel-Options
I think that would be the architectures i386, x86_64, ARM, AArch64.

vs
kernel (arch): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/configs?id=refs/tags/v4.0
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch?id=refs/tags/v4.0
Which would be i386, x86_64, arm, arm64

I vote "i386, x86_64, arm, arm64" if these are my only options.

My preference would be x86-32, x86-64 to denote intel/amd, then for arm, arm-32, arm-64.

Eventually 32-bit will become extinct and a future bit system (128) will push forth so you could drop the naming for *-32 and create *-128.
Essentially it would be <base/common-system-name>-.

@MattWhilden MattWhilden self-assigned this Apr 14, 2015
@MattWhilden
Copy link
Contributor

I'll follow up with folks here and see what the consensus is. I don't know how much will actually change or if we'll just document the current state with potential followup but I'll let you know.

@vindicatorr
Copy link
Author

I think I'm needing to reiterate the OP is about a failed build due to the incorrect parameter used per "help" usage output.

"./build.sh" says to use "x64", but the build will fail at the very end.
The parameter needs to be "amd64" in order for the build to succeed.

@MattWhilden
Copy link
Contributor

facepalm that's an even easier fix for now. Goes to show how easy it is to get distracted. That fix seems easy enough.

@MattWhilden MattWhilden changed the title BuildArch can be: Modify build.sh to have correct usage statement regarding AMD64/x64 BuildArch Apr 14, 2015
ellismg referenced this issue in ellismg/coreclr Apr 15, 2015
The help text for build.sh said that you should pass "x64" as a
paramter for the build architecture.  However, the script was looking
for amd64.  Update the script to look for x64 since that's what we use
everywhere else (and the behavior you got if you didn't pass an
argument to this script.)

Fixes #689
ellismg referenced this issue in ellismg/coreclr Apr 15, 2015
The help text for build.sh said that you should pass "x64" as a
paramter for the build architecture.  However, the script was looking
for amd64.  Update the script to look for x64 since that's what we use
everywhere else (and the behavior you got if you didn't pass an
argument to this script.)

Fixes #689
@msftgits msftgits transferred this issue from dotnet/coreclr Jan 30, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Jan 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants