1) Given that the behavior for the NetBSD branch are so similar to linux, I feel that this might be a change that we could just pull into emsdk upstream, if you'd like to post a PR. 2) What is the difference between 'gtar' and 'tar'? Are these tools identical in behavior? If they are, I think we could have emsdk script first search for 'tar', and if it doesn't find that in PATH, then it could try to fall back to look for 'gtar'. Would that make sense? 3) This sounds like an upstream LLVM build issue, or what do you think? Does the same issue occur if you just try to build vanilla upstream LLVM from sources in llvm.org? If so, if you'd like to post that as a bug to upstream LLVM bug tracker, the fix can then trickle in back to us in a merge since we follow LLVM upstream development. 4) Not sure how to nicely test whether the bundled 'node' is good for the given platform or not - perhaps that might have a specific Linux only check to make it strictly available only on Linux.
Thanks for the writeup, this looks useful for anyone trying on NetBSD, Jukka 2016-03-14 9:39 GMT+02:00 <[email protected]>: > Hi All, > > This one is just for the record so that if anyone happens to come here for > that reason can already find something:) I know that emscripten is > officially supported only on linux/win/osx (even though judging by the > scripts, it seems that earlier freebsd and dragonfly were supported as > well) but with a few changes I could make it work on NetBSD (actually 7.0) > as well. Here they are: > > 1) In the emsdk script I just hacked the platform check to let the > installer think it's running on linux: if platform.system()=='NetBSD' : > LINUX=true > 2) Also in the emsdk script, there's one call to tar which I had to > replace with gtar. > > That's already enough to be able to do ./emsdk update. > > The toughest thing was to find a workaround to the $ORIGIN problem in > NetBSD. So I had to look up the places in clang/fastcomp/src/Makefile.rules > where $ORIGIN is used (there are two of them) and replace them as > follows(#commented line is changed to the one below it): > > 1) > ifneq ($(HOST_OS),Darwin) > #LD.Flags += $(RPATH) -Wl, '$$ORIGIN' > LD.Flags += -Wl, -install_name -Wl, "@rpath/lib$(LIBRARYNAME)$(SHLIBEXT)" > else > LD.Flags += -Wl, -install_name -Wl, "@rpath/lib$(LIBRARYNAME)$(SHLIBEXT)" > endif > > 2) > ifneq ($(HOST_OS),Darwin) > ifdef TOOLNAME > #LD.Flags += $(RPATH) -Wl, '$$ORIGIN/../lib' > LD.Flags += $(RPATH) -Wl, @executable_path/../lib > endif > else > ... > > $ORIGIN also appears in clang/fastcomp/src/CMakeLists.txt where I changed > the following: > > 1) > else(UNIX) > if(NOT DEFINED CMAKE_INSTALL_RPATH) > #set(CMAKE_INSTALL_RPATH "\$ORIGIN/../lib${LLVM_LIBDIR_SUFFIX}") > set(CMAKE_INSTALL_RPATH "@executable_path/../lib") > ... > > After all these ./emsdk install latest and ./emsdk activate latest can be > issued. As I checked this out in a vm, I also noted that 2GB ram was not > enough to build emscripten on NetBSD-7.0 but 3GB was. Interestingly enough > the compiled node 4.1.1 dumps but that one can be installed separately as > package anyway. I carried out a few tests with hello world examples, > compiling zlib in the test suite and they do work:) However, I must add > that I'm no NetBSD expert so the changes I made may not be the best ones > but at least let emscripten run on the system. > > Best regards, > r0ller > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
