Go 1.12 Beta 1 is released

Hello gophers,

We have just released go1.12beta1, a beta version of Go 1.12.
It is cut from the master branch at the revision tagged go1.12beta1.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.12beta1
is by using the go command:
$ go get golang.org/dl/go1.12beta1
$ go1.12beta1 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.12beta1

To find out what has changed in Go 1.12, read the draft release notes:
https://tip.golang.org/doc/go1.12

Alla prossima,
Filippo for the Go team

Go 1.12 is the last release that will support binary-only packages.

What are the alternatives?

I need binary-only packages for packages that use cgo with non-standard environment variable values.

You can compile your C code into a set of .syso files without having
to compile your Go code into a binary package. See, for example, the
runtime/race package in the standard library.

Ian

How do I do what runtime/race does? Is it what I want?

I have a package with C and Go files. I want to install that package. Then I want to import that package into a program, and build that program without recompiling the package. Because recompile fails.

How do I do that? This was an issue before, and the provided solution: after installation, mark the source as binary-only. That is a bit of a pain, but it works.

Starting with Go 1.13, Go is going to make its users work more difficult again. Why?

I just want to install a package and use it, without having to worry about external stuff.

I assume that the recompile fails because compiling the C code fails.
You should compile the C code yourself, producing a .syso file. You
should add that .syso file to your package directory. You should
remove the C code from your package directory--you can still put it in
a subdirectory, of course, for reference. Then a Go program can
import your package, compile the Go code as usual, and use the .syso
file for the C code. Hopefully that won't be any more painful than
the approach you are using today, although it is different.

The reason for the change is that binary packages are hard to support
correctly. There are many ways to modify how Go code is compiled,
with options like -buildmode and -gcflags. If those options do not
match exactly how the binary package was built, it's easy for there to
be a silent error in the resulting program. That is not a good
experience.

Ian

If you were able to use Go binary packages, then I don't understand
why this is not an option. The Go binary package must have included
compiled versions of the C code. Perhaps I completely misunderstand
what you want to do.
If I understand you correctly, you can do this by setting the
CGO_CFLAGS and CGO_LDFLAGS environment variables when you run `go
get`.

Ian

Ian Lance Taylor <ia...@golang.org> schreef op 19 december 2018 23:27:13 CET:
They do not. They have Go code and C code. They are installed with go get. Then I add a file to the package source code that marks it as binary package. After any upgrade of Go or the package, I remove the binary marker, and repeat the procedure.
I want to provide packages in a environment where not all resources are available in a standard location (because of access restrictions in the organisation), packages that can only be installed with options relevant to that environment. I want multiple users to be able to import those package without them having to worry about environment settings.

In practice, this mostly means including into the final program the path to some C libraries (rpath).

Also in our set-up, the command 'go' is a wrapper script that adds a non-standard location to the end of GOPATH.
Yes, that used to work for older versions of Go. It doesn't work since Go a few versions back. Now building any program that imports the package, directly or indirectly, needs to set those same CGO_CFLAGS and CGO_LDFLAGS environment variables.



--
Peter Kleiweg
http://pkleiweg.home.xs4all.nl

How about this:

Move the C files to a subdirectory. Write a script or Makefile that
compiles the C files into a .syso file in the main package directory,
using flags that you specify. Fetch the package using `go get -d`.
Run the script with the appropriate flags to generate the .syso file.
At that point `go build` should work.

Ian

Ian Lance Taylor <ia...@golang.org> schreef op 20 december 2018 00:06:58 CET:
The C files are part of the package. This would mean, downloading the package and reorganize it.

I was thinking there might be a better way. Add a file with local configuration, a file that imports '"C" and sets CFLAGS and LDFLAGS, without modifying the official package files. This works, except for packages that rely on pkg-config. I don't see how I can modify the contents of PKG_CONFIG_PATH in a Go file.

I was imagining that this rearrangement would be done at the package
source, not each time it was downloaded.
Sure, that could work too.

I don't understand why pkg-config would need to be correct on a
specific system. Why would pkg-config be incorrect?

Ian

Ian Lance Taylor <ia...@golang.org> schreef op 20 december 2018 16:47:20 CET:
That would be nice, but the package developers are not on our payroll. They do not cater for our odd requirements.
Sometimes, standard systems are too rigid. Things clash. Sometimes, you have to bend the accepted practices to get very odd bunches of software to work together. So you work in an odd environment. The Gnu build system handles this very well. It gives you options to tweak anything. In comparison, Go is rigid, and becoming more rigid. It assumes too much sameness on development platforms.

Why would pkg-config be incorrect? Who cares. I just want to be able to fix it, when I need to. And I need to.

