Re: emscripten & android ndk on NetBSD

[r0ller <r0ller%freemail.hu@localhost>]

Hi Greg&All,

I agree that a native build would be the best but I'm no python expert (and the android ndk scripts are in python) and I got quickly stuck in understanding why the build script fails. Nevertheless, that's my long term goal as well.

However, for the time being the workaround I described works just fine -today I even tried using the .so on the phone and it ran without any problem.

I admit that the workaround for the fallocate is kludgy but it can be made a bit handier if 'cat fifo > file &' is called in the project build script before invoking the compiler or even another solution that I found at stackoverflow ( http://stackoverflow.com/questions/27817046/unzip-file-to-named-pipe-and-file ) that uses the buffer command to the achieve the same but it requires installing the buffer pkg.

Concerning implementing fallocate, I just don't feel that confident about OS development as I'm rather an application developer so I guess I'll end up getting the ndk installer work natively sooner than writing a new linux syscall.

Best regards,
r0ller

-------- Eredeti levél --------

Feladó: Greg Troxel <
gdt%lexort.com@localhost
>

Tárgy: Re: emscripten & android ndk on NetBSD

Címzett: r0ller <
r0ller%freemail.hu@localhost
>



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
> I'm 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 haven't tried it out yet if it really
> works on the phone. I'll 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.