Hi, >>The whole point of my poc was to be able to get the LLVMIR of GO then put it into an iOS app with bitcode enable. What are you saying is that it is not possible to achieve this?
It's definitely outside the normal/expected use of gollvm, but it seems at least possible to do this. The key thing is that for a Go program to run, it needs copies of all its dependent packages. That means that those packages need to be compiled down to bitcode as well, and then the whole collection handed off to whatever is going to be executing the bitcode. To list your transitive dependencies, you can do something like $ go list -json hello2.go and then look at the "Deps" section. I think the last time this was attempted, some hacks were required in the runtime (see https://go-review.googlesource.com/c/gofrontend/+/140917), so you might need to dust off that CL and get it working again. Thanks, Than On Tue, Jan 4, 2022 at 2:49 AM Danilo bestbug <bestbug.corporat...@gmail.com> wrote: > Hello, > Thanks for the answer. I've still some question then. The whole point of > my poc was to be able to get the LLVMIR of GO then put it into an iOS app > with bitcode enable. What are you saying is that it is not possible to > achieve this? Or it's possible but I've to add the missing symbols? If is > the second thing do you have any idea how to do this? > > Thanks! > > Il giorno gio 16 dic 2021 alle ore 22:38 Than McIntosh <th...@google.com> > ha scritto: > >> Greetings, >> >> The code that Go compilers emit is closely tied to the Go runtime-- any >> compiled Go code (including *.ll files) will have references to symbols >> that it needs from the runtime. When you try to convert your LLVM-produced >> bitcode into a binary via >> >> clang helloworld.ll -o helloworldLLVM >> >> you're effectively not including definitions of any of those key runtime >> routines (for example, "runtime.newobject", which is one of the functions >> that supports memory allocation). >> >> It would be similar to what might happen if you took a C++ "hi mom" >> program, compiled it down to an object file using "clang++", then tried to >> link the resulting object into a binary using "gcc". >> >> Hope this helps-- >> >> Than >> >> On Thu, Dec 16, 2021 at 1:07 PM Danilo bestbug < >> bestbug.corporat...@gmail.com> wrote: >> >>> Hello, >>> >>> I've create a docker images with ubuntu 20.10 with GOLLVM, I'm using at >>> the moment a simple test repository >>> <https://github.com/bestbug456/gollvmRepository>, I was able to create >>> the ll file with the following command: >>> >>> go build -gccgoflags -static-libgo -x -work 1> transcript.txt 2>&1 >>> WORK=$(egrep -m 1 '(WORK=|llvm-goc -c)' transcript.txt | awk '{ print >>> substr ($0, 6 ) }') >>> >>> /gollvm/install/bin/llvm-goc -c -O2 -g -m64 >>> -fdebug-prefix-map=$WORK=/tmp/go-build \ >>> -gno-record-gcc-switches -fgo-pkgpath=$PWD \ >>> -fgo-relative-import-path=$PWD -o $WORK/b001/_go_.o \ >>> -I $WORK/b001/_importcfgroot_ -o $LLFILE -S -emit-llvm $MAINFILE >>> >>> But when I try to convert to binary via clang the file I've some error: >>> clang helloworld.ll -o helloworldLLVM >>> warning: overriding the module target triple with x86_64-pc-linux-gnu >>> [-Woverride-module] >>> 1 warning generated. >>> /usr/bin/ld: >>> /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o: >>> in function `_start': >>> (.text+0x24): undefined reference to `main' >>> /usr/bin/ld: /tmp/helloworld-bcb8cc.o: in function >>> `_..z2fopt..z2fvmsdk..z2fhelloworld.describe': >>> /opt/vmsdk/helloworld/./describe.go:6: undefined reference to >>> `runtime.newobject' >>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference >>> to `runtime.writeBarrier' >>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference >>> to `fmt.Printf' >>> /usr/bin/ld: /opt/vmsdk/helloworld/./describe.go:6: undefined reference >>> to `runtime.typedmemmove' >>> /usr/bin/ld: >>> /tmp/helloworld-bcb8cc.o:(.rodata.string..d[string..d]+0x18): undefined >>> reference to `runtime.strequal..f' >>> /usr/bin/ld: >>> /tmp/helloworld-bcb8cc.o:(.rodata.type...1string[type...1string]+0x18): >>> undefined reference to `runtime.memequal64..f' >>> clang: error: linker command failed with exit code 1 (use -v to see >>> invocation) >>> >>> >>> I'm this is the first time I use this buildchain and I don't understand >>> what I'm doing wrong. Can someone help me? >>> Those are the commit I've used for build gollvm, if needed >>> >>> llvm-project: 43ff75f2c3feef64f9d73328230d34dac8832a91 >>> llvm-project/llvm/tools/gollvm: 44a7a475cfd3b871b7a5a0941b8ab1ea9d489adc >>> llvm-project/llvm/tools/gollvm/gofrontend: >>> be0d2cc2df9f98d967c242594838f86362dae2e7 >>> llvm-project/llvm/tools/gollvm/libgo/libffi: >>> 737d4faa00d681b4c758057f67e1a02d813d01c2 >>> llvm-project/llvm/tools/gollvm/libgo/libbacktrace: >>> 5a99ff7fed66b8ea8f09c9805c138524a7035ece >>> >>> 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/d503d8bf-e904-42be-9955-6813d4f8c29fn%40googlegroups.com >>> <https://groups.google.com/d/msgid/golang-nuts/d503d8bf-e904-42be-9955-6813d4f8c29fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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/CA%2BUr55H8YxDFkA8_KnxjMC%3D31fVXEykYZKxbmAAvV3yXb-nUPQ%40mail.gmail.com.
