On Wed, May 18, 2016 at 02:06:32PM -0400, Matthew Jordan wrote: > Thanks to the initial work done by "Efraim Flashner > <efr...@flashner.co.il>" and a little encouragement ("tweeaking" lol) > from Ludovic Courtès <l...@gnu.org> I have done some work on the golang > compiler package.
I'm very happy to see more work being done to bring Golang into Guix! > +;;; GNU Guix --- Functional package management for GNU > +;;; Copyright © 2015, 2016 Efraim Flashner <efr...@flashner.co.il> > +;;; Copyright © 2016 Matthew Jordan <matthewjordandev...@yandex.com> > +;;; > +;;; This file is an addendum GNU Guix. We should remember to update this line when we are ready to merge the patch. > +(define-public go-1.4 [...] > + ;; Disable the unix socket test > + (system* "sed" "-i" "/TestShutdownUnix/areturn" > "net/net_test.go") Later, I think we should replace the use of `sed` with more uses of (substitute). > +(define-public go-1.5 > + (native-inputs > + `(("gccgo" ,go-1.4) > + ,@(alist-delete "gccgo" (package-native-inputs go-1.4)))))) Is there a reason to call go-1.4 'gccgo' here? Is it an artifact of copy-pasting the go-1.4 package definition, which uses 'gccgo' in the pre-build and build phases? > 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 This is the big problem with all of our attempts so far. > Solved manually by > $ export LD_LIBRARY_PATH=$LIBRARY_PATH As Ricardo said in another thread, we should really figure out how to make this unecessary.