Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

feedback for binary distro linux-amd64 #3211

Closed
adg opened this Issue · 40 comments

9 participants

Andrew Gerrand Albert Strasheim GopherBot Ian Lance Taylor Russ Cox Daniel YC Lin Yves Junqueira Aram Hăvărneanu Anthony Starks
Andrew Gerrand
Owner
adg commented
Please describe your experiences with the linux-amd64 binary distribution, both positive
and negative, here. Thanks.

http://code.google.com/p/go/downloads/list
Albert Strasheim

Comment 1:

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?
Albert Strasheim

Comment 2:

Might be a good idea to sign the tarballs.

http://www.gnu.org/software/swbis/
GopherBot
Collaborator

Comment 3 by remigius.gieben:

Works on Ubuntu 10.10
GopherBot
Collaborator

Comment 4 by robl.luobo:

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.
GopherBot
Collaborator

Comment 5 by wkharold:

Ubuntu 11.10 Server AMD64

ubuntu@gs02:/tmp$ uname -a
Linux gs02 3.0.0-12-server #20-Ubuntu SMP Fri Oct 7 16:36:30 UTC 2011 x86_64 x86_64
x86_64 GNU/Linux

Had to change ownership and permissions post untar. Beyond that no issues.
GopherBot
Collaborator

Comment 6 by wkharold:

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)
Albert Strasheim

Comment 7:

chmod -R a+rX,ug+w /path/to/go and tar --owner=root --group=root can probably help to 
normalise permissions in the tarball.
Albert Strasheim

Comment 8:

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?
Albert Strasheim

Comment 9:

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
Ian Lance Taylor
Collaborator

Comment 11:

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.
Albert Strasheim

Comment 12:

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.
Albert Strasheim

Comment 13:

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
Russ Cox
Owner
rsc commented

Comment 14:

"""
Also, RHEL/CentOS 5 is still going to be with us until 2017 or even 2020:
"""

There's also PDP-1 at the Computer History Museum running
programs written in 1962.  That doesn't mean Go has to run on it.
GopherBot
Collaborator

Comment 15 by jamslam:

Works perfectly with Archlinux :-)

# uname -a
Linux Ocelot 3.2.7-1-ARCH #1 SMP PREEMPT Tue Feb 21 09:51:29 CET 2012 x86_64 AMD
Phenom(tm) II X6 1075T Processor AuthenticAMD GNU/Linux
Albert Strasheim

Comment 16:

Comparing one PDP-1 at the Computer History Museum to probably hundreds of thousands of
servers running RHEL/CentOS 5 makes complete sense. Especially when you're developing a
systems programming language that you actually want people to use. But okay.
Russ Cox
Owner
rsc commented

Comment 17:

Old operating systems will always be with us.
The fact that in 2020 people will be running a
Linux distribution that forked the kernel 13 years
earlier does not mean we have to support it.
Albert Strasheim

Comment 18:

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.
:-)
GopherBot
Collaborator

Comment 19 by jimteeuwen:

$ uname -a
Linux xxxx 3.2.8-1-ARCH #1 SMP PREEMPT Mon Feb 27 21:51:46 CET 2012 x86_64 Intel(R)
Core(TM)2 CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux

go.weekly.2012-03-04.linux-amd64 is working perfectly.
GopherBot
Collaborator

Comment 20 by dahankzter:

I have the latest Archlinux and everything worked fine after resetting the rights which
was completely borked.
GopherBot
Collaborator

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
Russ Cox
Owner
rsc commented

Comment 22:

You can drop GOARCH and GOOS.
Daniel YC Lin

Comment 23:

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
Russ Cox
Owner
rsc commented

Comment 24:

The tar command in the instructions says xzf.
It does not say xzpf.  Why is everyone having problems
with the owner and group on the files?

Russ
Albert Strasheim

Comment 25:

I'm guessing that if you untar as root, you actually get xzpf.
GopherBot
Collaborator

Comment 26 by allard.guy.m:

Everything I have to test here works with the March 13 build.  Does on Win7 as well.  I
will test the Mac build tomorrow.
Daniel YC Lin

Comment 27:

March 13 build problem: permission denied for the mode is 0750, it is 0755 for better,
and all source/library should be 0644 instead of 0640
Daniel YC Lin

Comment 28:

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
Daniel YC Lin

Comment 29:

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
Andrew Gerrand
Owner

Comment 30:

dlin please file separate issues for #2 and #3
Daniel YC Lin

Comment 31:

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
GopherBot
Collaborator

Comment 32 by vendion:

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
Yves Junqueira

Comment 33:

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
Aram Hăvărneanu
Collaborator

Comment 34:

Comment #31 suggested stripping binaries. Please don't do that :).
Anthony Starks

Comment 35:

on Amazon EC2 Linux instance (AMI:
ebs/ubuntu-images/ubuntu-natty-11.04-amd64-server-20110426 (ami-1aad5273)

unzip 2012-03-22 using installation script, test by installing svgo, running client,
runs fine
GopherBot
Collaborator

Comment 36 by jimteeuwen:

weekly.2012-03-22 on a fresh install of Arch Linux is working as intended.

$ uname -a
Linux purgatory 3.2.12-1-ARCH #1 SMP PREEMPT Mon Mar 19 17:50:01 CET 2012 x86_64
Intel(R) Core(TM)2 CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux
Andrew Gerrand
Owner

Comment 37:

Labels changed: added priority-later.

GopherBot
Collaborator

Comment 38 by Ryan.FireBall:

I installed this, and it didn't work. I had to run "sudo find /usr/local/go -type d
-exec chmod a+x \{\} \;" for it to work.
Russ Cox
Owner
rsc commented

Comment 39:

Re #38, thank you.  I created issue #3458 to track that problem.
Andrew Gerrand
Owner

Comment 40:

Closing these issues now that Go 1 is out. Please create a new issue for any problem
with the binary distributions.

Status changed to Done.

Andrew Gerrand adg self-assigned this
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.