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

Fails to locate box when cross-compiling in go 1.5 #66

Closed
robdimsdale opened this issue Aug 9, 2015 · 24 comments
Closed

Fails to locate box when cross-compiling in go 1.5 #66

robdimsdale opened this issue Aug 9, 2015 · 24 comments

Comments

@robdimsdale
Copy link

When cross compiling using go 1.5 the resultant binary fails with:

panic: could not locate box "../assets/templates"

goroutine 1 [running]:
github.com/GeertJohan/go%2erice.MustFindBox(0x820abdfc0, 0x13, 0x9)
    /go/src/github.com/GeertJohan/go.rice/box.go:110 +0x9a

This is true for multiple target architectures. I've verified that it works fine when compiling natively on multiple targets.

I'm using commit ada95a01c963696fb73320ee662195af68be81ae of this repository; this is the tip of master branch.

I'm cross compiling with e.g. GOOS=linux GOARCH=arm GOARM=7 go build main.go

Do you know what would be different about cross compiling vs compiling natively?

@GeertJohan
Copy link
Owner

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

@robdimsdale
Copy link
Author

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
Copy link
Contributor

cortesi commented Sep 13, 2015

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
Copy link
Owner

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
Copy link

kwo commented Sep 18, 2015

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
Copy link

Depado commented Sep 24, 2015

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
Copy link
Owner

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

@Depado
Copy link

Depado commented Sep 27, 2015

@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
Copy link
Author

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
Copy link
Owner

@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
Copy link
Owner

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
Copy link
Author

@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
Copy link

Depado commented Oct 5, 2015

@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
Copy link
Owner

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?

@Depado
Copy link

Depado commented Oct 7, 2015

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
Copy link
Owner

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

@GeertJohan
Copy link
Owner

@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
Copy link

Depado commented Oct 7, 2015

@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
Copy link
Owner

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

@Depado
Copy link

Depado commented Oct 7, 2015

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

@cortesi
Copy link
Contributor

cortesi commented Oct 7, 2015

@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
Copy link
Contributor

cortesi commented Oct 20, 2015

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
Copy link
Author

@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
Copy link
Owner

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

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

5 participants