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? Best, Ting On Thursday, July 18, 2019 at 10:55:39 PM UTC+8, Ian Lance Taylor wrote: > > On Thu, Jul 18, 2019 at 6:50 AM Yuan Ting <yuan...@ict.ac.cn <javascript:>> > wrote: > > > > Thank you for your fix. I have some curious about the difference between > the main Go compiler and gollvm. I read gollvm's readme and know that the > main difference comes from the efficiency of GC. Is the other difference > causes the symbol undefined reference as you mentioned above? Or some bugs > (or library version skew) that will be fixed in the future. > > The gc toolchain has a different assembler that does not use the same > syntax as standard assembler for a platform > (https://golang.org/cmd/asm). GoLLVM uses the standard assembler for > whatever platform it is being used on. So Go packages that use > assembler code, like golang.org/x/sys, have to use different code to > support gc and GoLLVM. That is part of your problem. (That code does > exist in current versions of golang.org/x/sys; the build above is > showing an older version of the package; it's quite possible that > current versions would work). > > The gc toolchain has a special approach for unifying type descriptors > that uses a runtime-specific symbol runtime.typelinks. GoLLVM does > not have that symbol. I don't know what github.com/modern-go/reflect2 > is, but it seems to be using unsafe mechanisms to reach into the > runtime to examine that symbol. That won't work with GoLLVM. The > reflect package in general is closely tied to the compiler, so it's > possible that whatever modern-go/reflect2 is, it will not work with > GoLLVM. > > 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/47ff4ccd-cabf-419c-88a1-6e5687b9ce18%40googlegroups.com.
