Met No matching .ll file error while running llgo-dist on MacOS

[hzmangel]

I was following post http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-does-pnacl.html to install llgo on my Mac for writing PNaCl code, but I have met this problem:

2013/05/24 15:41:30 - syscall
No matching .ll file for "asm_darwin_amd64.s"

I have checked the syscall directory but only find asm_linux_amd64.ll and asm_linux_arm.ll. Could you please tell me how to get the .ll file for MacOS?

Here are some information of my dev env:

• llvm: Version 3.3svn, which is shipped with pepper_canary
• llgo-dist: Fetched via go get github.com/axw/llgo/cmd/llgo-dist
• MacOS: 10.7.5

Thanks.

By the way, I have met some error while running llgo-dist in pkg/runtime/panic.c, the reason is because of thread-local variable is not supported by compiler on MacOS, I have made some changes in my local version and will submit a pull request if needed.

[axw]

Hi there, thanks for the report. I'm in the middle of getting PNaCl support working again, so it's a little bit untidy.

You're getting the error because llgo-dist is trying to build for MacOS, when it should be building for the PNaCl target. What you should be doing instead (when it works properly) is something like: llgo-dist -triple=pnacl. I'll update this issue again when I've addressed that.

In the mean time you could try this: make a copy syscall/asm_linux_arm.ll, calling it syscall/asm_darwin_amd64.ll. The ARM file is just a placeholder. You'll need to strip out the "target datalayout" and "target triple" lines from the copy. You may meet similar problems in other files, though.

Please do send a pull request for fixing panic on MacOS. I don't have a Mac, so I don't know what needs to happen there.

[hzmangel]

Thanks for the quick reply. The build can continue after copying asm_linux_arm.ll to asm_darwin_amd64.ll.

But I have met several redeclaration errors in the following build. I have commented the whole file src/github.com/axw/llgo/pkg/sync/atomic/atomic.go to pass the build. Seems all the functions have been declared in /usr/local/go/src/pkg/sync/atomic/doc.go, is this caused by go 1.1?

I will send out the pull request later, I have just replace the __thread to pthread_getspecific and pthread_getspecific. I plan to change it to a more general form before sending.

[quarnster]

By the way, I have met some error while running llgo-dist in pkg/runtime/panic.c, the reason is because of thread-local variable is not supported by compiler on MacOS, I have made some changes in my local version and will submit a pull request if needed.

FWIW it works fine if you change the target triple to "x86_64-apple-macosx10.7.0" or "i386-apple-macosx10.7.0".

Running go test in github.com/axw/llgo/llgo complains about unresolved externals for me though:

Undefined symbols for architecture x86_64:
  "_runtime.panic_", referenced from:
      _runtime.panicwrap in test-MGYM1o.o
      _runtime.memalign in test-MGYM1o.o
      _reflect.call in test-MGYM1o.o
      _reflect.cacheflush in test-MGYM1o.o
      _reflect.makeFuncStub in test-MGYM1o.o
      _reflect.rselect in test-MGYM1o.o
      _reflect.typelinks in test-MGYM1o.o
      ...
  "runtime.guardedcall", referenced from:
      runtime.rundefers in test-MGYM1o.o
     (maybe you meant: _runtime.guardedcall)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Haven't taken a closer look at what might be the cause yet.

[axw]

@hzmangel I fixed the sync/atomic issue today - can you please pull the latest changes and retest? Also, I'd really prefer not to drag in pthread so if quarnster's suggestions fixes the TLS usage, then let's leave panic.c alone.

@quarnster It looks a bit like on MacOS, global symbols are given a preceding underscore. I think each asm("symbolname") in runtime/panic.c will need a "_" at the beginning on MacOS.

[quarnster]

@axw That does indeed appear to be the case :)

PASS
ok      github.com/axw/llgo/llgo    25.223s

[hzmangel]

@axw Sorry for the late reply. I have pulled the newest llgo-dist and try to rebuild llgo with triple x86_64-apple-macosx10.7.5 but got this error:

dyld: Library not loaded: @executable_path/../lib/libLLVM-3.3svn.dylib
  Referenced from: /Users/hzmangel/gocode/bin/llgo
  Reason: image not found

Do you have any idea about this?

[axw]

@hzmangel It looks like llgo can't find the LLVM shared library; I think you need to set DYLD_LIBRARY_PATH (to the LLVM lib directory). llgo-dist builds llgo with "-r" (rpath), though, so I don't know why it should need that.

[hzmangel]

@axw Thanks for the reply, I have set the environment variable before but still has no effect. The llgo binary has been built out and the error is occurred while running the command. It want to find the dylibfile at @executable_path/../lib/ directory. I am still investigating this.

[hzmangel]

@quarnster , the thread-local issue has been fixed with the suggested methods, thanks.

@axw I have created a lib directory and made a symlink of libLLVM-3.3svn.dylib and the llgo can be executed now. I am continue trying to build PNaCl module with llgo, thanks for your amazing tool.

By the way, in your blog post of PNaCl, it shows a llgo-link command, but I can't find it in my ~/gocode/bin (Only llgo and llgo-dist in it). Is the process for PNaCl changed?

[axw]

@hzmangel Thanks. That's a bit of a pain (having to create the lib dir manually), but shouldn't be too much of a problem when llgo binary distributions are generated.

Regarding the blog post: llgo-link got deleted because I found there was no need to do anything special in the linker after all. Just use llvm-link directly.

Having said that, I did try to build a PNaCl module a few nights ago and came across problems that were not present before. I think I may have broken the runtime type generate code, and there's also an issue with how the PP_* structures are declared in Go code (namely the function pointers are no longer the same width).

I'll leave this issue open for now, because I think llgo ought to auto-detect the right triple to support TLS properly. I'll open a new issue to get PNaCl working again.

[axw]

Opened #37

[hzmangel]

@axw Thanks. I will follow those tickets and do the test on MacOS.

[quarnster]

This can also be closed, right?

[axw]

Yes indeed, thanks.