Re: emscripten & android ndk on NetBSD

[Greg Troxel]

r0ller  writes:

> 1) The first topic would be asking for a kind of review (if anyone is
> interested) of what I posted about building emscripten on NetBSD in
> the google group of emscripten:
>
> https://groups.google.com/d/msg/emscripten-discuss/2z1NZrX3sA8/jNy4ACiIBwAJ
>
> Actually, they offered their support for NetBSD in the buildscript once I 
> sort out a few problems/questions they listed in their answer:
>
> https://groups.google.com/d/msg/emscripten-discuss/2z1NZrX3sA8/9sYySK32BgAJ
>
> However, as Im not a NetBSD expert, I thought Id first let
> my changes in the buildscript checked by someone more
> knowledgeable. So thatd be one task while the next task would be
> to discuss their questions like the one concerning vanilla llvm
> build. Just as a side note, till now my emscripten build works fine
> without any hickups. Unfortunately, I havent had the time since
> my post to try if a vanilla llvm would pose any problems on NetBSD or
> why building nodejs failed back then.

tar is BSD tar (really pax underneath) and gtar, if present, is
installed by pkgsrc.   Arguably packages should be using autoconf or
equivalent to find a version of tar that's acceptable if they don't
stick to invocations that comply with POSIX.  But I agree that code that
looks for gtar and if so uses it, and else uses tar is likely to work
and be pretty portable.

I really don't know about ORIGIN.


signature.asc
Description: PGP signature

Re: emscripten & android ndk on NetBSD

[Greg Troxel]

r0ller  writes:

> 2) I also tried building android ndk but the python buildscript failed
> and I have currently no time for getting really into it so I just

It would be nice to have the android tools working natively some day.

> tried the linux installation making use of the NetBSD linux
> compatibility layer. The only thing I had to change was the check for

But mostly the linux emulation works well.

> the host so that in case of NetBSD, the script evaluates it to
> linux:) I almost managed to build my project that way but in
> the end when the linker tries to write the shared library object
> Im building, it fails with the error message function not
> implemented. I made a ktrace and kdump showed that the reason was
> unimplemented fallocate for the linux syscall. Is it planned
> to have that implemented? Anyway, just for the record: for the time

In general, there isn't central planning, so it will get implemented
when someone writes and tests it.If you are interested in helping, I
would recommend that you start by building -current from sources.
Things tend to get implemented there, and some get pulled up to the
release branch, but most just end up in the next release.

I see that posix_fallocate(3) is implemented in NetBSD 7, and that
fallocate(2) is said to be nonportable.  So, if you were to make a new
linux syscall that just did posix_fallocate and ignored the flags, it
wouldn't be the right thing but it might actually work in practice.  If
not you can look into what flags are used and start implementing cases
of interest.

> being I created a named pipe with the name of the targeted shared
> library and when the build hangs waiting for someone to read the pipe,
> I just cat the named pipe into a file in another terminal:) It seemed
> to spit out the .so that way and the file command recognizes it as an
> ARM shared library but I havent tried it out yet if it really
> works on the phone. Ill let you know later:)

If it does work, that's super news.  The workaround sounds a bit kludgy,
but building ok with a feasible workaround is a pretty good situation.


signature.asc
Description: PGP signature

emscripten & android ndk on NetBSD

[r0ller]

Hi All,

This is my first mail to this list and hopefully I found the right user group 
with my topics -let me know if not.

1) The first topic would be asking for a kind of review (if anyone is 
interested) of what I posted about building emscripten on NetBSD in the google 
group of emscripten:

https://groups.google.com/d/msg/emscripten-discuss/2z1NZrX3sA8/jNy4ACiIBwAJ

Actually, they offered their support for NetBSD in the buildscript once I sort 
out a few problems/questions they listed in their answer:

https://groups.google.com/d/msg/emscripten-discuss/2z1NZrX3sA8/9sYySK32BgAJ

However, as Im not a NetBSD expert, I thought Id first let my changes 
in the buildscript checked by someone more knowledgeable. So thatd be one 
task while the next task would be to discuss their questions like the one 
concerning vanilla llvm build. Just as a side note, till now my emscripten 
build works fine without any hickups. Unfortunately, I havent had the time 
since my post to try if a vanilla llvm would pose any problems on NetBSD or why 
building nodejs failed back then.

2) I also tried building android ndk but the python buildscript failed and I 
have currently no time for getting really into it so I just tried the linux 
installation making use of the NetBSD linux compatibility layer. The only thing 
I had to change was the check for the host so that in case of NetBSD, the 
script evaluates it to linux:) I almost managed to build my project 
that way but in the end when the linker tries to write the shared library 
object Im building, it fails with the error message function not 
implemented. I made a ktrace and kdump showed that the reason was 
unimplemented fallocate for the linux syscall. Is it planned to have 
that implemented? Anyway, just for the record: for the time being I created a 
named pipe with the name of the targeted shared library and when the build 
hangs waiting for someone to read the pipe, I just cat the named pipe into a 
file in another terminal:) It seemed to spit out the .so that way and the file 
command recognizes it as an ARM shared library but I havent tried it out 
yet if it really works on the phone. Ill let you know later:)

Thanks for any help in advance!

Best regards,
r0ller