Mac linker error: dyld: Symbol not found: _futimens #5418
Comments
|
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? What is |
|
(oops, hit wrong button before) |
|
Same issue here, but I'm not using Rust, just See https://gist.github.com/f5066409ceeab4e254149d9b6c374bc0 This happens while compiling libsodium.js, with the macOS 10.12, Xcode 9b6. |
|
Workaround. I used homebrew instead, but encountered the same problem. Since there's something wrong with 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-arChange paths where necessary. |
emscripten-core/emscripten#5418 (comment) Hopefully just a temporary thing.
emscripten-core/emscripten#5418 (comment) Hopefully just a temporary thing.
|
@kripken: I just noticed your question! |
|
Here is some trace of investigation: 1It looks connected to rust-lang/rust#42997 2Some fixes in the upstream project: llvm-mirror/llvm@0e3a936#diff-2eeb0237a3e7842df96b4c1280614125 3This looks that the test 4Once I've forced flag UpdateOK 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: emscripten-core/emscripten-fastcomp#200 |
Fix for emscripten-core/emscripten#5418 Where on macOS <10.13 a flag HAVE_FUNTIMENS was incorrectly set to 1
|
Just upgraded my emsdk to |
|
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. |
|
|
|
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 |
|
I used the package at |
|
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 |
|
|
|
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: |
|
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: The |
|
Just install emsdk to 1.37.26 and getting the same issue |
|
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 class A class A |
|
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 ***@***.***> 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
<#5418 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADo8NP0cvZ3B3KCrqJFo4axgWu99a2Dks5tFw_GgaJpZM4Ohf4x>
.
|
I haven't had this problem since upgrading to High Sierra. |
|
Looking into this now.. |
|
The issue is the same as here: emscripten-core/emscripten-fastcomp#200, but for some reason the PR to fix did not apparently catch all cases. This is now tackled in two ways:
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 |
|
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 ***@***.***> wrote:
The issue is the same as here: emscripten-core/emscripten-fastcomp#200
<emscripten-core/emscripten-fastcomp#200>, but for some
reason the PR to fix did not apparently catch all cases.
This is now tackled in two ways:
1. In emsdk, if building from source on macOS SDK < 10.13,
-DHAVE_FUTIMENS=0 is passed to the build: ***@***.***
<emscripten-core/emsdk@f3ac553>
2. 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
<#5418 (comment)>,
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. |
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
* Update Bazel to 0.29.0 Tried Bazel 0.29.0 locally with Linux and it works. So create a PR to see if it works for macOS as well. Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Update grpc/googleapis/etc Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Pin h5py==2.9.0 Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Fix bazel lint error Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Pin h5py==2.9.0 in bazel build, as h5py==2.10.0 is broken in ubuntu 16.04 Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Bump the OSX to osx10 on Travis CI, See emscripten-core/emscripten#5418 Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Switch to xcode 9.3, since ignite requires JDK 1.8 or 1.9 (xcode10 have JDK 10) Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Fix the import path issue in grpc Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Removed `python -m pip install -q grpcio-tools` as this is not needed anymore Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Build //tensorflow_io/core:all to create Travis CI Cache Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Fix nucleus build failure caused by bazel 0.29.0 Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Enable all builds Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Build //tensorflow_io/core:all to create Travis CI Cache Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
* Update Bazel to 0.29.0 Tried Bazel 0.29.0 locally with Linux and it works. So create a PR to see if it works for macOS as well. Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Update grpc/googleapis/etc Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Pin h5py==2.9.0 Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Fix bazel lint error Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Pin h5py==2.9.0 in bazel build, as h5py==2.10.0 is broken in ubuntu 16.04 Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Bump the OSX to osx10 on Travis CI, See emscripten-core/emscripten#5418 Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Switch to xcode 9.3, since ignite requires JDK 1.8 or 1.9 (xcode10 have JDK 10) Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Fix the import path issue in grpc Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Removed `python -m pip install -q grpcio-tools` as this is not needed anymore Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Build //tensorflow_io/core:all to create Travis CI Cache Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Fix nucleus build failure caused by bazel 0.29.0 Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Enable all builds Signed-off-by: Yong Tang <yong.tang.github@outlook.com> * Build //tensorflow_io/core:all to create Travis CI Cache Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
and others
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.
The text was updated successfully, but these errors were encountered: