cgo - 'runtime.h' file not found in MacOSX

[DM]

I am trying to execute the cgo program as mentioned here

package main

    /*
    #include "runtime.h"

    int goId() {
            return g->goid;
    }
    */
    import "C"
    import "fmt"

    func main() {
     x := C.goId()
     fmt.Printf("Id - %d", x)
    }

On running the above program I am getting the below error:-

jab-MacBook-Pro-4:src debraj$ go build gid.go
# command-line-arguments
./gid.go:4:10: fatal error: 'runtime.h' file not found
#include "runtime.h"
         ^
1 error generated.

If I change the header to be like below:-

#include <objc/runtime.h>

then it is giving me the below error:-

jab-MacBook-Pro-4:src debraj$ go build gid.go
# command-line-arguments
./gid.go:7:9: error: use of undeclared identifier 'g'
        return g->goid;
               ^
1 error generated.

Environment:-

• MacOSX - 10.11.6
• Go - 1.7.3

Can someone let me know how can I run the above program in MacOSX?

[Tamás Gulácsi]

2016. december 15., csütörtök 12:51:28 UTC+1 időpontban DM a következőt írta:

I am trying to execute the cgo program as mentioned here

That's not a cgo program there, but a Go program, which uses the gc compiler's affinity to compile C programs into the resulting binary.

But since Go 1.5.0, that C backend is removed (the last version is 1.4.2), so that side effect has vanished.

BTW why would you need the ID of the goroutine? That's Pandora's box, and frowned upon here.

[Debraj Manna]

Exactly for the same use case as mentioned in this thread

https://groups.google.com/forum/#!msg/golang-nuts/zuWWBHKn6iw/FKjTGPItzcYJ

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Z7qTnu3V0dI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gulácsi Tamás]

Just attach your pimped logger to the Context, and use some structured logger such as github.com/go-kit/kit/log, and pass a logger.With("reqid", reqID) specialized logger.

Way easier than hacking out the goroutine id just to have a goroutine-local storage,

and waay more reliable - for example you can pass your Context (or just the logger) through a channel to another (worker) goroutine, and won't lose context information.

To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Debraj Manna]

If I get you correctly I still have to pass the Context (with logger attached) to all the functions where I wish to do the logging.

If my understanding is not correct then can you please give me a small example?

To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.

[Gulácsi Tamás]

Debraj Manna <subhara...@gmail.com> ezt írta (időpont: 2016. dec. 15., Cs, 14:12):

If I get you correctly I still have to pass the Context (with logger attached) to all the functions where I wish to do the logging.

If my understanding is not correct then can you please give me a small example?

No, you're right: you have to pass around the Context, or the logger.

[Debraj Manna]

Actually that is my problem changing all functions to pass on the context.

[zhex...@gmail.com]

I compile your snippet in `Ubuntu`. It doesn't work either. 

cheers 

[Dragos Harabor]

You may or may not agree with this but Peter makes the strong point of making all dependencies explicit (skip to around 31:40 if you don't want to watch it all):

https://www.infoq.com/presentations/go-patterns

Even "hiding" the logger in Context is questionable many times. And yes, it may make your API "ugly" or force you to update a bunch of function signatures, but it's a better alternative to obfuscating behavior in the code by using globals, using thread local storage or hiding things in Context when they don't belong there.

[Gulácsi Tamás]

I think this is a little bit gray area. I don't really depend on the logger, as I use the global/default instance if not provided in the Context.

AFAIK Context is for the actual request, it should hold values only that specific for that request. A logger instrumented with that request (ID, parsed parameters ... etc) is such a value. But of course Peter Bourgon argues it's not :)

Maybe all these could be avoided, if Context could only hold string values and keys, so it would be less easy and compelling to shovel values in it!