Closed n8gray closed 6 years ago
This stuff looks like a weird OS X linking issue. I don't know much about OS X, but it looks like a problem between your system libs and the build of LLVM. Maybe linked on another machine with other system libs or something like that?
dyld: Symbol not found: _futimens
Referenced from: /SAPDevelop/src/Swift2WebAssembly/emsdk/clang/fastcomp/build_incoming_64/bin/llvm-ar
Expected in: /usr/lib/libSystem.B.dylib
What is Swift2WebAssembly
, btw?
(oops, hit wrong button before)
Same issue here, but I'm not using Rust, just emcc
.
See https://gist.github.com/f5066409ceeab4e254149d9b6c374bc0
This happens while compiling libsodium.js, with the incoming
branch of emscripten.
macOS 10.12, Xcode 9b6.
Workaround. I used homebrew instead, but encountered the same problem. Since there's something wrong with llvm-ar
, I used llvm-ar
from llvm
homebrew package instead:
brew install llvm
mv /usr/local/opt/emscripten/libexec/llvm/bin/llvm-ar /usr/local/opt/emscripten/libexec/llvm/bin/llvm-ar.old
ln -s /usr/local/opt/llvm/bin/llvm-ar /usr/local/opt/emscripten/libexec/llvm/bin/llvm-ar
Change paths where necessary.
@kripken: I just noticed your question! Swift2WebAssembly
was me trying to hack the Swift compiler to produce wasm. I didn't make any progress to speak of. :(
Here is some trace of investigation:
It looks connected to https://github.com/rust-lang/rust/issues/42997 What in fact is caused by having XCode9 and macOS10.12: (other case: https://gitlab.kitware.com/cmake/cmake/issues/17101) I've tried to compile locally sdk-incoming and it looks that it's not compilation environment specific problem.
Some fixes in the upstream project: https://github.com/llvm-mirror/llvm/commit/0e3a93628a91926fe1a0b45f576ebdc9ff5c250d#diff-2eeb0237a3e7842df96b4c1280614125 Looks that the flag is propagated nicely further to Makefiles, but during compilation I've got
In file included from /Users/piotr.paczkowski/SDK/emsdk_git/clang/fastcomp/src/lib/Support/Path.cpp:1174:
/Users/piotr.paczkowski/SDK/emsdk_git/clang/fastcomp/src/lib/Support/Unix/Path.inc:462:7: error: 'futimens' is only available on macOS 10.13 or newer [-Werror,-Wunguarded-availability-new]
if (::futimens(FD, Times))
^~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/stat.h:373:5: note: 'futimens' has been explicitly marked partial here
int futimens(int __fd, const struct timespec __times[2]) __API_AVAILABLE(macosx(10.13), ios(11.0), tvos(11.0), watchos(4.0));
^
/Users/piotr.paczkowski/SDK/emsdk_git/clang/fastcomp/src/lib/Support/Unix/Path.inc:462:7: note: enclose 'futimens' in a __builtin_available check to silence this warning
if (::futimens(FD, Times))
^~~~~~~~~~
This looks that the test check_symbol_exists(futimens sys/stat.h HAVE_FUTIMENS)
# returns false positive result.
Strangely I haven't found anything extra in the upstream project to prevent using futimens.
Once I've forced flag HAVE_FUTIMENS=0
and I've compiled llvm-ar, it works nicely.
OK It looks that I had a problem with a false positive results due a CMakeCache, after removing the build folder it has started to work, here you can find a PR: https://github.com/kripken/emscripten-fastcomp/pull/200
Just upgraded my emsdk to 1.37.22
and getting the same issue
The fix should be a part of version 1.37.23, what's unreleased yet at the moment.
version 1.37.22 same issue
How do you get 1.37.23? It doesn't look like it is available through the emsdk.
I followed the script at https://github.com/GodotBuilder/godot-builds/pull/9/files, worked a treat
So, emscripten on macOS is basically broken until 1.37.23 is released? That's ridiculous. This should have a hot fix.
1.37.24
was released 3 days ago: https://github.com/kripken/emscripten/releases
There may be an issue with the emsdk fetching it, though (our bots don't seem to, I'm not sure why - might need to wait for @juj to get back and look at it). Otherwise, though, the emsdk should be able to fetch incoming
(instead of a tag) and build that.
I used the package at https://s3.amazonaws.com/mozilla-games/emscripten/releases/emsdk-portable.tar.gz
that the link on the official website points to. ./emsdk install latest
did not give me a newer version. I did it yesterday and today. Are the binaries always a couple of releases behind?
The binaries need to be built by the bots, yes, and there is a problem there that only @juj can investigate.
But if you install incoming
using the sdk, that will work (it will build the binaries for you locally), http://kripken.github.io/emscripten-site/docs/tools_reference/emsdk.html?highlight=emsdk%20incoming#how-do-i-track-the-latest-emscripten-development-with-the-sdk
Interesting, thanks @dasa - I wasn't aware brew had frequent updates of emscripten. Perhaps our docs should suggest using it on OS X?
Yeah, @ilovezfs seems to be keeping it updated: https://github.com/Homebrew/homebrew-core/commits/master/Formula/emscripten.rb
Huh, yes, that sounds like a good idea to me. I'm already using Homebrew and would've installed it via that if I that had been one of the endorsed ways of installing it. I might've installed it that way in any case if I had known about it, but I tend to expect that the official install method gives me a fresher release than a package manager. I think I've seen some CLI installers actually use Homebrew if it's available?
@rspq I have tried your method and works well. Thanks very much
Is this now fixed? I'm confused why we still have people talking about workarounds.
I have this issue after following the instructions here on macos 10.12 http://kripken.github.io/emscripten-site/docs/getting_started/downloads.html
I'm having this issue when trying to use wargo:
cargo new --bin meow
cd meow
wargo build
The wargo build
step fails.
Just install emsdk to 1.37.26 and getting the same issue
Referenced from: /Users/me/tools/emsdk-portable/clang/e1.37.26_64bit/llvm-ar (which was built for Mac OS X 10.13)
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: _futimens
Referenced from: /Users/me/tools/emsdk-portable/clang/e1.37.26_64bit/llvm-ar (which was built for Mac OS X 10.13)
Expected in: /usr/lib/libSystem.B.dylib
0 llvm-ar 0x00000001014e2d88 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1 llvm-ar 0x00000001014e3336 SignalHandler(int) + 358
2 libsystem_platform.dylib 0x00007fffbccf8b3a _sigtramp + 26
3 libsystem_platform.dylib 0x00000001057cab4d _sigtramp + 1219305517
4 libsystem_platform.dylib 0x00000001057d5464 _sigtramp + 1219348804
5 libsystem_platform.dylib 0x00000001057b0793 _sigtramp + 1219198067
6 libsystem_platform.dylib 0x00000001057b089e _sigtramp + 1219198334
7 libdyld.dylib 0x00007fffbcae5282 dyld_stub_binder + 282
8 llvm-ar 0x0000000101719340 (anonymous namespace)::DarwinX86AsmBackend::getCompactUnwindRegNum(unsigned int) const::CU64BitRegs + 10650
9 llvm-ar 0x00000001013aae6d performOperation(ArchiveOperation, llvm::object::Archive*, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::vector<llvm::NewArchiveMember, std::__1::allocator<llvm::NewArchiveMember> >*) + 2013
10 llvm-ar 0x00000001013aa0a2 performOperation(ArchiveOperation, std::__1::vector<llvm::NewArchiveMember, std::__1::allocator<llvm::NewArchiveMember> >*) + 930
11 llvm-ar 0x00000001013a7c99 main + 361
12 libdyld.dylib 0x00007fffbcae9235 start + 1
Stack dump:
0. Program arguments: /Users/me/tools/emsdk-portable/clang/e1.37.26_64bit/llvm-ar xo /Users/me/XXXX.a
Traceback (most recent call last):
File "/Users/me/tools/emsdk-portable/emscripten/1.37.26/em++", line 16, in <module>
emcc.run()
In my case(macOS 10.12.6, emscripten 1.37.27), I got this issue because virtual destructors.
.cpp including virtual destructors was compiled, but was not linked.(I don't know why.)
If virtual destructors are unnecessary, try not to use that .
class A { public: A(); ~A(); }; is ok.
class A { public: A(); virtual ~A(); }; is not ok.
class A { public: A(); ~A(); virtual void B(); }; is ok.
Does anyone know whether this works on high sierra?
This issue is causing a lot of problems for a lot of users. Can anyone invest some time into fixing this?
The parcel-bundler team wants to integrate Rust via Wargo, but this is currently blocking us.
On Sat, Dec 30, 2017 at 10:38 PM, Robert Balicki notifications@github.com wrote:
Does anyone know whether this works on high sierra?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kripken/emscripten/issues/5418#issuecomment-354584941, or mute the thread https://github.com/notifications/unsubscribe-auth/AADo8NP0cvZ3B3KCrqJFo4axgWu99a2Dks5tFw_GgaJpZM4Ohf4x .
Does anyone know whether this works on high sierra?
I haven't had this problem since upgrading to High Sierra.
Looking into this now..
The issue is the same as here: https://github.com/kripken/emscripten-fastcomp/pull/200, but for some reason the PR to fix did not apparently catch all cases.
This is now tackled in two ways:
emsdk
, if building from source on macOS SDK < 10.13, -DHAVE_FUTIMENS=0
is passed to the build: https://github.com/juj/emsdk/commit/f3ac553081e6b717afaa96632a87ecdc22cd4b92I'm having trouble verifying since I don't have an actual macOS 10.11 device at hand. It would be great to hear from someone who does, whether after git pulling latest emsdk emsdk install sdk-incoming-64bit
works properly after that commit?
I have macOS 10.12. Would that help?
@juj if you want to hop on Parcel Bundler's slack and shoot me a message, I can help debug this in real time with you. https://github.com/parcel-bundler/parcel
On Wed, Jan 3, 2018 at 2:45 PM, juj notifications@github.com wrote:
The issue is the same as here: kripken/emscripten-fastcomp#200 https://github.com/kripken/emscripten-fastcomp/pull/200, but for some reason the PR to fix did not apparently catch all cases.
This is now tackled in two ways:
- In emsdk, if building from source on macOS SDK < 10.13, -DHAVE_FUTIMENS=0 is passed to the build: juj/emsdk@f3ac553 https://github.com/juj/emsdk/commit/f3ac553081e6b717afaa96632a87ecdc22cd4b92
- The macOS build systems have been updated to build targeting macOS SDKs 10.11, where this symbol was not present.
I'm having trouble verifying since I don't have an actual macOS 10.11 device at hand. It would be great to hear from someone who does, whether after git pulling latest emsdk emsdk install sdk-incoming-64bit works properly after that commit?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kripken/emscripten/issues/5418#issuecomment-355121989, or mute the thread https://github.com/notifications/unsubscribe-auth/AADo8KgeRTdJ1hI3hO2zD0JPGzUBl3STks5tG-bsgaJpZM4Ohf4x .
@juj is there prebuilt build I can test to verify the fixes to the build system?
Updating to 1.37.36 (and installing python2 as a workaround for #6275) solved the issue on macOS 10.12 for me.
Thank you all!
I'll close this as fixed, I think we should actually now be double fixing this issue since we are using devernay/xcodelegacy to explicitly pin to an older macOS SDK to keep supporting old versions.
Following the tutorial here I've installed Rust and Emscripten. But when I try to compile a simple rust file to WebAssembly I get an error from llvm-ar. I'm on macOS Sierra 10.12.5:
I've also reported this to the Rust project since I'm not sure where the problem lies.