Fails to locate box when cross-compiling in go 1.5 about go.rice

[Depado]

Isn't generating the go source files with rice embed-go supposed to include the resources directly in the binary when compiling without appending after ?

[GeertJohan]

Is the binary executed with having the pwd equal to the cmd import path location?

[robdimsdale]

Yes. I ran go get path-to-my-repo in Ubuntu 14.04 and cd $GOPATH/my-repo and everything works as expected - building the binary is fine, and the embedded files exist when running it.

I do the identical same steps in a docker container with the Ubuntu 14.04 image and the build passes but the resultant binary panics.

[cortesi]

I'm seeing the same issue. It looks like the error only occurs when a relative path is specified. So, "./assets" fails on cross-compilation, but just "assets" does not.

[GeertJohan]

I didn't find how this can happen yet. I only tested subfolders being rice boxes (so no ../ or ./ required). Can you please paste the steps you're executing @robdimsdale ?

[kwo]

I'm getting the same issue on normal compilation on OS X and am also using a relative path. All works fine in live mode but I cannot append to an executable.

[Depado]

Same issue here. Compiling with rice embed-go && go build and then scping the binary to another machine results in a panic about the boxes not being found.

[GeertJohan]

I'm not too familiar with cross-compiling.. I'l try to reproduce. Can someone paste the complete panic message?

[Depado]

@GeertJohan It's not an issue about cross compiling I think, more an issue with Go 1.5. I get the same problem even though not cross-compiling.

Compiled on a 64bit Linux, executed on 64bit Linux, here is the full panic :

panic: could not locate box "templates"

goroutine 1 [running]:
github.com/GeertJohan/go%2erice.MustFindBox(0x924a70, 0x9, 0xc820000180)
    /home/hellsing/Prog/GoLang/src/github.com/GeertJohan/go.rice/box.go:110 +0x9a
main.init()
    /home/hellsing/Prog/GoLang/src/git.defab.fr/depado/go-randagent/main.go:28 +0xb0

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

goroutine 20 [runnable]:
os/signal.loop()
    /usr/local/go/src/os/signal/signal_unix.go:20
created by os/signal.init.1
    /usr/local/go/src/os/signal/signal_unix.go:28 +0x37

goroutine 21 [runnable]:
github.com/zenazn/goji/graceful.waitForSignal()
    /home/hellsing/Prog/GoLang/src/github.com/zenazn/goji/graceful/signal.go:92
created by github.com/zenazn/goji/graceful.init.3
    /home/hellsing/Prog/GoLang/src/github.com/zenazn/goji/graceful/signal.go:31 +0x2b

There is also the panic from Goji though. Don't mind that part.

[robdimsdale]

I have created a sample app that demonstrates the issue I am seeing at https://github.com/robdimsdale/go-rice-test

from OSX run the following command:

GOOS=linux go build -o go-rice-test main.go

and copy the resultant binary to a linux machine and you will see the following error:

panic: could not locate box "http-files"

goroutine 1 [running]:
github.com/GeertJohan/go%2erice.MustFindBox(0x79a890, 0xa, 0x0)
    /Users/robdimsdale/go/src/github.com/GeertJohan/go.rice/box.go:110 +0x9a
main.main()
    /Users/robdimsdale/go/src/github.com/robdimsdale/go-rice-test/main.go:12 +0x62

If you cross-compile on a linux machine to target darwin, and run the resultant binary on an OSX machine, you will see the same issue.

This is using the HEAD of https://github.com/GeertJohan/go.rice and go 1.5.1

I am no longer using this library in my applications, so I will be unable to assist much further.

---

I cannot reproduce the issue @Depado is reporting with regards to native compilation - when I run it natively it works fine. I did have to delete the entire GOROOT and reinstall go 1.5.1 - when I tried to install go 1.5.1 over the top of go 1.4.2 it gave me the following error:

package runtime: C source files not allowed when not using cgo or SWIG: atomic_amd64x.c defs.c float.c heapdump.c lfstack.c malloc.c mcache.c mcentral.c mem_linux.c mfixalloc.c mgc0.c mheap.c msize.c os_linux.c panic.c parfor.c proc.c runtime.c signal.c signal_amd64x.c signal_unix.c stack.c string.c sys_x86.c vdso_linux_amd64.c

