NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: emscripten & android ndk on NetBSD



r0ller <r0ller%freemail.hu@localhost> 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
> &#34;linux&#34;:) I almost managed to build my project that way but in
> the end when the linker tries to write the shared library object
> I&#39;m building, it fails with the error message &#34;function not
> implemented&#34;. I made a ktrace and kdump showed that the reason was
> &#34;unimplemented fallocate&#34; 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&#39;t tried it out yet if it really
> works on the phone. I&#39;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.

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index