Re: [go-nuts] cgo: undefined reference to `stdout'

[andrey mirtchovski]

this is bug 10715: https://github.com/golang/go/issues/10715

a more idiomatic solution is available here:
https://github.com/golang/go/blob/master/misc/cgo/stdio/stdio.go

On Sun, Jul 31, 2016 at 1:22 AM, P Q  wrote:
> https://play.golang.org/p/4XZSmyRkZa
>
> I've got error message when building the code as follows:
>
> C:\Users\Home\AppData\Local\Temp\go-build437760086\command-line-arguments\_obj\_cgo_main.o:_cgo_main.c:(.data+0x0):
> undefined reference to `stdout'
> collect2.exe: error: ld returned 1 exit status
>
> I don't know what's something wrong as I'm using no external library, and
> using just standard library. I suspect what cause the error is associated
> with linker, but I'm not sure. How can it be fixed to be compiled?
>
> I know workaround that make wrapping function in C side and use the function
> in Go side like this: https://play.golang.org/p/NncAFmlPXN. I do expect true
> solution to this problem, not workaround.
>
> Note: version of go on this computer is go1.6.2 windows/amd64.
>
> --
> 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.

-- 
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] Compiling C files conditionally

[andrey mirtchovski]

there are a few problems with your project as presented:

- your .c file has a (mistyped) directive to not build on linux on
line 1: "/ build !linux". this needs to go

- your a_non_linux.go file is not idiomatic. it makes much more sense
to specialize the linux code in a separate file and leave all the
other code in non-specialized .go files, rather than saying a.go is
"linux-only" and everything else is "non-linux only".

given that, with almost zero modifications I am able to compile your
code on the few linux platforms I have, so I am suspecting that
something in your configuration is wrong, not with Go.

here's an example:
https://play.golang.org/p/6NpoZFu50D

-- 
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] Re: why treat int and []int differently here?

[andrey mirtchovski]

> @all, thanks for the explanation!

in my view, all the "details" come from reasoning about Go through the
sieve of other programming languages. nothing wrong in doing that, as
long as the original intention is understood. for me, Go will always
be looked through the sieve of C, in particular the kind of C the
authors wrote for Plan 9. even though some of the decisions may have
looked strange to me at one point or another, summarily Go is much
more complete.

the standard library implementation on the other hand should be looked
through the sieve of Go and Go alone. and perhaps the go1
compatibility guarantee :)

-- 
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] export struct method to C-code as callback (cgo-related)

[andrey mirtchovski]

If the library made no provision for the caller to give a unique token
which would help to identify it in the callback then that library does
not expect to have more than one caller-and-callback in play at any
one time, or, even worse, expects you to arrange some thread-local
storage in the caller to resolve the correct one. Without knowing more
about the library there isn't much to say, except that you should be
able to serialize all calls into it on the Go side, leaving only one
possible *A with an outstanding function call at a time. This is going
to be slow.

-- 
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.