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
feedback for binary distro linux-amd64 #3211
Labels
Comments
Works on Fedora 15 x86_64. Offering bzip2 or xz archives could help people with slower links: gzip download: 32405785 bzip2 -9: 27241965 xz -9: 17782308 I see that quite a few recent releases of GNU code use xz. Fedora 15 includes support for xz in tar 1.26. It might be nice to offer a minimal download for people that update regularly and don't need all the docs, source, etc. and instead consume them from the web. Here's me trying to install go.crypto with go.weekly.2012-03-04.linux-amd64.tar.gz: $ export GOPATH= $ cd ~/go $ rm -rf src # just to see if this works $ go get -v code.google.com/p/go.crypto code.google.com/p/go.crypto (download) package code.google.com/p/go.crypto imports code.google.com/p/go.crypto: no Go source files in $HOME/go/src/pkg/code.google.com/p/go.crypto What's this error about? $ go install -v code.google.com/p/go.crypto can't load package: package code.google.com/p/go.crypto: no Go source files in $HOME/go/src/pkg/code.google.com/p/go.crypto $ go install -v code.google.com/p/go.crypto/... This works after the go get. Now try go get with the dots after deleting src again: $ rm -rf src $ go get -v code.google.com/p/go.crypto/... warning: "code.google.com/p/go.crypto/..." matched no packages Is there any way to install go.crypto without getting an error somewhere in the process? |
Might be a good idea to sign the tarballs. http://www.gnu.org/software/swbis/ |
ubuntu 10.04.3 server amd64 $ uname -a Linux ubuntu 2.6.32-33-generic #70-Ubuntu SMP Thu Jul 7 21:13:52 UTC 2011 x86_64 GNU/Linux using: go.weekly.2012-03-04.linux-amd64.tar.gz after the install the permissions were set to user: 104178 group: 5000 no world readable on the directories or files no world executable on the executable files so I did the following to get it to work: sudo find /usr/local/go -print | xargs chown root.root sudo find /usr/local/go -print | xargs chmod +wr sudo find /usr/local/go -type d -print | xargs chmod +wx sudo chmod +wx /usr/local/go/bin/* sudo chmod +wx /usr/local/go/pkg/tool/linux_amd64/* then it worked fine :) note that I was using a non privileged account. |
CentOS 5.4 (Old and busted I know) # uname -a Linux mcp 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux go run hello.go # command-line-arguments /usr/local/go/pkg/tool/linux_amd64/6g: /lib64/libc.so.6: version `GLIBC_2.7' not found (required by /usr/local/go/pkg/tool/linux_amd64/6g) |
I looked at the dynamic symbols with objdump -T: objdump -T go/pkg/tool/linux_amd64/* | grep GLIBC_2.7 | sort -u 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.7 __open64_2 The full list of GLIBC_* symbol versions: GLIBC_2.2.5 GLIBC_2.3 GLIBC_2.3.4 GLIBC_2.4 GLIBC_2.7 I'm guessing that if the open function is replaced with code in Go instead of using the glibc version, these binaries could run almost anywhere? |
If I build on Fedora 15 x86_64, I get these symbol versions: GLIBC_2.14 GLIBC_2.2.5 GLIBC_2.3 Specifically: 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 open 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 open64 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 opendir and the only GLIBC_2.14 symbol is memcpy: 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.14 memcpy |
Some ideas for solving the memcpy issue: http://stackoverflow.com/questions/8823267/linking-against-older-symbol-version-in-a-so-file |
I think you'll find that the GLIBC_2.7 open function is being called from 6g and other C programs, so writing a Go function won't help. It is inevitable that binary releases will fail to run on some old systems. The question is: what is the oldest system that we want the binary releases to support? I personally have no problem saying that binary release won't work on CentOS 5. It will still be possible to install from source. |
Not supporting some older systems is probably fine. But as far as I understand, the O_CLOEXEC stuff was backported to later versions of RHEL/CentOS 5 (5.2 or 5.3), so these could actually be supported: http://www.held.org.il/blog/2008/03/glibc-27-on-centos-rhel-5/ Where I wrote "Go version" I meant that the C tools could use an open function implemented in C outside of glibc. Maybe the same trick as for memcpy could be used. It could be nice to solve this problem so that anybody building a binary distro for others (think of someone distributing Go+go.crypto+other dependencies+patches to an internal team in a company) has a good chance of producing a build that will work on most machines. |
Also, RHEL/CentOS 5 is still going to be with us until 2017 or even 2020: http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Life_Cycle_Dates |
I understand. All I did was document a bit of research here that suggested that the barrier to supporting a widely used distribution (especially if you include other derivatives like CentOS, Scientific Linux, Oracle's distro, etc.) with this binary distro isn't very high. You are completely free to disregard this information or disagree about the height of the barrier. You are free to choose to not support these distros. As has been said, users of these distributions are then free to puzzle over the errors they will see when running this binary distribution, after which they are free to build from source. At least a quick Google on their part might turn up this discussion. :-) |
Comment 21 by erwin.misc@24speed.at: It works :-) $ go run hello.go Hello, 世界 $ go build hello.go $ ./hello Hello, 世界 $ uname -a Linux X61 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012 x86_64 GNU/Linux $ cat /etc/debian_version 6.0.4 $ go version go version weekly.2012-03-04 +f4470a54e6db File ~/.profile # GOOGLE GO if [ -d "$HOME/opt/go" ] ; then export GOROOT="$HOME/opt/go" export GOARCH="amd64" export GOOS="linux" export GOBIN="$GOROOT/bin" PATH="$GOROOT/bin:$PATH" fi |
It works on Archlinux x86_64. Just require chown -R root:users. Please 'strip' binary files (and library if possible) to reduce binary size.(All platform) My sample find $pkgdir/opt/go -type f -perm -u+w 2>/dev/null | while read binary ; do case "$(file -bi "$binary")" in #*application/x-sharedlib*) # Libraries (.so) # strip $STRIP_SHARED "$binary";; #*application/x-archive*) # Libraries (.a) # strip $STRIP_STATIC "$binary";; *application/x-executable*) # Binaries strip $STRIP_BINARIES "$binary";; esac done |
March 13 build problems: 1. permission denied for the mode is 0750, it is 0755 for better, and all source/library should be 0644 instead of 0640 Temp solution (if install on /opt/go): sudo chmod -r o+r /opt/go sudo chmod -R o+r /opt/go sudo chmod -R o+x /opt/go/bin sudo chmod -R o+x /opt/go/pkg/tool/linux_amd64/* 2. please strip the binary to reduce package size. My sample script for strip: find $pkgdir/opt/go -type f 2>/dev/null | while read binary ; do case "$(file -bi "$binary")" in *application/x-sharedlib*) # Libraries (.so) strip $STRIP_SHARED "$binary";; *application/x-archive*) # Libraries (.a) strip $STRIP_STATIC "$binary";; *application/x-executable*) # Binaries strip $STRIP_BINARIES "$binary";; esac done |
March 13 build binary problems & suggestions. linux platform problems =================== 1. permission denied for the mode is 0750, it is 0755 for better, and all source/library should be 0644 instead of 0640 Temp solution (if install on /opt/go): sudo chmod -r o+r /opt/go sudo chmod -R o+r /opt/go sudo chmod -R o+x /opt/go/bin sudo chmod -R o+x /opt/go/pkg/tool/linux_amd64/* Common problems on all platforms =========================== 1. please strip the binary to reduce package size. My sample script for strip: find $pkgdir/opt/go -type f 2>/dev/null | while read binary ; do case "$(file -bi "$binary")" in *application/x-sharedlib*) # Libraries (.so) strip $STRIP_SHARED "$binary";; *application/x-archive*) # Libraries (.a) strip $STRIP_STATIC "$binary";; *application/x-executable*) # Binaries strip $STRIP_BINARIES "$binary";; esac done 2. godoc example can not expand under IE 8(Windows XP) 3. please use hyper link instead of release pdf documents in binary. I suggest add some links in 'doucments' page: * contrib.html * ExpressivenessOfGo.pdf (its code are before Go1) * describe windows utf-8 platform on install.html, ref: http://stackoverflow.com/questions/9611931 |
March 13 build binary problems & suggestions. linux platform problems =================== 1. permission denied for the mode is 0750, it is 0755 for better, and all source/library should be 0644 instead of 0640 Temp solution (if install on /opt/go): sudo chmod -r o+r /opt/go sudo chmod -R o+r /opt/go sudo chmod -R o+x /opt/go/bin sudo chmod -R o+x /opt/go/pkg/tool/linux_amd64/* Common problems on all platforms =========================== 1. please strip the binary to reduce package size. My sample script for strip: find $pkgdir/opt/go -type f 2>/dev/null | while read binary ; do case "$(file -bi "$binary")" in *application/x-sharedlib*) # Libraries (.so) strip $STRIP_SHARED "$binary";; *application/x-archive*) # Libraries (.a) strip $STRIP_STATIC "$binary";; *application/x-executable*) # Binaries strip $STRIP_BINARIES "$binary";; esac done |
Go1 RC1 build works on Archlinux > uname -a Linux Loki 3.2.9-1-ARCH #1 SMP PREEMPT Thu Mar 1 09:31:13 CET 2012 x86_64 AMD Phenom(tm) II X2 555 Processor AuthenticAMD GNU/Linux Note: I installed Go out side of my home directory and as root so after extracting the tarball all I had to do was sudo chmod -R o+x /opt/go and everything worked |
This may be a problem on my side (see below), but I wanted to report in case anybody else sees this. After installing the tarball in an amd64 Linux, I get this when compiling a simple code: magnets@a:~/gist-2073020$ go build -x -v WORK=/tmp/go-build301440566 _/home/magnets/gist-2073020 mkdir -p $WORK/_/home/magnets/gist-2073020/_obj/ cd /home/magnets/gist-2073020 /home/magnets/go/pkg/tool/linux_amd64/6g -o $WORK/_/home/magnets/gist-2073020/_obj/_go_.6 -p _/home/magnets/gist-2073020 -D _/home/magnets/gist-2073020 -I $WORK ./gistfile1.go /home/magnets/go/pkg/tool/linux_amd64/pack grc $WORK/_/home/magnets/gist-2073020.a $WORK/_/home/magnets/gist-2073020/_obj/_go_.6 cd . /home/magnets/go/pkg/tool/linux_amd64/6l -o gist-2073020 -L $WORK $WORK/_/home/magnets/gist-2073020.a # _/home/magnets/gist-2073020 type..eq.strconv.leftCheat: out of memory This is rented virtualized instance with Xen, and I've seen weird things happening there already, so it's possible that it's a bug on their side. magnets@a:~/gist-2073020$ uname -a Linux a.magnets.im 2.6.26-2-xen-amd64 #1 SMP Wed Sep 21 05:57:38 UTC 2011 x86_64 GNU/Linux magnets@a:~/gist-2073020$ free -m total used free shared buffers cached Mem: 3383 255 3127 0 0 11 -/+ buffers/cache: 242 3140 Swap: 1953 48 1904 Code at: https://gist.github.com/2073020 it's a simple memcached client. $ sha1sum go.weekly.2012-03-13.linux-amd64.tar.gz 985f5131e67cf7fdb8081323d18a2324990e6945 go.weekly.2012-03-13.linux-amd64.tar.gz |
Re #38, thank you. I created issue #3458 to track that problem. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: