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

math/big error on arm #49

Open
njaremko opened this issue Jan 31, 2017 · 11 comments
Open

math/big error on arm #49

njaremko opened this issue Jan 31, 2017 · 11 comments

Comments

@njaremko
Copy link

When attempting to build on arm, I get this:
src/github.com/mattn/anko/builtins/math/big/big.go:19: constant 4294967295 overflows int

and the build fails.

@mattn
Copy link
Owner

mattn commented Jan 31, 2017

Could you please show me your code reproduce?

@njaremko
Copy link
Author

No code, just running go get github.com/mattn/anko

@mattn
Copy link
Owner

mattn commented Jan 31, 2017

Hmm, it seems a bug of go/arm. could you please file issue on https://github.com/golang/go/issues/new ?

@mattn
Copy link
Owner

mattn commented Jan 31, 2017

But I can do workaround like removing the part of line until go fix the issue. Could you please try to figure out what line should be removed.

@njaremko
Copy link
Author

Line 19 of big.go

@mattn
Copy link
Owner

mattn commented Jan 31, 2017

Yes, it's only 1 line?

@njaremko
Copy link
Author

Yep

mattn added a commit that referenced this issue Jan 31, 2017
@mattn
Copy link
Owner

mattn commented Jan 31, 2017

removed math.MaxPrec temporary (until fixing this go/arm issue), and I keep to open this issue until it. Thank you

@mattn
Copy link
Owner

mattn commented Feb 7, 2017

@njaremko Could you please file your issue? https://github.com/golang/go/issues/new

@MichaelS11
Copy link
Contributor

This may not have been an issue with Go, nor with arm. Maybe this was just issue with a 32 bit system.

From Big:
MaxPrec = math.MaxUint32 // largest (theoretically) supported precision; likely memory-limited

So a unit32 const was being put into a int which was an int32, which means the value was too big.

Maybe now everything will be fine now that we are using the new packages? I do not have a 32 bit system to test. Anyone have a 32 bit system to test?

@MichaelS11
Copy link
Contributor

@mattn any thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants