ndk r11b libc.so files don't contain all the symbols that r10e libc.so files did

[froydnj]

I've tried to compile Firefox for Android with r11 and r11b, and I've found missing symbols (relative to r10e) in the libc.so files provided with both of them:

• arc4random_addrandom
• getdtablesize
• arc4random_stir
• getdents

Possibly others; this is my incomplete list from poking around with readelf -sW. The above symbols are declared in header files, so it's a bit frustrating that they don't exist in libc.so. (They do seem to exist in the libc.a files, FWIW.)

arc4random_addrandom's non-existence prevents Firefox for Android from compiling with r11b; the linker complains about not being able to find the symbol.

I think this is similar to #23 (comment), but different enough that the issues can't be solved by recompiling. It's not clear to me whether #23 addresses the libc.so or the libc.a files, though.

[DanAlbert]

Those arc4random functions were removed from BSD (from which we derive our implementations). The motivation for this is that the responsibility of stirring/adding randomness is not the user's job. That task should be done by the implementation/the kernel. The implementation is self-stirring, randomness comes from the kernel.

getdtablesize was removed from POSIX. Should replace with sysconf(_SC_OPEN_MAX).

The getdents change actually matches glibc. Form their man page:

Glibc does not provide a wrapper for this system call; call it using syscall(2). You will need to define the linux_dirent structure yourself. However, you probably want to use readdir(3) instead.

And at the top:

DESCRIPTION
This is not the function you are interested in. Look at readdir(3) for the POSIX conforming C library interface.

If for some reason readdir is not sufficient for firefox, use syscall(__NR_getdents). You should take a look at how it's being used though. If it isn't already written that way, that means that it is Android (or at least non-GNU Linux) specific code because glibc would require it to be written that way anyway. There is probably a better way to write it.

[froydnj]

Thanks for the explanation! I assume this reasoning is behind the "Removed from all versions of NDK libc, m, and dl all symbols which the platform versions of those libs do not support." release note?

[DanAlbert]

Correct. There's a non-zero chance that some of the things that were removed shouldn't have been (see #1), so don't hesitate to file bugs if you find other things that seem like they should be there.

[timofey-retailnext]

Thanks for explanation,
are there any specific reasons why removed arc4random_* functions still exist in stdlib.h ?

ex. {NDK-r12b}/platforms/android-19/arch-arm/include/stdlib.h lines 119-120:
extern void arc4random_stir(void);
extern void arc4random_addrandom(unsigned char *, int);

[DanAlbert]

Because our headers are and have always been incorrect. Recently they're more wrong than they used to be since the shared libraries, which were also wrong, were fixed.

We're trying to fix this (#120), but until recently even we didn't have a good idea of what functions were available in each API level/architecture. The shared libraries in the NDK (as of r12) are should all be a correct representation of the world now though.