type [1073741824]uint16 too large
winxxp opened this issue · comments
set GOARCH=386
\example_glfw_opengl3> go build -v -tags 'glfw' -o 32.exe .
D:\Golib\pkg\mod\github.com\inkyblackness\imgui-go\v2@v2.1.0\AllocatedGlyphRanges.go:32:16: type [1073741824]uint16 too large
D:\Golib\pkg\mod\github.com\inkyblackness\imgui-go\v2@v2.1.0\GlyphRanges.go:24:16: type [1073741824]uint16 too large
Assuming your goal is to get a binary for an Intel 386 CPU and you are wondering why it does not work: I find your enthusiasm great, and I also wonder how you got that far.
Because when I try to run this, go bails out earlier, as the libraries won't support this:
GOARCH=386 go run -tags 'glfw' .
../../internal/renderers/OpenGL2.go:7:2: build constraints exclude all Go files in /home/dertseha/go/pkg/mod/github.com/go-gl/gl@v0.0.0-20190320180904-bf2b1f2f34d7/v2.1/gl
../../internal/renderers/OpenGL3.go:7:2: build constraints exclude all Go files in /home/dertseha/go/pkg/mod/github.com/go-gl/gl@v0.0.0-20190320180904-bf2b1f2f34d7/v3.2-core/gl
../../internal/platforms/glfw.go:10:2: build constraints exclude all Go files in /home/dertseha/go/pkg/mod/github.com/go-gl/glfw/v3.3/glfw@v0.0.0-20200222043503-6f7a984d4dc4
This is running on Go 1.14 (a similar error was happening with 1.13, albeit a little more cryptic) - both for Linux and MS Windows and trying it with newest libraries.
What kind of setup are you running this in? If you can reproduce this, I'd also be happy with a pull-request.
It comes down to a common hack to get back from a raw C-pointer to a typed-array of a certain size. The 386 build would need a different arbitrary large-enough size for the base array pointer.
Closing due to inactivity and apparent non-applicability.
Had the same problem trying to compile directly (not cross compiling) on Raspberry Pi 4 (2GB and Raspberry PI OS).
Didn't really try to understand what that code does, just changed culprit lines from 1 << 30 to 1 << 20 and it compiled and ran fine.
Later tried with 1 << 29 and it worked... then tried with (1 << 30) - 1 and it was also working. So i don't know whether changing those value would break something for anyone, but if not then probably those values should be lowered, at least by one.
Thank you for more details, @the-goodies . I originally focused only on the examples and an Intel architecture.
With more evidences, I looked at it again, and changed the code to also handle 32bit architectures.
Sadly, I still could not reproduce it, despite having access to an ARM system. For some reason, it wouldn't compile with bogus errors - hopefully some problem with my setup.
Await v2.4.1 momentarily.