[go-nuts] Re: Fail build on missing dependencies
Thank you for your overview and the links. Using -mod=readonly together with go install indeed does what I want. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Fail build on missing dependencies
Consider the following scenario. I commit a version of my project and I'm happy with the dependencies and their versions that are listed in my go.mod file. I push my code to the central repo and the CI starts to build the project with go get or go install. Because the CI builds for a GOOS/GOARCH pair that I did not try On My Machine, the list of .go files to be built changes. One of the newly added files has a dependency on a module that is not yet recorded in the go.mod file. go get/install promptly adds the dependency and fetches it from the internet. As a result, I get a binary that is built with dependencies that I don't know about, the versions of the dependencies being whatever was freshest that day. How do I prevent this situation? I do not want to forbid go get/install to fetch modules from the internet with GOPROXY. I'm fine that go get/install fetches the dependencies with versions/hashes recorded in go.mod and go.sum. I would only like for the build to fail if there are missing dependencies. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Cross compiling sers (with CGO) to Android
This is embarassing, but setting GOOS=android fixed the issue. I was under the impression that android builds were only supported with an addition to the toolchain. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Cross compiling sers (with CGO) to Android
I am trying to cross compile the sers library from github.com/distributed/sers to arm64 android. I have an Android SDK on my computer and I point $AR, $CC, $CXX and so on to the relevant programs. In a checkout of the sers library (git clone https://github.com/distributed/sers.git) I run: ~/tmp/sers$ CGO_ENABLED=1 GOARCH=arm64 GOOS=linux go get # runtime/cgo /home/joe/android/toolchain/bin/../lib/gcc/aarch64-linux-android/4.9.x /../../../../aarch64-linux-android/bin/ld: cannot find -lpthread clang60: error: linker command failed with exit code 1 (use -v to see invocation) My go env is: ~/tmp/sers$ CGO_ENABLED=1 GOARCH=arm64 GOOS=linux go env GOARCH="arm64" GOBIN="" GOCACHE="/home/joe/.cache/go-build" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/home/joe/gop" GOPROXY="" GORACE="" GOROOT="/usr/local/go" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" CC="aarch64-linux-android-clang" CXX="aarch64-linux-android-clang++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build095666131=/tmp/go-build -gno-record-gcc-switches" I am using Go 1.11. I suspect that the toolchain attempts to link against -lpthread, but this is not necessary, since pthread functionality is included in the C library in Android. Does anybody know how to circumvent this build problem? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Thread local error information when wrapping lib with cgo
Thanks for the clarification. I suppose internal UnlockOSThread does not override the runtime.LockOSThread by my code from the outside? Not really. On error you could malloc a buffer, copy in the string, > and return the buffer to Go. In Go you could copy the buffer into Go > memory and C.free the buffer. That approach isn't any better than > what you are doing today, but it would work (it does copy the buffer > twice, but presumably errors are not the common case). > That's a good suggestion. I suspect that in a typical usage an error will lead to program termination, connection termination or user interaction via some user interface, so the performance of the two allocations and the two copies will not be an issue. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Thread local error information when wrapping lib with cgo
I am currently wrapping a proprietary library with cgo.
About error reporting, the library documentation says "Every function that
can fail returns at least boolean or pointer value that can be used to
detect error state (false and NULL means error, every other value means
success). If such error happens, details about it can be queried using
thelib_error(). The error information is thread-local."
So when calling a function from the library, in C I write about the
following code:
bool ret = thelib_dosomework(...);
if (!ret) {
// call has to be in same thread as call to thelib_dosomework() above
int errcode = thelib_error(buf, BUF_SIZ, null);
fprintf(stderr, "error %d: %s\n", errcode, buf);
return false;
}
My current approach to call a C function from the library and get the
corresponding error information looks like this:
func callIntoTheLib() error {
runtime.LockOSThread()
defer runtime.UnlockOSThread()
ret := C.thelib_dosomework(...)
if !ret {
return extractErrorFromTheLibError()
}
return nil
}
func extractErrorFromTheLibError() error {
var buf [1024]byte
var outsize C.size_t
errcode := C.thelib_error((*C.char)(unsafe.Pointer((&errbuf[0]))), C.
size_t(len(errbuf)), &outsize)
// not wrapping in struct type for brevity
return fmt.Errorf("error %d: %s", errcode, buf[:outsize])
}
Is this sensible? Looking at the runtime implementation,
LockOSThread/UnlockOSThread seem to be really simple as the only save a
couple of words in goroutine storage. I don't mind about using up an OS
thread as there will not be a large number of concurrent calls into the
library. Also, calls into C use up one thread anyway and the majority of
time will be spent in the payload call, not in thelib_error(), which is a
short and fast function.
Another approach I was thinking about was to copy the error message and
code to memory in C code, but with this approach I always have to have a
preallocated buffer for an error that might not happen.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Porting Go to New Platforms
Hi Efraim You can take a binary built for linux/386, copy it to a QNX system and run it. The QNX loader will load and execute these binaries. Of course the program will not get very far during its execution, I think it crashes at the first "int $0x80" instruction, which is to be expected. This what I mean by "some success executing": instructions from the program get run until the process hits an instruction that does not make sense for a QNX process. I also wrote Hacking QNX syscalls via int $0x28 directly into runtime.rt0_linux_386, I > have been able to write to stdout and exit the program gracefully. That means I edited rt0_linux_386.s, specifially the function _rt0_386_linux, which begins with the first instruction run by a Go program. I wrote code, in this assembler function, to synthesize an _IO_WRITE message and call MsgSendv through the syscall interface, which works by executing "int $0x28". I never had anything close to a QNX port. The only thing I showed is that the output of the current linux/386 toolchain can be used to run code on a QNX system. Are your port efforts public? Cheers, Michael On Friday, June 24, 2016 at 8:57:21 PM UTC+2, Efraim Sealman wrote: > > Hello, > > Can you please share some info about how you made the go binary to run on > QNX? > > Aram, > > Can you please share what have you done for solaris to support go > compiler? Watched the video that you posted and couldn't get much from it. > Couldn't find the slides though. We're looking to make the same thing for > QNX and need your help. Any info is appreciated . > > Thanks, > Efraim Sealman > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
