Unable to cross compile

[skx]

Unable to cross compile

[skx]

My view is that if a patch were to be submitted that used different bindings I'd accept it, but otherwise it works as-is and I wouldn't go out of my way to change just for cross-compilation.

I won't close, but I'll label appropriately.

[stahnma]

I got a build to cross-compile after a lot of fiddling with CGO. I'll put in a PR with some documentation on how to make it work. It's not super-pretty, but probably works. (I mean, it worked for me).

[skx]

For my own reference I looked into this again yesterday because I wanted to auto-build an i386 binary, as well as the amd64 one.

Turns out I'd misunderstood the nature of the bug report. What I thought was "These bindings don't allow for cross-compilation, please use a different sqlite binding". The actual bug here is that sqlite doesn't allow cross-compilation easily, because it is a native package.

So a solution here is not just "Find better/different bindings" it is "Don't use SQLite". I had a brief look at ql and boltdb. It might be that I'll have to switch to one/other of them, or something similar. The sticking point will be getting the queries we want working.

[stahnma]

Interesting. I hadn't looked into it very closely, so I wasn't sure.

…

On Aug 13, 2017 03:30, "Steve Kemp" ***@***.***> wrote: For my own reference I looked into this again yesterday because I wanted to auto-build an i386 binary, as well as the amd64 one. Turns out I'd misunderstood the nature of the bug report. What I thought was "These bindings don't allow for cross-compilation, please use a different sqlite binding". The actual bug here is that sqlite doesn't allow cross-compilation easily, because it is a native package. So a solution here is not just "Find better/different bindings" it is "Don't use SQLite". I had a brief look at ql and boltdb. It might be that I'll have to switch to one/other of them, or something similar. The sticking point will be getting the queries we want working. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAbMYG5DNK6TbgGtk29s9ot470_6bQdks5sXrRCgaJpZM4O0NjF> .

[skx]

I've not looked horribly in-depth, but I think there are probably three different ways to go:

• Try to rework things to use cznic/ql, which is 100% golang.
• Try to rework it to use boltdb/leveldb.
• Try to rework it to use Redis.

The first is perhaps the best, but failing that the last has its appeal. Moving from a relational database to key/val would be a lot of work, redis would let us store things in sets/hashes which makes it easier, but still non-trivial.