Met `No matching .ll file` error while running llgo-dist on MacOS about llgo HOT 14 CLOSED

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.

from llgo.

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.

from llgo.

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.

from llgo.

@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.

from llgo.

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

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

from llgo.

@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?

from llgo.

@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.

from llgo.

@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.

from llgo.

@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?

from llgo.

@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.

from llgo.

Opened #37

from llgo.

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

from llgo.

This can also be closed, right?

from llgo.

Yes indeed, thanks.

from llgo.