Adding the file with the local configuration should work just as well
when you need to adjust pkg-config results as it would for a package
that does not use pkg-config.

I'm sorry you have trouble with the go tool. But to me it sounds like
you were using binary packages as a hack to get around that trouble,
not as a clean solution. There are good reasons why binary packages
do not work in general, as I outlined earlier.

It sounds like you should be using a more flexible tool, such as make,
rather than trying to force-fit your complex and unusual scenario into
the go tool.

Ian

Ian Lance Taylor <ia...@golang.org> schreef op 20 december 2018 19:20:13 CET:
No it doesn't. Unless I modify the original code, there is no way to switch off a failing call to pkg-config. I don't think modifying third-party package files is good idea.
I don't want to use binary packages. But at the moment, it's the only working solution that doesn't require modifying third-party package files.
I don't need make. A simple script will do. Or rather, it should. I can install the packages, but I can't import them because Go is too limited to remember the necessary environment settings. Starting from Go 1.14 I can only fix it by modifying files that should not be modified.
Y

You said you use a wrapper script around go tool.
Then you already have a place where you can fiddle at will.
There you may have "the necessary environment settings".

> I don't need make
You need a build tool. Any one, be it an ad-hoc bash script
or gradle with its insane configs. Or a Mage [1].

Today, go picks binary packages only for you and for very few
others (see [2]) at the expense of valuable go dev-team time.

>>> [ Peter Kleiweg wrote at 12/20/2018 17:01:55 CET ]
[1] https://github.com/magefile/mage
[2] https://github.com/golang/go/issues/28152

hope this helps,

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

In your go tool wrapper set the PKG_CONFIG environment variable to
something that does what you want. E.g., does nothing, to let you use
the fake .go file that you added.

Ian

Ian Lance Taylor <ia...@golang.org> schreef op 20 december 2018 23:10:17 CET:
I prefer to keep package-specific configuration with the package, not polluting the environment unless the package is used. There may be incompatible settings between packages. But it is an option.

With my suggestion I think you should be able to keep the
package-specific configuration with the package. Add the file you
described earlier, which uses #cgo CFLAGS and #cgo LDFLAGS as needed.
When using the go tool, set PKG_CONFIG to point to a script that
prints nothing. The go tool should agglomerate the CFLAGS/LDFLAGS
from the new file and from pkg-config (the latter being nothing). I
hope.

Ian

...
Sorry, I cannot use the issue tracker for lack of an Github account,
so I'm reporting here instead*:

Today I tried to compile Go 1.12 beta 1 from source and the process
got stuck for the last ~20 minutes

==== jnml@e5-1650:~/go/src> git checkout go1.12beta1
Note: checking out 'go1.12beta1'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b <new-branch-name>

HEAD is now at e3b4b7baad runtime: use QPC for nanotime and time.now
on windows/arm
==== jnml@e5-1650:~/go/src> git status
HEAD detached at go1.12beta1
nothing to commit, working tree clean
==== jnml@e5-1650:~/go/src> time ./all.bash
Building Go cmd/dist using /home/jnml/go1.4.
Building Go toolchain1 using /home/jnml/go1.4.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for linux/amd64.

##### Testing packages.
ok archive/tar 0.086s
ok archive/zip 1.168s
ok bufio 0.088s
^Cgo build regexp: /home/jnml/go/pkg/tool/linux_amd64/compile: signal: interrupt

real 18m35,138s
user 3m28,947s
sys 0m19,605s

==== jnml@e5-1650:~/go/src>

There stuck process as seen in top is

25119 jnml 20 0 122056 34356 9008 R 203,65 0,210 19:44.57
/home/jnml/go/pkg/tool/linux_amd64/compile -o
/tmp/go-build884388659/b081/_pkg_.a -trimpath
/tmp/go-build884388659/b081 -p regexp -std -complete -buildid
lXgdJ55enkn+

Here is openSUSE Leap 15.0/64 bit, x86_64 architecture.

----

*: It would be nice if the Go team could possibly figure out some way
how to make it easier to use input from people willing to participate
in the project without requiring them to have a Microsoft owned
account. There seems to be no obvious connection between the Microsoft
corp. and maintaining the Go project.

Thanks, this is probably https://golang.org/issue/29385, which should
be fixed in the next beta.
Yes, it would be nice, but I'm not sure what to do. I think it's
clear that we need an issue tracker, and we don't particularly want to
run our own. Want to raise this as a separate thread? In particular
we would need to know the requirements: having some sort of identity
seems like a requirement, but what sorts of identity would be
acceptable?

Ian