oops. fixed in https://android-review.googlesource.com/#/c/134610/.
On Sun, Feb 22, 2015 at 10:44 AM, Kevin Cernekee <cerne...@google.com> wrote: > On Fri, Feb 20, 2015 at 11:00 AM, Paul Eggert <egg...@cs.ucla.edu> wrote: >> Kevin Cernekee wrote: >> >>> However, I don't see how any of the m4 changes address the problem >>> that is causing the test cases to fail: lib/getdtablesize.c still >>> wants to rely on sysconf(_SC_OPEN_MAX) on Android, and that call just >>> blindly returns 256 on all released versions of the OS. This is why >>> my earlier submission changed it to use getrlimit() instead. >> >> >> Thanks for explaining. How about if we go even further than that patch, and >> avoid the use of _SC_OPEN_MAX everywhere? I applied the attached two >> patches; I think only the second one matters to you. Do they fix the >> problem? > > Unfortunately I don't think we define RLIM_SAVED_* on Android: > > arm-linux-androideabi-gcc -DHAVE_CONFIG_H -I. -I.. > -DGNULIB_STRICT_CHECKING=1 -pie -fPIE -MT getdtablesize.o -MD -MP > -MF $depbase.Tpo -c -o getdtablesize.o getdtablesize.c &&\ > mv -f $depbase.Tpo $depbase.Po > getdtablesize.c: In function 'getdtablesize': > getdtablesize.c:107:26: error: 'RLIM_SAVED_CUR' undeclared (first use > in this function) > && lim.rlim_cur != RLIM_SAVED_CUR > ^ > getdtablesize.c:107:26: note: each undeclared identifier is reported > only once for each function it appears in > getdtablesize.c:108:26: error: 'RLIM_SAVED_MAX' undeclared (first use > in this function) > && lim.rlim_cur != RLIM_SAVED_MAX) > ^ > make[4]: *** [getdtablesize.o] Error 1 > make[4]: Leaving directory `/shared/testdir/gllib' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/shared/testdir/gllib' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/shared/testdir/gllib' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/shared/testdir' > make: *** [all] Error 2 > > > So maybe we need to add something like: > > #ifndef RLIM_SAVED_CUR > #define RLIM_SAVED_CUR RLIM_INFINITY > #endif > > Based on comments in tests/test-sys_resource.c it looks like somebody > may have started a <sys/resource.h> replacement, but there is more > work to be done. -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer.