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

feedback for binary distro linux-amd64 #3211

Closed
adg opened this issue Mar 6, 2012 · 40 comments
Closed

feedback for binary distro linux-amd64 #3211

adg opened this issue Mar 6, 2012 · 40 comments

Comments

@adg
Copy link
Contributor

adg commented Mar 6, 2012

Please describe your experiences with the linux-amd64 binary distribution, both positive
and negative, here. Thanks.

http://code.google.com/p/go/downloads/list
@alberts
Copy link
Contributor

alberts commented Mar 6, 2012

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?

@alberts
Copy link
Contributor

alberts commented Mar 6, 2012

Comment 2:

Might be a good idea to sign the tarballs.
http://www.gnu.org/software/swbis/

@gopherbot
Copy link

Comment 3 by remigius.gieben:

Works on Ubuntu 10.10

@gopherbot
Copy link

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

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

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)

@alberts
Copy link
Contributor

alberts commented Mar 7, 2012

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.

@alberts
Copy link
Contributor

alberts commented Mar 7, 2012

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?

@alberts
Copy link
Contributor

alberts commented Mar 7, 2012

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

@alberts
Copy link
Contributor

alberts commented Mar 7, 2012

Comment 10:

Some ideas for solving the memcpy issue:
http://stackoverflow.com/questions/8823267/linking-against-older-symbol-version-in-a-so-file

@ianlancetaylor
Copy link
Contributor

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.

@alberts
Copy link
Contributor

alberts commented Mar 7, 2012

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.

@alberts
Copy link
Contributor

alberts commented Mar 7, 2012

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

@rsc
Copy link
Contributor

rsc commented Mar 7, 2012

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

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

@alberts
Copy link
Contributor

alberts commented Mar 7, 2012

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.

@rsc
Copy link
Contributor

rsc commented Mar 7, 2012

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.

@alberts
Copy link
Contributor

alberts commented Mar 7, 2012

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

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

Comment 20 by dahankzter:

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

@gopherbot
Copy link

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

@rsc
Copy link
Contributor

rsc commented Mar 8, 2012

Comment 22:

You can drop GOARCH and GOOS.

@dlintw
Copy link

dlintw commented Mar 9, 2012

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

@rsc
Copy link
Contributor

rsc commented Mar 9, 2012

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

@alberts
Copy link
Contributor

alberts commented Mar 11, 2012

Comment 25:

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

@gopherbot
Copy link

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.

@dlintw
Copy link

dlintw commented Mar 14, 2012

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

@dlintw
Copy link

dlintw commented Mar 14, 2012

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

@dlintw
Copy link

dlintw commented Mar 14, 2012

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

@adg
Copy link
Contributor Author

adg commented Mar 14, 2012

Comment 30:

dlin please file separate issues for #2 and #3

@dlintw
Copy link

dlintw commented Mar 14, 2012

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

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

@nictuku
Copy link
Contributor

nictuku commented Mar 18, 2012

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

@4ad
Copy link
Member

4ad commented Mar 20, 2012

Comment 34:

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

@ajstarks
Copy link
Contributor

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

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

@adg
Copy link
Contributor Author

adg commented Mar 27, 2012

Comment 37:

Labels changed: added priority-later.

@gopherbot
Copy link

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.

@rsc
Copy link
Contributor

rsc commented Apr 2, 2012

Comment 39:

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

@adg
Copy link
Contributor Author

adg commented Apr 19, 2012

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.

@adg adg added done labels Apr 19, 2012
@adg adg self-assigned this Apr 19, 2012
@golang golang locked and limited conversation to collaborators Jun 24, 2016
@rsc rsc unassigned adg Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants