Re: emscripten 1.36.0 on NetBSD

[r0l...@freemail.hu]

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

[juj j]

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

--
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 emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[r0l...@freemail.hu]

Hi Jukka,

That'd be pretty nice -and sorry for the Easter lag:)

The answers to the other questions:

2) As far as I know, tar on NetBSD is the normal BSD tar and gtar is the GNU tar. While it's the other way around on linux: tar is the GNU tar and the BSD tar is called bsdtar:) That's why I rather changed the call from tar to gtar (instead of looking for an option that is similar to the one that was unaccepted by BSD tar) in order to retain the GNU tar behaviour.

3) I haven't tried building llvm on its own but I also think that it's rather an llvm issue. I'll give it a try and check with the llvm guys. But it's rather strange as clang-3.6.2 is available on NetBSD and the llvm guys seem to keep an eye on NetBSD -at least when reporting a bug, NetBSD can be directly selected from the OS-es listed as a platform on which the bug appeared so it's not just put in the 'other' option basket.

4) Concerning node, I don't know what went wrong. It should just compile without any problems but I'll try to build it on its own as well. However, as mentioned node-4.1.1 is available as a binary package on NetBSD so for the time being it's not the biggest showstopper to get emscripten running:)

By the way, since then I managed to build sqlite3, readline, zlib and two personal C/C++ github projects with emscripten and they do work without any issues:) I'll get back to you with the updates as soon as I have something.

Best regards,

r0ller

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Brion Vibber]

On Tue, Mar 29, 2016 at 1:04 AM, <r0l...@freemail.hu> wrote:

2) As far as I know, tar on NetBSD is the normal BSD tar and gtar is the GNU tar. While it's the other way around on linux: tar is the GNU tar and the BSD tar is called bsdtar:) That's why I rather changed the call from tar to gtar (instead of looking for an option that is similar to the one that was unaccepted by BSD tar) in order to retain the GNU tar behaviour.

Note that Mac OS X also comes with BSD tar as 'tar' but doesn't provide GNU tar, so there's no 'gtar' available there. However it might be extended with an option that isn't in the NetBSD version... probably the '--strip' option?

Might be best to do a check for 'gtar' and use that if present, but fall back to 'tar' if it's not; that should work pretty reliably across BSD and GNU/Linux variants.

-- brion

[r0l...@freemail.hu]

Hi Brion,

I don't know anything about Macs but as far as I can remember the install script handles them separately -actually I saw there three branches: win/linux/mac- so the tar/gtar changes for linux won't affect the mac branch I guess.

Regards,

r0ller

[Brion Vibber]

I see only two branches in update_emsdk; one for 'WINDOWS' and one for 'OSX or LINUX'. They all call the same download_and_unzip function, which calls the same untargz function, which makes the same shell-out to tar on any OS. (.zip files are used on Windows, so something different is called in that case. .tar.gz are used on both Mac and Linux.)

-- brion

--

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 emscripten-disc...@googlegroups.com.

[r0l...@freemail.hu]

Hi Brion,

Yepp, you're right -I recalled it wrong:)

Regards,

r0ller

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.