Sections/Contents
--- Summary/Short version
--- More detailed version

================================================================================

--- Summary/Short version (see "--- More detailed version" for details)

================================================================================

=============> Note: some of the commands may be biased towards the
zsh shell

Results;

go-1.4 builds sucessfully with all.bash script.
go-1.5 builds successfully with all.bash script.
go-1.6 build successfully with make.bash script.

Main problem affecting the three mentioned minor versions;

$ go version
go: error while loading shared libraries: libgcc_s.so.1: cannot open
shared object file: No such file or directory

Solved manually by
$ export LD_LIBRARY_PATH=$LIBRARY_PATH

$ go version
go version go1.6.2 linux/amd64

I suspect that not having LD_LIBRARY_PATH is also affecting the package
build, namely
the following snippets from the package code;

(delete 'validate-runpath)

(setenv "LD_LIBRARY_PATH" (getenv "LIBRARY_PATH"))

I have taken a look at the code related to gcc@4.9 lib output.  I know
I can add the following snippet;

(search-path-specification
(variable "LD_LIBRARY_PATH")
(files '("lib" "lib64")))

to the search-path-specification list for a given package.  Just when
looking at gcc@4.9 it's quite different. I'm wondering what would be
considered the correct way to accomplish this in the upstream package.

Problem affecting the minor version 6;

$ less $BUILD_LOG
...
which: no go_linux_amd64_exec
...
<End of log>

================================================================================

--- More detailed version

================================================================================

Using or testing out go-1.6.2;

$ export GUIX_BUILD_OPTIONS="--keep-failed --verbosity=3"
$ BUILD_LOG=${HOME}/tmp/logs/pre-guix-build.log
$ ./pre-inst-env guix build go@1.6.2 &>/dev/stdout &>${BUILD_LOG}
$ ./pre-inst-env guix environment --ad-hoc go@1.6.2
$ eval `./pre-inst-env guix environment --search-paths --ad-hoc
go@1.6.2`

$ go version
go: error while loading shared libraries: libgcc_s.so.1: cannot open
shared object file: No such file or directory

$ export LD_LIBRARY_PATH=$LIBRARY_PATH
$ go version
go version go1.6.2 linux/amd64

Build/run hello world
$ mkdir ~/tmp/go-hello-world && \
cd ~/tmp/go-hello-world
$ cat <<EOF > hello-world.go
package main

import "fmt"

func main() {
            fmt.Println("hello world")
            }
            EOF

Run the hello world
$ go run hello-world.go


Build and run the hello world
$ go build hello-world.go
$ ./hello-world


Build/run hello world with C code import
$ rm ./* # just cleaning up
$ cat <<EOF > hello.c
#include "hello.h"

void hello()
{
    printf("%s\n", "Hello World!");
    }
    EOF

$ cat <<EOF > hello.h
#ifndef _HELLO_H_
#define _HELLO_H_

#include <stdio.h>

void hello();

#endif /* _HELLO_H_ */
EOF

$ cat <<EOF > hello.go
package main

/*
#include <stdlib.h>
#include "hello.h"
*/
import "C"

func main() {
     C.hello()
     }
     EOF

$ go build
$ ./go-hello-world

Both hello world programs built and ran sucessfully. I have gotten
similar results with go-1.4.3. I haven't done this with go@1.5.4 but I
would expect similar results there also.

Main problem affecting the three mentioned minor versions;

$ go version
go: error while loading shared libraries: libgcc_s.so.1: cannot open
shared object file: No such file or directory

Solved manually by
$ export LD_LIBRARY_PATH=$LIBRARY_PATH

$ go version
go version go1.6.2 linux/amd64

I suspect that not having LD_LIBRARY_PATH is also affecting the package
build, namely
the following snippets from the package code;

(delete 'validate-runpath)

(setenv "LD_LIBRARY_PATH" (getenv "LIBRARY_PATH"))

I have taken a look at the code related to gcc@4.9 lib output.  I know
I can add the following snippet;

(search-path-specification
(variable "LD_LIBRARY_PATH")
(files '("lib" "lib64")))

to the search-path-specification list for a given package.  Just when
looking at gcc@4.9 it's quite different. I'm wondering what would be
considered the correct way to accomplish this in the upstream package.

Problem affecting the minor version 6;

$ less $BUILD_LOG
...
##### ../misc/cgo/testsovar

##### ../misc/cgo/testcarchive
which: no go_linux_amd64_exec in
(/tmp/guix-build-go-1.6.drv-0/go/bin:/gnu/store/sb1h89qyg17j4776qhjz0ximg8p1vqgc-go-1.6/bin:/tmp/guix-build-go-1.6.drv-0/go/src..//bin:/g
nu/store/avrs0mngdhwl4l1xn4r98j3bilrxlvmf-go-1.4.3/bin:/gnu/store/527yzcdcga89cpzm9mf9b786yz8sr99z-gcc-4.9.3/bin:/gnu/store/wbdfz4mjzr8kv5vds1a9h5f40ljjfaj2-rc-1.7.4/bin:
/gnu/store/abgjh1qaxd5fmg24d4wl3p1q8naskz4p-perl-5.22.1/bin:/gnu/store/ggmmcw327ny831gqd7zvi3hpl5fm23mn-tar-1.28/bin:/gnu/store/304ljrrivn98ds6zsv3lcrp5c8qyl8d5-gzip-1.6/
bin:/gnu/store/b3bmn7z2f68v76331k1vk47wv5d4g5xd-bzip2-1.0.6/bin:/gnu/store/z8vgpay1q450ndgil902xxxz5mq0b1qr-xz-5.2.2/bin:/gnu/store/knws2xhs2507r0f9qc3b45dn1fxmpi5g-file-
5.25/bin:/gnu/store/p2c0vfazcl5xzg1pjjcanzmdwvli4fnv-diffutils-3.3/bin:/gnu/store/fhwvc4i82dxfipkl5nqc54s6rfp7jjq9-patch-2.7.5/bin:/gnu/store/5n82r6pa03fzxkph4i589ycm2kay
7kid-sed-4.2.2/bin:/gnu/store/wimqywg0v6xjgrpfpnr2hb6r93qm5272-findutils-4.6.0/bin:/gnu/store/01q81q7lxwpkykghl4yc7d4g4yvpbbi6-gawk-4.1.3/bin:/gnu/store/jfj94hba68b4py44l
0imw1052qmp90dj-grep-2.22/bin:/gnu/store/34j2zmi69mqwrslpyizbi9mcxmn2hzgb-coreutils-8.24/bin:/gnu/store/jwg90sxflq78ikvggf3hkwyk39ikrnik-make-4.1/bin:/gnu/store/b1yqjimbd
h5bf9jnizd4h7yf110744j2-bash-4.3.42/bin:/gnu/store/sfxymqv7ggsg900yyaipg90r3sg42638-ld-wrapper-0/bin:/gnu/store/7s1ikfk5dyhq4s7p8jaas4yrr14d77dq-binutils-2.25.1/bin:/gnu/
store/sjvcirri2bg7q5hlrkaywhmxllik0cfx-gcc-4.9.3/bin:/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/bin:/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/sbi
n:/gnu/store/cf2pqc3xg14qpcpjc32xd65r51lsrd16-which-2.21/bin:/gnu/store/qyyb05g8zp914ds6ania5pkrkqfgn31v-pkg-config-0.29/bin:/gnu/store/yvbr4gi6phn3rnwvynscwgcddqf9cd8f-p
cre-8.38/bin:/gnu/store/5fx3vscv9pqjr1k0vyaqnpqlvvzl8rff-glibc-2.22/bin:/gnu/store/5fx3vscv9pqjr1k0vyaqnpqlvvzl8rff-glibc-2.22/sbin)
PASS
PASS
PASS
PASS
PASS
PASS

##### ../misc/cgo/testcshared
ok
...
<End of log>

A couple more test are run after and some are skipped but the test
ultimately fails.

-- 
Matthew Jordan
Sent with my mu4e