Unable to compile a simple Swift file (maybe not possible?) #2427
Comments
|
Unfortunately it is not possible to link .dylib files to Emscripten. The reason for that is that the .dylibs already contain native machine code for x86/x64, and Emscripten cannot "go back" and get that to LLVM IR form again. What one would have to do is implement the standard library for Swift and compile that in. The unrecognized struct value errors sounds like something unrelated to this linking issue. Perhaps it might be possible to stub in those standard library functions with your own implementation? |
|
Interesting, I suspected as much, but had hoped dylibs might have llvm I'll take a look to see how much of the Swift standard library source is Appreciate the response, thanks! On Saturday, June 14, 2014, juj notifications@github.com wrote:
|
|
What if we implement our own standard lib, according to http://practicalswift.com/2014/06/14/the-swift-standard-library-list-of-built-in-functions there are just 74 functions |
|
If the Also, an update, the commands in the first post seem deprecated, here is what I tried: Versions The file to compile: The IR The SIL (IDK if it's useful, but can't hurt): Trying to compile with emcc: |
|
If anyone can look at the above and give me an idea of what specifically it's missing, ie "it's trying to link stdlib.swift" and a link to somewhere that someone documents how they solved a similar problem, then I'll put a few hours into trying to get it. If there's any reasonable progress in that time, I'll report it here and probably keep at it. Right now I'm just so ignorant that I don't even know what what the problem is or what to look for in terms of resolving it. But I have like 50 options I'm considering for my project, including things like Elm which I've already put a few days into playing with, so I need some guidance to not wander in circles for a months. |
|
The targets need to match. As the IR shows, the swift frontend emits Emscripten uses its own triple ( |
|
So, I'm ignorant enough that I don't know how to interpret "the targets need to match" (I don't know what "target" means, or what a "triple" is -- kinda sounds like a fixed-length set of memory, like a "tuple" in a functional language). So it's unclear to me if it's something that I fucked up (e.g. did I compile it wrong, or with my own version of some binary, since emscripten uses its own set of binaries -- e.g. I'll create the file using emcc and diff them and spend an hour poring over the differences, confused and trying and failing repeatedly, to figure out what I need to do, but I don't know how. The The reality is that I have no particularly good model for figuring out how this stuff works. I once spent 8 hours getting a C program to compile and load a library I was interested in, that's about the extent of my experience. Code that operates at this level operates under a model that I am simply ignorant of, so while we're in this domain, it's reasonable to me like I've never programmed before. I'm actually pretty good at guessing and cursing repeatedly trying and failing and guessing and cursing again, but I need some sort of model or context to iterate upon. And there's a sufficiently large amount of information available out there, that I need someone who's familiar with this domain to clue me in, and imply to me that this isn't a giant waste of my time (b/c, lets be honest, I could just suck it up and write my shit in JavaScript). |
|
A target is what clang/LLVM is emitting code for. When you build normally, on OSX your target triple is something like Emscripten has its own target, and emcc tells clang and LLVM to use it, |
|
Hmm. Guess I thought LLVM was the target. Anyway, asmjs-unknown-emscripten looks correct: -triple isn't the correct flag, apparently, and it tells me the wrong help file: llvm isn't a binary, but tab-complete suggestions include llvm-gcc and llvm-g++, their help screens don't mention a triple, but do talk about a $ xcrun swiftc -Xllvm "--target=asmjs-unknown-emscripten" -emit-bc f.swift -o f.bc
swift (LLVM option parsing): Unknown command line argument '--target=asmjs-unknown-emscripten'. Try: 'swift (LLVM option parsing) -help'
swift (LLVM option parsing): Did you mean '-stats=asmjs-unknown-emscripten'?
# same output for each of these potential variations:
$ xcrun swiftc -Xllvm "--target=asmjs-unknown-emscripten" -emit-bc f.swift -o f.bc
$ xcrun swiftc -Xllvm "--target asmjs-unknown-emscripten" -emit-bc f.swift -o f.bc
$ xcrun swiftc -Xllvm "-target asmjs-unknown-emscripten" -emit-bc f.swift -o f.bc
$ xcrun swiftc -Xllvm "-target=asmjs-unknown-emscripten" -emit-bc f.swift -o f.bc
$ xcrun swiftc -Xllvm "--target" -Xllvm "asmjs-unknown-emscripten" -emit-bc f.swift -o f.bc
# for that last one, it says "swift (LLVM option parsing): Did you mean '-stats'?"
# so lets verify that llvm-gcc is the right binary by seeing if `-stats` is one of its options:
$ llvm-gcc --help | grep stats
# ...nope, what the fuck is llvm?
# searching implies its binary is named "clang" for some reason,
# but no dice here either:
$ clang --help | grep stats
# man pages have any ideas?
$ man llvm-gcc
No manual entry for llvm-gcc
$ man llvm-g++
No manual entry for llvm-g++
$ man clang # this one works!
# After looking through this man page, I try -arch, which doesn't do shit
# was going to try setting MACOSX_DEPLOYMENT_TARGET env var
# but then I realized there's some way to search all man pages for "-stats"
# some stupid searching (man man) eventually I figure out:
$ man -K stats
# go through this list, and `gcc-4.8` shows up, so maybe llvm is just gcc? *shrug* lets try it
# it turns out to be fruitless
# at this point, I'm considering trying to find in the emscripten code where they invoke it
# figure I'll try googling a bit, find some docs for `llc`, which isn't a binary on my system, but does have a `-mtriple` flag, so lets try that:
$ xcrun swiftc -Xllvm "-mtriple=asmjs-unknown-emscripten" -emit-bc f.swift -o f.bc
# run the gamut of possible ways that I'm supposed to pass this thing
# (why can't I find a fucking example of how to do this?)
# eventually, one of the options suggests "-spiller" as a correction possibility
$ man -K spiller # ...just some thing about cryptoAt this point, documenting in code would add another hour, but many searches, fancy Get pissed, internet search like the fourth time for an example of how to use Look one more time at llvm-gcc, llvm-g++, lldb, Decide to go see if I can find where this happens in So, I'm like 3 hours in, and literally no further than when I started. Looks like someone got Rust compiling to asm.js, maybe that's a better choice. Someone got Go compiling directly to JavaScript. Might be sufficient. Could go suffer through the Elm type system for another week or two (it was basically like this: hours of slamming myself into the wall, but I kept at it for like 3 times longer), or maybe write the thing in C, since that at least compiles, but some part of me thinks that's masochism. If I did it in Opal, I wouldn't have to learn a new language... but that's part of the appeal, and I'm not sure it'll be able to scale in directions I might want to go with my project. Going to go for a drink and weigh the shittiness of C as a language against the fact that I'll almost certainly succeed. |
|
I was able to get very, very simple programs to build with the 6.3 beta at least. Unfortunately even something as simple as a string literal will not work, and regardless the resulting file has a bunch of missing symbols. Some of the symbols ( |
|
So, luckily, this will help later on: https://developer.apple.com/swift/blog/?id=29 |
|
So I was trying to do the same thing, and I just stumbled upon this Issue. So glad that I won't waste my time again. By the way did you try again with XCode 7 and the |
|
Since Apple now supports LLVM Bitcode, would that enable including dylibs that contain it? |
|
LLVM bitcode is not portable. Bitcode for the App Store would be specific to Apple's hardware and OS. |
|
Thanks, that makes sense. In case anyone is interested in more details as I was, LLVM FAQ: Can I compile C or C++ code to platform-independent LLVM bitcode? |
|
It's been 18 months since I started this issue and I still really want this to happen. With Swift going open-source today let's hope that means it's now possible! |
|
This will definitely make it a lot easier! :) Ok, to move forward here, we need to do the following:
|
|
Swift does have a fork of LLVM at apple/swift-llvm. Not sure what changes they have made. |
|
the swift-cli has a bunch of handy options to output just the llvm byte code etc. |
|
Let me know what I can help with would love to have something working! |
|
Thanks for the info @Gaelan. Ok, if they have their own fork, then the best workflow would probably be:
The first step is to upstream our triple, which is already partially there (due to nacl upstreamings), so it's a small patch and probably not controversial. What we need to send is basically this: https://gist.github.com/kripken/0b7ba068faf21d5449a3 Anyone interested to help upstream that? |
|
It looks like Apple's llvm clone is pretty strict about changes being made upstream unless they are specifically swift-related. See: https://swift.org/contributing/#llvm-and-swift |
|
Could open an issue in the Swift LLVM github to ask them for changes |
|
I think that reduces to asking them to merge the changes in themselves, which is against their policy. The patch would have to be submitted directly to llvm by someone here. I have no familiarity with the llvm community, so I don't know how they would feel about, for example, introducing |
|
This is very exciting @kripken! In theory, should we be able to make these modifications locally and try things out using the swift LLVM clone? I modified the relevant files in the swift LLVM clone, according to your patch - here is the diff of the changes I made: https://gist.github.com/sberan/43bc5fbff78ea47658f0 Unfortunately I don't see a new target for asmjs in the swift recompiled LLVM: Maybe more work needs to be done here in order to register asmjs as a target? Forgive me if this is a noob question, I'm very new to llvm and emscripten, just very excited to try swift in the browser 😄 I'd be happy to try and push these changes upstream, but I'd like to verify that they'll work first! 😆 |
|
I'll try to give it a go when I get a chance! |
|
I think you might not see a target because you can't build a full executable for js. But you should be able to build with |
|
There is another possible path here. Upstream LLVM has a WebAssembly triple now. It is almost identical to our asm.js triple. It should be possible for swift to build to the wasm-wasm-wasm triple, then import that bitcode into emscripten which can compile it to asm.js. (We would still need to make sure it's the same LLVM version, or close enough, to avoid e.g. debug info changes. But emscripten merges upstream every week or two now, so that should be easy, if someone tells me what is a good time to merge for Swift, i.e., when Swift merges.) Note that the wasm triple is still experimental, so you need to build LLVM with it enabled, from the list of experimental targets. |
|
@kripken - This is an overview of the release process for Swift https://swift.org/blog/swift-2-2-release-process/ |
|
Swift uses llvm 3.8.0. They have their branch and not exactly sure their policy but once they finish swift 2.2, they'll probably merge their branch to upstream trunk. 3.8.0 already has wasm as kripken said, so I was able to build swift-llvm with wasm64 enabled and pass basic tests, but struggling to build swift with llvm-wasm and build swift stdlibs with with llvm-wasm + emscripten, main reason is that their build system is huge but not so flexible. (There're lots places that have hard-coded config like `if system==darwin then build for Mac, else build linux kind of thing) But I'm new for their build system so I may miss something. I just wanted to make sure the process I'm doing is in the right course.
|
my ignorant suggestion: |
|
It doesn't look like the argument is passed incorrectly, otherwise I'd expect My current guess is that something's missing in |
|
nice progress! so, looks like looking at SwiftConfigureSDK.cmake, but we are not setting the variable in |
|
Thank you @patcheng, that's a great shout! I've fixed that missing directory problem and a few more header import errors following after that in my fork. Here's the error I'm currently stuck at: Looking at this precompiled module file we can see that it's compiled to WebAssembly: Not sure if that's any good, a bit more googling leads to this clang doc on precompiled modules. There's also a mention of an unmerged patch for WebAssembly precompiled modules here and an unresolved clang bugreport probably related to this problem, both posted by @patcheng by the way 👍 Probably need to try and apply that patch or figure another way to make clang consume these precompiled WebAssembly modules. Or maybe these modules shouldn't be compiled to WebAssembly altogether? 🤔 |
|
Hey @MaxDesiatov, a big thanks for all the work you've been doing on this! I was wondering what the current status of compiling Swift to WASM is right now. I lack much experience in this area, but I'm very excited to potentially see support for this, so I would be happy to attempt contributing toward these efforts, given some guidance on what needs to be worked on. Thanks! |
|
I’m pretty sure the precompiled modules should be readable to the cross-compile host (in your case Mac OS?) so shouldn’t be in web assembly format. This is a common pain when trying to cross-compile generally (host vs target), and the last I looked the swift toolchain was doing weird things in this regard because it doesn’t follow CMake’s standard- Apple was having toolchain build performance issues internally using it in that way. So to fix your issue it’s possible it’s an LLVM bug but it may also be an issue with the CMake scripts (or what is being passed to them by build-script-impl). I haven’t looked at the build system in a while. I’m still tied up with some other projects but I do look here periodically and will try to share what limited experience I have with the build system. |
|
I just discovered that @ddunbar has been creating PRs to add WASM support to Swift: apple/swift-clang#235 |
|
Just a few, very minimal initial ones... this bug has the status: https://bugs.swift.org/browse/SR-9307 |
|
Hi all, sorry for the delayed reply. There are few more blocking things that I've discovered while trying to make stdlib and a few basic examples compile:
Hope this helps. |
|
It looks like short-term it would be great if we could push swiftlang/swift#20684 PR towards being merged. Reviewing its code, commenting on the review, upvoting the PR, pinging the authors/reviewers once a week or at least once a month and sharing to your friends so that they do the same would definitely help. And yes, the Apple's contribution guide for the Swift compiler says we can ping people once a week 😃
Here's also quick guide if anyone's interested in investigating the rest of the issues I mentioned above. The gist is that you need to compile a Swift toolchain that supports Or you can try @ddunbar's branch from the PR, but you need to check if it pulls fresh LLVM/Clang when doing I haven't compiled any of these branches for quite some time so that's why some rebasing on top of the latest code and resolving conflicts might be needed. After you've got the toolchain compiling successfully you can try compiling MicroStdlib test: % ./build/Ninja-DebugAssert+stdlib-ReleaseAssert/swift-macosx-x86_64/bin/swiftc \
-target wasm32-unknown-unknown-wasm -c -force-single-frontend-invocation \
-parse-as-library -parse-stdlib -module-name Swift -emit-module \
-emit-module-path Swift.swiftmodule -o Swift.ll \
swift/validation-test/stdlib/MicroStdlib/Inputs/Swift.swiftThis will generate a If all goes well at the previous stage you can then compile Instructions that don't make sense should be fixed in |
Maybe could be simulated using green threads ? |
It's not that the standard library needs green threads or multi-threading to make it work, it's just that reference counting and the rest of the runtime were never written for platforms like WASM (or AVR for example) in mind, so it guards everything with atomics and synchronization assuming you always have to be safe when passing ref-counted objects around. On WASM that's not a problem as long as you don't have threads, we could even throw out all of the atomics and synchronization, the problem would be to keep that forked version maintained. That's why I'd prefer to have the shims compiled conditionally with upstream stdlib source code if/when we have shims available for atomics. And this is what people from the Swift core team recommended to do anyway:
|
|
I left a comment on the forum, gist being that wasm has plans for atomics, but not any time soon, so stubbing I’d avoiding trying to fork the things to not use atomics in the stdlib/runtime because it’s much more likely to change than atomics, and you can write/maintain NOP functions much more easily than maintaining a fork of the standard library. |
|
Thanks for all the hard work trying to get this to work - Swift is a fantastic language that I would love to see running in the browser (although the 5 megabyte bundle size will make me think twice). |
|
I spent the past week looking into this: it looks like LLVM/WebAssembly's support for custom data sections isn't mature yet, so Swift's runtime type reflection won't work. I got to the same stage as @patcheng's and @MaxDesiatov's ports: specifically, I can compile a simple Swift function that doesn't use the stdlib and run it in Firefox.
but I'm stuck here now as well. I had to comment out a lot of stuff in LLVM to get asserts to stop firing when writing the type information sections to the wasm file.This results in invalid wasm files when I compile any Swift file with a class or struct declaration in it... including the stdlib. While it's possible to disable runtime type information in Swift (with the -disable-reflection-metadata flag), this would break pretty much everything in the stdlib. (I remember from the Swift 2 era that even I know @patcheng sent some patches to LLVM to try to resolve this, but I'm not sure what they do or whether more changes are needed. I wonder how other language with runtime types support, such as Go or Rust's Any trait, encode their type information in WebAssembly. |
|
I wonder if using something like Binaryen instead of LLVM would allow us to write the metadata properly 🤔 I know that Binaryen IR doesn't even use SSA, this would probably require writing whole codegen pass for it, but maybe still worth it? Does anyone here have any experience with Binaryen and can provide their opinion on this? |
|
Hi zhuowei,
I work on the llvm backend for WebAssembly. We are certainly interested in
any bugs you have found related to custom data sections. Could you open a
bug https://bugs.llvm.org/ and perhaps attach an example of some bitcode
that causes the error/assertions?
cheers,
sam
…On Sat, Apr 13, 2019 at 12:04 AM zhuowei ***@***.***> wrote:
I spent the past week looking into this: it looks like LLVM/WebAssembly's
support for custom data sections isn't mature yet, so Swift's runtime type
reflection won't work.
I got to the same stage
<https://github.com/swiftwasm/swift/tree/swiftwasm> as @patcheng
<https://github.com/patcheng>'s and @MaxDesiatov
<https://github.com/MaxDesiatov>'s ports: specifically, I can compile a
simple Swift function that doesn't use the stdlib and run it in Firefox.
[image: swiftwasm_first]
<https://user-images.githubusercontent.com/704768/56073919-515f7f00-5d5f-11e9-9350-daa76c153a4f.png>
but I'm stuck here now as well.
I had to comment out a lot of stuff
<https://github.com/swiftwasm/swift-llvm/tree/stable-swiftwasm> in LLVM
to get asserts to stop firing when writing the type information sections to
the wasm file.This results in invalid wasm files when I compile any Swift
file with a class or struct declaration in it... including the stdlib.
While it's possible to disable runtime type information in Swift (with the
-disable-reflection-metadata flag), this would break pretty much everything
in the stdlib. (I remember from the Swift 2 era that even println("hello
world") would crash without runtime type info)
I know @patcheng <https://github.com/patcheng> sent some patches to LLVM
<https://reviews.llvm.org/people/revisions/16900/> to try to resolve
this, but I'm not sure what they do or whether more changes are needed.
I wonder how other language with runtime types support, such as Go or
Rust's Any trait, encode their type information in WebAssembly.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2427 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAfe5fpT2lriWLn623BjOAw8EOEhmdRsks5vgYF8gaJpZM4CEPAq>
.
|
|
@sbc100 I don't have a Bugzilla account on LLVM yet; I'll apply for one soon. In the meantime, here are the issues I ran into, with links to patches/workarounds. I'm planning to send some of these upstream when possible
Swift has a bunch of data relocations that are (symbol - constant value); this becomes a MCBinaryExpr, which causes asserts when writing object. patcheng has a patch to check for these at https://reviews.llvm.org/D42564; I have a terrible kludge for fixing them at swiftwasm/llvm-project@d0a183f and swiftwasm/llvm-project@3dc1a43
This one can be worked around by not passing the equivalent of that flag when compiling Swift
Comdat only works when custom sections aren't specified. Comdat in LLVM's Wasm object writer expects unique section name for each comdat symbol; The default section names are ".rodata.(symbol name)", which does work. If I specify a custom name, it doesn't: https://gist.github.com/zhuowei/597b77698634aac9b302d43b5c464838 Worked around by not using Comdat (since Swift disables comdats on Linux/ELF and macOS anyways)
This isn't an LLVM issue; it's just that Swift writes relative addresses in the metadata table to avoid runtime relocations (ie (target address - current address)); this requires a relocation type referencing two symbols, which doesn't exist in Wasm. I asked a Swift developer on Twitter and it seems the Windows port has some workarounds for this that I could look into.
Patcheng has a patch for this: https://reviews.llvm.org/D42233 but it predated custom sections support, so it was decided to wait for custom sections to be included and switch the patch to use that. I've addressed the comment and switched that patch to using custom sections: my version of that patch is swiftwasm/swift-llvm@de2966b and swiftwasm/swift-llvm@502e753
ddunbar added Swift calling convention support to llvm, but it isn't turned on yet (maybe because there are no tests?) I enabled it at swiftwasm/llvm-project@ea5605a, and I'm currently trying to port the ARM32 swift-return.ll/swifterror.ll/swiftself.ll test cases to WebAssembly so I can submit that patch. Thank you so much for your work on the WebAssembly backend! |
|
@MaxDesiatov A quick update on my progress: The Stdlib links. ...For certain values of "links": I basically completely broke the metadata support to get it to link. Attempting to run the resulting WebAssembly file gives me: Yeah, this needs a lot more work before swift_getTypeByMangledName would run. All my changes are pushed to the SwiftWasm repo, and I'll setup CI and document how to build it soon. |
|
@zhuowei - I'm curious to hear more about your goals for the port. You're using wasi, so is this mostly for non-browser use cases? Is running on the web not a goal? (And, is using an API like OpenGL not a goal?) |
|
@kripken Thank you so much for your comments! I'm looking to target the browser, with serverside being a nice to have. I mostly used WASI because it's new and defaults to using LLVM's wasi-ld for linking, instead of Emscripten's bitcode-based emcc linker. (I know Emscripten can use wasm-ld as well, but I think? the standard libraries are all compiled for emcc?) I actually started with a Emscripten sysroot, and it didn't take too many changes to switch to WASI. Thus, I'm sure most of the work done for this port would also be applicable to an Emscripten-based port. I was planning to modify WASI's browser polyfill for better interop with web APIs and JavaScript (since Emscripten's EM_ASM macros probably won't work in Swift anyways). I understand that Emscripten's the more mature choice right now for interoperating with the Web. I would really appreciate your expertise in what approach I should take to turn Swift into a language for the web. |
|
Interesting, thanks @zhuowei! Yes, emscripten does support wasm-ld and the LLVM wasm backend - basically if you just point emscripten to a plain upstream LLVM build, it will use all that (on linux, you can already try it out using Anyhow, the reason I asked is I'm curious how emscripten can help here. Sounds like using the LLVM wasm backend is a good step we're close to completing. Otherwise, I guess it depends on the applications you want to port. My general thoughts on the topic, for languages using LLVM:
Since you say your main goal is the browser, then maybe emscripten has a role to play here - let me know what you think. We'd definitely like to help here if it's relevant! Btw, a question about your Swift PR: I see it has ifdefs on both |
|
@kripken I did see the progress on the Wasm-ld stuff: I honestly was just trying to be hipster by using the latest shiny SDK... Minimal pure computation was possible even before we started this port (see my comment above) - most of the work is mainly about getting the full stdlib working. I originally started by targetting Emscripten, and switching to WASI was pretty much a find-and-replace (since both used Musl), so adding support for Emscripten is definitely something that we'll look into once we get the basic support upstreamed. Yes, that's what I tried to do for defines: I tried to use the I named the platform as just "Wasm" in the Swift stdlib, so the conditional compiles there are I definitely agree that support for Emscripten would be great for Swift - we're definitely interested in working together to make that possible in the future. Thank you so much for the comments and for all your work on Emscripten. |
|
@kripken @zhuowei Hi I’m really excited for these developments, but I’ve got a lot of questions. 🎉 I don’t know too much about Emscripten, but I read that Rust chose not to use it because of its weighty runtime (rust-lang/rust#45905). Do you mind giving a high level overview (or linking) what functionality the runtime provides? Also, how can we minimize the weight of that runtime? Can we use dead code stripping, LTO, import just what we need from Swift? Thanks for your insights |
|
@zhuowei Great, let me know when and how we can help :) @therealbnut Sure, let me try to explain what the extra runtime stuff does here. Maybe a step back first though - note that Rust didn't remove Emscripten support, they added a second option. But yes, that new option is definitely where most of the activity is, as you said. This makes sense because of the different use cases:
This is simply because Rust is a new language - there aren't many large important native applications written in Rust yet. Most relevant applications are currently written in C++ - for example, the Unity and Unreal game engines. The runtime that emscripten provides is exactly to support POSIX, OpenGL, SDL, etc. It consists of ports of those libraries, of new C APIs to make porting them easy, and of basic building blocks to enable all of that. All of this is very web-specific and includes a lot of complexity because of that - because it's not easy to implement pthreads using Workers or normal OpenGL using WebGL, etc. The web platform is weird! Note that we already do LTO and other things to reduce code size. We even do dead code elimination across both the wasm and the JS ("metadce"). We also make sure to keep our JS code compatible with closure advanced optimizations for the best JS minification on that side, and use binaryen to minify the wasm. But we can do more, and we do have some unnecessary code in the runtime we'd like to remove (the ongoing That's how I see the extra value that emscripten brings here. It's incredibly important for C/C++ because existing apps need that, but maybe not for Rust since it's new code anyhow. But with that said, if Rust becomes important in native application development - which seems plausible - then maybe the next 1 million line game engine will be written in Rust, and then emscripten would be the right tool to port it. I don't know enough about the Swift ecosystem to know how it fits in all this, but as discussed above, it should be pretty easy to support both wasi and emscripten, leaving options open for both new code as well as porting native applications. Btw, emscripten brings another, separate type of value as well - it's mostly the same team of developers that work on emscripten, the LLVM wasm backend, wasm-ld, and binaryen. Since it's the same people, I think it's natural that we do a good job of making emscripten use those other tools in an optimal way. In particular, emscripten makes sure to call wasm-ld and binaryen with carefully-chosen flags for optimizing for code size and speed, uses features like metadce that was mentioned before, etc. So the out-of-the-box code quality - just grab the emsdk and do |
|
@kripken Awesome, thank you very much for taking the time to respond, that answers a lot of my questions, and some I hadn’t thought of yet :) |
|
This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant. |
and others
Hi team, playing around with Emscripten in earnest for the first time, not my usual area of work so apologies if this is clearly never going to work. What I'd like to do is compile a simple Swift program to JS:
So far what I've tried is:
but that fails because it can't find certain symbols (looks like the standard library isn't present):
Value: %1 = call { i8*, i64, i64 } @_TFSS37_convertFromBuiltinUTF16StringLiteralfMSSFTBp17numberOfCodeUnitsBw_SS(i8* bitcast ([14 x i16]* @0 to i8*), i64 13) LLVM ERROR: Unrecognized struct value Traceback (most recent call last): File "/Users/glen/Downloads/emsdk_portable/emscripten/1.16.0/emcc", line 1540, in <module> shared.Building.llvm_opt(final, link_opts) File "/Users/glen/Downloads/emsdk_portable/emscripten/1.16.0/tools/shared.py", line 1267, in llvm_opt assert os.path.exists(target), 'Failed to run llvm optimizations: ' + output AssertionError: Failed to run llvm optimizations:Drilling a bit further, and looking at how
xcrun swift -v hello_world.swiftactually works, I'm able to use this linking command to compile the bitcode to an executable using normalld.So, it seems like
libswift_stdlib_core.dylibis the only dependency forhello_world.bcto be properly linked to an executable.But I'm stuck - is there some equivalent between the
-Land-rpathflags onldthat I should be passing toemcc? Or is a dylib like that not possible to be used in emscripten? The final command I tried was:Hopefully something's possible from here - Swift is a neat high-level language with a nice type system and no garbage collector, which makes me think it's a good fit for compiling to JS.
The text was updated successfully, but these errors were encountered: