You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Dominique Leuenberger 280cb9b088 Accepting request 1079833 from devel:languages:go
- Add subpackage go1.x-libstd for compiled shared object
  only on Tumbleweed at this time.
  * Main go1.x package included in previous versions
  * Split into subpackage that can be installed standalone
  * Continues the slimming down of main go1.x package by 40 Mb
  * Experimental and not recommended for general use, Go currently has no ABI
  * Upstream Go has not committed to support buildmode=shared long-term
  * Do not use in packaging, build static single binaries (the default)
  * Upstream Go go1.x binary releases do not include
  * go1.x Suggests go1.x-libstd so not installed by default Recommends
  * go1.x-libstd does not Require: go1.x so can install standalone
  * Provides go-libstd unversioned package name
  * Fix build step -buildmode=shared std to omit -linkshared
- Packaging improvements:
  * go1.x Suggests go1.x-doc so not installed by default Recommends
  * Use Group: Development/Languages/Go instead of Other
  * On Tumbleweed bootstrap with current default gcc13 and gccgo118
  * On SLE-12 aarch64 ppc64le ppc64 remove overrides to bootstrap
    using go1.x package (%bcond_without gccgo). This is no longer
    needed on current SLE-12:Update and removing will consolidate
    the build configurations used.
  * Change source URLs to as per Go upstream (forwarded request 1079832 from jfkw)

2 months ago
.gitattributes Accepting request 903995 from home:jfkw:branches:devel:languages:go 2 years ago
README.SUSE Accepting request 903995 from home:jfkw:branches:devel:languages:go 2 years ago
_service Accepting request 903995 from home:jfkw:branches:devel:languages:go 2 years ago
dont-force-gold-on-arm64.patch Accepting request 962203 from home:dirkmueller:Factory 1 year ago
gcc-go.patch Accepting request 967627 from home:jfkw:branches:devel:languages:go 1 year ago
go-rpmlintrc Accepting request 903995 from home:jfkw:branches:devel:languages:go 2 years ago
go.gdbinit Accepting request 966741 from home:jfkw:branches:devel:languages:go 1 year ago
go1.17.13.src.tar.gz Accepting request 992075 from home:jfkw:branches:devel:languages:go 10 months ago
go1.17.changes Accepting request 1079832 from home:jfkw:branches:devel:languages:go 2 months ago
go1.17.spec Accepting request 1079832 from home:jfkw:branches:devel:languages:go 2 months ago
llvm-89f7ccea6f6488c443655880229c54db1f180153.tar.xz Accepting request 903995 from home:jfkw:branches:devel:languages:go 2 years ago


Updated: 05.05.2012
Authors: Graham Anderson, <>



Maintainers: Sascha Peilicke (saschpe),
             Graham Anderson (andtecheu)


Go toolchain environmental variables are configured via, which is
installed to /etc/profile.d/

Packaging guidelines and an RPM spec file recipe for packaging third party Go
libraries can be found on the openSUSE wiki:

The openSUSE go package uses the standard Go distribution toolchain, with a
a small patchset to modify a few of the toolchain commands to suit our
environment and packaging needs.

This means that many of the standard go toolchain commands are not inside a
users PATH, but rather are invoked and used via the "go" command. Should you
wish to script or manually use the commands, the install location on a 64 bit
system is /usr/lib64/go/pkg/tool/linux_amd64

The "go" tool, the "godoc" document server are inside a users PATH.

We currently don't support the gccgo implementation, this is not for
any other reason than contributer and maintainer time constraints.


As of yet, there are no man pages for the standard Go distribution toolchain,
please see the documentation provided by the "godoc" command. Man pages are
slated to be included in the release in future.

One of the diffs from the maintained patchset adds the distro specific doc and
source file locations of the *-doc RPM packages to the virtual filesystem of
the "godoc" documentation server. That is to say, as long as packages follow
the Go packaging guidelines, API and other documentation should always be
available via the godoc server if the packages "doc" RPM is installed.


Go standard library packages are installed to a location in $GOROOT, which is
defined as /usr/lib64/go on 64bit systems.

Third party package binaries are installed to the default system wide
$GOPATH entry. On 64bit systems the location /usr/lib64/go/contrib is used.
This is specified in the macros.go RPM macro definition file that is part of
the main Go package and is used for packaging most third party Go libraries.

The reasons binary packages are installed to a GOPATH entry instead of GOROOT
are mainly to do with how the Go toolchain prioritises and behaves with
packages installed to the same location as the Go std library.

By installing third party packages to a system-wide GOPATH entry location,
we can ensure that no packages clobber the standard library namespace or file
tree. Additionally we can support binary only packages, which as of Go 1.1
will only be supported outside of the $GOROOT.

There are additional benefits to this location; such as allowing users and
developers to prioritise linking from their own user defined GOPATH, which
defaults to $HOME/go configured via /etc/profile.d/ config. This has
particular benefit for development workflows.

For Go 1.1 and beyond, building and linking with binary only pacakges will
only be supported with the following caveat. Package source code must not
exist in the same GOPATH segment as the binary package .a archive file.

If both the binary archive (.a) and the package source are installed to the
same GOPATH segment, then the "go build" or "go install" command will
prioritise building the software using package sources before using package
binary archives. A side effect of this is that is actually possible to have
source code only third party packages.
To summarise the priority of binary package linking and building:

  1. Any source files or binary packages in $GOROOT are considered first. Any
     binary packages in $GOROOT that are considered "stale" by the build tools
     are ignored in favour of the package source.

  2. $GOPATH is considered next for import statements. GOPATH is a colon
     delimited list of paths. GOPATH segments are examined by the build tools
     in a FIFO manner, left to right.

     Both a system wide and a user GOPATH segment are configured by default,
     the user GOPATH segment takes priority over the system segment to allow
     flexibility for development workflows.

     The default user GOPATH is:


     The default root user GOPATH is:


  3. For Go < 1.1, If both the source and binary archive is available for a
     package import in the same GOPATH segment, the binary archive will take
     precedence and will be linked during compilation.

     For Go >= 1.1 If the package source is avaiable in the GOPATH segment, it
     will always be used in preference to the binary