Re: [go-nuts] Why was islibrary not set correctly when using -buildmode=c-shared with gccgo compiler
On Tue, Aug 18, 2020 at 6:20 PM Yonatan Gizachew wrote: > > But may I know what gccgo's runtime package? https://go.googlesource.com/gofrontend/+/refs/heads/master/libgo/go/runtime/ https://go.googlesource.com/gofrontend/+/refs/heads/master/libgo/runtime/ Ian > On Wednesday, August 19, 2020 at 8:52:48 AM UTC+9 Ian Lance Taylor wrote: >> >> On Mon, Aug 17, 2020 at 10:42 PM Yonatan Gizachew wrote: >> > >> > Sorry I couldn't provide code to reproduce the case, but I just wanted to >> > know if there are known cases for my issue. >> > From the golang source code, in the runtime library proc.go file there is >> > this code snippet >> > https://github.com/golang/go/blob/a745171e6b30394b661a040d04e8807b4bd0c7da/src/runtime/proc.go#L199 >> > In my case, I build my go program with -buildmode=c-shared mode and I >> > loaded it dynamically to my program written in C. So as to load the >> > runtime go libraries dynamically, I preferred to use the gccgo compiler >> > instead of gc compiler. Here is how I built my go code. >> > >> > $ go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go >> > >> > I was hoping the linker would set the islibrary flag to True and as a >> > result the main function in proc.go would return at line 202. But it >> > wasn't the case. >> > >> > I was wondering why islibrary was set false. >> >> Note that gccgo uses a different runtime package. Your link is to the >> gc runtime package, not the gccgo runtime package. >> >> gccgo sets isarchive for both c-archive and c-shared. As this is an >> internal runtime variable, it shouldn't make any difference. Does it >> ever make a difference to your code that gccgo sets isarchive rather >> than islibrary? >> >> 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/39b98200-4b70-4c1e-8604-b98e2cad43f4n%40googlegroups.com. -- 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/CAOyqgcVDT06L3RDmwChTJkXmQC5OkR5KkO%3DwH%3DTcjdJrYY5sRA%40mail.gmail.com.
Re: [go-nuts] Why was islibrary not set correctly when using -buildmode=c-shared with gccgo compiler
Oh, thanks for clarification. For your question, not for now. On Wednesday, August 19, 2020 at 8:52:48 AM UTC+9 Ian Lance Taylor wrote: > On Mon, Aug 17, 2020 at 10:42 PM Yonatan Gizachew > wrote: > > > > Sorry I couldn't provide code to reproduce the case, but I just wanted > to know if there are known cases for my issue. > > From the golang source code, in the runtime library proc.go file there > is this code snippet > > > https://github.com/golang/go/blob/a745171e6b30394b661a040d04e8807b4bd0c7da/src/runtime/proc.go#L199 > > In my case, I build my go program with -buildmode=c-shared mode and I > loaded it dynamically to my program written in C. So as to load the runtime > go libraries dynamically, I preferred to use the gccgo compiler instead of > gc compiler. Here is how I built my go code. > > > > $ go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go > > > > I was hoping the linker would set the islibrary flag to True and as a > result the main function in proc.go would return at line 202. But it wasn't > the case. > > > > I was wondering why islibrary was set false. > > Note that gccgo uses a different runtime package. Your link is to the > gc runtime package, not the gccgo runtime package. > > gccgo sets isarchive for both c-archive and c-shared. As this is an > internal runtime variable, it shouldn't make any difference. Does it > ever make a difference to your code that gccgo sets isarchive rather > than islibrary? > > 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/10ab8647-5307-4351-bb5f-a30f190c6208n%40googlegroups.com.
Re: [go-nuts] Why was islibrary not set correctly when using -buildmode=c-shared with gccgo compiler
But may I know what gccgo's runtime package? On Wednesday, August 19, 2020 at 8:52:48 AM UTC+9 Ian Lance Taylor wrote: > On Mon, Aug 17, 2020 at 10:42 PM Yonatan Gizachew > wrote: > > > > Sorry I couldn't provide code to reproduce the case, but I just wanted > to know if there are known cases for my issue. > > From the golang source code, in the runtime library proc.go file there > is this code snippet > > > https://github.com/golang/go/blob/a745171e6b30394b661a040d04e8807b4bd0c7da/src/runtime/proc.go#L199 > > In my case, I build my go program with -buildmode=c-shared mode and I > loaded it dynamically to my program written in C. So as to load the runtime > go libraries dynamically, I preferred to use the gccgo compiler instead of > gc compiler. Here is how I built my go code. > > > > $ go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go > > > > I was hoping the linker would set the islibrary flag to True and as a > result the main function in proc.go would return at line 202. But it wasn't > the case. > > > > I was wondering why islibrary was set false. > > Note that gccgo uses a different runtime package. Your link is to the > gc runtime package, not the gccgo runtime package. > > gccgo sets isarchive for both c-archive and c-shared. As this is an > internal runtime variable, it shouldn't make any difference. Does it > ever make a difference to your code that gccgo sets isarchive rather > than islibrary? > > 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/39b98200-4b70-4c1e-8604-b98e2cad43f4n%40googlegroups.com.
Re: [go-nuts] Why was islibrary not set correctly when using -buildmode=c-shared with gccgo compiler
On Mon, Aug 17, 2020 at 10:42 PM Yonatan Gizachew wrote: > > Sorry I couldn't provide code to reproduce the case, but I just wanted to > know if there are known cases for my issue. > From the golang source code, in the runtime library proc.go file there is > this code snippet > https://github.com/golang/go/blob/a745171e6b30394b661a040d04e8807b4bd0c7da/src/runtime/proc.go#L199 > In my case, I build my go program with -buildmode=c-shared mode and I loaded > it dynamically to my program written in C. So as to load the runtime go > libraries dynamically, I preferred to use the gccgo compiler instead of gc > compiler. Here is how I built my go code. > > $ go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go > > I was hoping the linker would set the islibrary flag to True and as a result > the main function in proc.go would return at line 202. But it wasn't the case. > > I was wondering why islibrary was set false. Note that gccgo uses a different runtime package. Your link is to the gc runtime package, not the gccgo runtime package. gccgo sets isarchive for both c-archive and c-shared. As this is an internal runtime variable, it shouldn't make any difference. Does it ever make a difference to your code that gccgo sets isarchive rather than islibrary? 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/CAOyqgcWXwH4CQE65LcqCwXYXeViSs5-9GexBNH0C%2B2ktAVntmA%40mail.gmail.com.
[go-nuts] Why was islibrary not set correctly when using -buildmode=c-shared with gccgo compiler
Sorry I couldn't provide code to reproduce the case, but I just wanted to know if there are known cases for my issue. >From the golang source code, in the runtime library proc.go file there is this code snippet https://github.com/golang/go/blob/a745171e6b30394b661a040d04e8807b4bd0c7da/src/runtime/proc.go#L199 In my case, I build my go program with -buildmode=c-shared mode and I loaded it dynamically to my program written in C. So as to load the runtime go libraries dynamically, I preferred to use the gccgo compiler instead of gc compiler. Here is how I built my go code. - $ go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go I was hoping the linker would set the islibrary flag to True and as a result the main function in proc.go would return at line 202. But it wasn't the case. I was wondering why islibrary was set false. Thanks in advance. -- 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/17e2e62d-a189-4cc6-bce9-eabaeb142147n%40googlegroups.com.
