32-bit go compiler runs out of memory

[dontpanic92]

I've no idea on how to solve this. I'm not sure whether splitting the wrap file into multiple files can help -- golang will compile all go files in a package together so I don't think it works.

[neonsoftware]

Hi @dontpanic92,

I confirm you that I have seen as well 32bit compilation break Travis. But not my own CI server, so basically 32bit compilation actually works.
Although, as you say, it does requirea quite a fat memory, and if you consider >5g a big memory I completely agree and look forward an improvement.

Here is an input, go 1.7 includes a new feature called binary-only packages. It was created for closed-source projects, but it could be very useful as an alternative way to distribute this package to users that did not succeed to compile. (I think also about the embedded world, related to the arm compilation in issue #4, which I am finalizing).
Here is a sample example that very nicely illustrates how to create and distribute a binary-only package.

It's not the best solution, as it is not compatible with 'go get' yet, but it's viable alternative for still using the library with low resources. And it's official.

Also the build phase in the 'go get' is quite time-consuming. I could see one preferring this format when performing 'go get' within continuous integration and within the development cycle.

Looking forward to hear your opinion.

Cheers

[dontpanic92]

Really make sense. Even for 64 bit go users, it can save their time and it is also new-users friendly. If the binary-only packages don't satisfy users' needs, they can always compile it from source, though they may have to do a cross-compilation.

I'm currently working on an alternative go backend for SWIG. We can consider making a binary release when these works are done.

[neonsoftware]

Sounds great. 👍

[neonsoftware]

one thing, purely for information, I encountered by chance that the 'go build' tool actually recognises SWIG files, was that looked into or could it be relevant to the case ?

[dontpanic92]

I have taken a look at the binary only package, and unfortunately it doesn't work out of box though it looks like a very straight-forward method. We have the third-party dependencies, i.e the wx-libs in the wx/OS_ARCH/lib/. When we compile an application with precompiled wxGo static binary, the linker also needs to find these wx-libs --it will still try to find them in the original path when I compile wxGo. It seems that the path is stored in the compiled binary file.

Perhaps there are some ways to cope with this issue, it needs more investigation.

[dontpanic92]

Found solutions!

The linker cannot found these libraries, so one of the solutions is that we also include these static libraries in the binary-only-package, and the users have to add LDFLAGS to specify the path where the libraries live.

Another solution needs a little hack, but it doesn't require users to do any other work. We can use ar x to extract all the .o files which are archived in these .a files, and then use go tool pack -r to append these .o files to compiled wx.a library. Then everything goes well.

[neonsoftware]

I kind of like them both 😃, it would be quite a heavier hand, but since it would be confined to special and limited contexts then either a more assuming or a more manually static solution will still be a viable solution

[gonboy]

Whether the latest version has resolved this issue ？？？

[dontpanic92]

Actually no, but you can use the binary-only-packages, which are precompiled go packages (cross-compiling by a 64bit go compiler) that can be used directly by 32bit compilers. The go versions must match, i.e. if I compile the binary-only-packages using go 1.8.1, then the generated packages cannot be used by other versions of go.

I have compiled the binary-only-packages for go 1.8, which can be found in the releases page. You can also compile these packages yourself (for example, for a different go version), just run utils/build_binary_package.sh YOUR_OS 386.

简言之就是用预编译好的包就行，但是Go版本得对的上

[Asday]

If it's any help, installing wxPython from pip without pointing it at the precompiled stuff, (causing wx to be compiled), it takes about 5GiB there, too.

I think wx is just huge.