On Fri, Jul 19, 2019 at 1:11 AM Yuan Ting <yuant...@ict.ac.cn> wrote:
>
>  Sorry to have troubled you again, I found that many famous Go projects also 
> import github.com/modern-go/reflect2 , such as kubernetes and moby. According 
> to the second paragraph in your explanation, these popular projects will also 
> failed in compilation. I think this may be a big challenge for gccgo/gollvm's 
> promotion.
>
> To solve this compiler-sensitive problem, the way I can come up with is 
> replacing all unsafe mechanisms as mentioned above in reflect2 to safe or 
> standard mechanisms (and may go against the purpose of reflect2). I'm not 
> familiar with runtime, but is it possible to support the same symbol in 
> gccgo/gollvm style?

Simply supporting runtime.typelinks is not enough.  The reflect
package is closely tied to the compiler implementation.  The reflect
package is not identical in the gc library and the GoLLVM library.  If
people need reflect2 to work with GoLLVM, then the only workable
option is for the reflect2 authors to write a version of their package
that uses the gccgo build tag to build a version that works with
GoLLVM.  Perhaps you could help them with that.  Sorry this isn't very
helpful.  I don't really understand why people are using the package.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWZr%2BLjw8YQHHrHxN3AvhPi%2BNUyN3-F7ddvc7wpnSg3HQ%40mail.gmail.com.

Reply via email to