However, I think that is simply an issue with trying to install one version of golang over the top of an existing one, rather than installing to an empty directory.

[GeertJohan]

@robdimsdale Thanks for your report. I think the second error you're mentioning is not related here, looks like trouble with the Go install in generic. rice isn't using any C by default (only the embed-syso experiment does).

[GeertJohan]

I don't have a lot of free time at the moment, and didn't run into this issue myself yet. I hope to be able to fix soon. PR is also welcome and would be very much appreciated.

[robdimsdale]

@GeertJohan correct, the second part of my comment was intended to clarify that I could not reproduce the issue as described by @Depado - that I can only observe this when cross-compiling and that native compilation seems to work fine.

As I mentioned, I switched to a different library (https://github.com/mjibson/esc) so from my perspective I'm happy for you to close the issue.

[Depado]

@robdimsdale I have no trouble working with rice on the same machine. Compilation works fine, I can execute and such. But when I move the binary to another machine, then the issue shows up. Although appending via rice append --exec mybinary fixes the issue.

[GeertJohan]

Ah yes, I must have missed this in @robdimsdale's post, sorry. You must append the the binary with the rice boxes before moving the binary to a different machine. Without appended files, rice will try to look for the files on the filesystem. If it cannot find them the MustFindBox call will panic with could not locate box "<box-name>", as documented.

@kwo and @cortesi how did you reproduce? Did you append before moving the binary?

[GeertJohan]

@Depado yes. If you're using that you should be fine.

[GeertJohan]

@Depado In your panic I see you're trying to load the box during init. The embedded go files need an init too. Your init might be too soon (the box was not registered yet to the internal box register used by embedding).

[Depado]

@GeertJohan

package main

import (
    "flag"
    "html/template"
    "log"
    "math/rand"
    "net/http"
    "net/http/pprof"
    "strconv"
    "time"

    "github.com/GeertJohan/go.rice"
    "github.com/zenazn/goji"
    "github.com/zenazn/goji/web"
)

var templateBox = rice.MustFindBox("templates")
var staticBox = rice.MustFindBox("assets")

I "Find" the boxes right at the start of my program. Is that what you mean ? Where should I place the MustFindBox if not at the start ? (Maybe that would need another issue though I don't know if that's related to the cross-compilation problem I guess)

[GeertJohan]

You can have the templateBox and staticBox as global variables of type *rice.Box, just make sure to initialize them in main().

[Depado]

Alright ! It fixed the issue for me, although it was just a programming error. Thanks a lot for your reactivity.

[cortesi]

@GeertJohan I don't have time to track this down at the moment, but I'm seeing the issue using embedded boxes, using a super-simple test program like this:

func main() {
    fmt.Printf("%v", rice.MustFindBox("./static"))
}

To trigger the issue, I start on OSX, run "rice embed-go", and then cross-compile the binary for linux:

env GOOS=linux go build

Running the binary on Linux, I see:

panic: could not locate box "./static"

The exact same code works compiled locally for OSX. If I change the relative path "./static" to just "static", and re-run "rice embed-go", the code works on both platforms even with cross-compilation. I haven't confirmed that this works when compiled on Linux for Linux, so it may be a platform issue.

Geert, if you can't track this down, I might be able to make time a bit later in the week to look at this in more detail.

[cortesi]

I think this particular issue now spans a number of different problems, and should be split up. I've just reported #67 with an associated pull request that fixes my issue, and might also fix some of what other people are seeing here.

@robdimsdale: I'm unable to reproduce the cross compilation issue using your test code. Using the current master, "rice go-embed", cross compilation, and the running the binary in Linux with docker works. If you'd like to pursue this, please let me know, and I'll submit a Dockerfile and test script to your repo so we can make sure we're on the same page.

[robdimsdale]

@cortesi thanks for the offer. I am not working on this - no need to pursue. I'm glad it appears to be working though.

@GeertJohan I agree with @cortesi that this issue is overloaded. My original issue appears solved, so from my perspective I am happy for you to close the issue.

[GeertJohan]

Closing this issue. If anyone feels their problem hasn't been resolved yet please open a new issue.