[BUG]show “fcntl(): Bad file descriptor”

[cyz7758520]

Host OS: Windows
NDK:22.1.7171670

I execute ndk-build.cmd under CMD, it always shows “fcntl(): Bad file descriptor”.

[enh-google]

the internet seems to think that this is caused by the -O option that ndk-build passes to make. tidev/titanium-sdk@60fba0b passes --output-sync=none to avoid it.

it's unclear to me whether this is just an inherent problem on Windows? if so, i guess ndk-build should not pass -O on Windows. but wouldn't we have seen this ourselves?

[DanAlbert]

My understanding is that this isn't a real error. Everything works correctly, it just also prints this. We see this when we run tests but all the tests behave correctly.

Is this causing a problem that you're seeing, or is the bug here just "it's printing extra stuff"?

[cyz7758520]

When I use the old NDK 21.4.7075529, there is no such display.

[DanAlbert]

We know, that's when we updated make and started seeing this. It just doesn't appear to cause any harm.

Can you answer the question I asked in the previous comment? Is this causing a problem? We need to know how to prioritize this.

[cyz7758520]

I haven't found any problems so far, I just want to raise them first to prevent potential problems.

[rprichard]

I'd be happy to work on this today -- I think I recall mostly debugging it already.

[DanAlbert]

All yours :)

[cyz7758520]

Do I need to close the issue now?

[rprichard]

No, it can stay open.

[rprichard]

I filed an upstream bug with GNU make: https://savannah.gnu.org/bugs/?60444. I also attached a patch to that bug that I think would fix this issue.

[rprichard]

FWIW, I tried to build upstream make (with a recent, upstream gnulib) with x86_64-w64-mingw32-gcc, and was unsuccessful. I tried overriding fcntl in configure like so:

export CFLAGS="-Wno-error -Wno-format"
../configure --host=x86_64-w64-mingw32 \
  gl_cv_header_working_fcntl_h=yes \
  ac_cv_func_fcntl=yes \
  gl_cv_func_fcntl_f_dupfd_works=yes \
  gl_cv_func_fcntl_f_dupfd_cloexec=yes \

It seems that gnulib has a fcntl.h that defines F_GETFD to 2, but make already has code to define F_GETFD to 1 and F_SETLKW to 2, so we get this compiler error:

../src/w32/compat/posixfcn.c: In function ‘fcntl’:
../src/w32/compat/posixfcn.c:50:7: error: duplicate case value
   50 |       case F_SETLKW:
      |       ^~~~
../src/w32/compat/posixfcn.c:43:7: note: previously used here
   43 |       case F_GETFD:
      |       ^~~~

When I leave fcntl as-is, I hit a different gnulib issue:

/usr/bin/x86_64-w64-mingw32-ld: /usr/lib/gcc/x86_64-w64-mingw32/10-win32/../../../../x86_64-w64-mingw32/lib/libmsvcrt.a(libmsvcrt-oss00292.o):(.text+0x0): multiple definition of `_isatty'; src/w32/compat/posixfcn.o:posixfcn.c:(.text+0x629): first defined here

Here the trouble is that a newer version of gnulib (i.e. newer than in the NDK source tree) adds a bunch of defines in unistd.h, like so:

#define read _read
#define open _open
#define isatty _isatty

make is defining its own isatty in src/w32/compat/posixfcn.c because the MSVC isatty returns true for the NUL file. With mingw-w64, io.h declares _isatty as dllimport, but isatty as an ordinary function. The result is that, even though main.c and posixfcn.c both have #define isatty _isatty, the reference to isatty in main.o refers to __imp__isatty, while posixfcn.o defines _isatty. libmsvcrt.a(libmsvcrt-oss00292.o) provides both __imp__isatty and _isatty.

There is a commit message suggesting that this redefining can be turned off, but I don't know how to do that.

mingw-w64 and MSVC both provide the unprefixed names AFAICT, but I see MSDN docs and header annotations indicating that the unprefixed names are deprecated.

I'm not sure how to make the gnulib autoconf stuff work, so my preference is to:

• Just apply my patch locally, or
• Switch to the upstream-supported Windows configuration (ie. build_w32.bat, using MSVC -- maybe using kokoro?), or
• Just remove the output synchronization flag (-O) from ndk-build.cmd.

[DanAlbert]

Switching to MSVC is usually a good idea. Might be more work than it's worth compared to just patching locally though.

[rprichard]

There is another variant of this bug that happens on macOS:

• https://savannah.gnu.org/bugs/?52922
• https://jira.appcelerator.org/browse/TIMOB-27776

On macOS, the output-sync feature tries to lock the output file, but the file locking APIs don't work on a pipe. This problem started happening with NDK r21. Gradle captures the output of ndk-build (probably using a pipe), and I see the errors with either Android Studio or running ./gradlew at the CLI, but only if I configure gradle to pass -jN to ndk-build, which isn't the default.

It looks like the r21e macOS make output-sync works fine if the output is a tty or a real file, but not if it's a pipe.

[rprichard]

For Windows, I put in a workaround in r23 beta6 / rc1:
https://android-review.googlesource.com/c/platform/ndk/+/1755318/

That workaround isn't in the final r23 release, though.

• https://android.googlesource.com/platform/ndk/+log/refs/tags/ndk-r23/build/ndk-build.cmd
• https://android.googlesource.com/platform/ndk/+log/refs/tags/ndk-r23-beta6/build/ndk-build.cmd

Maybe it was lost during the transition from git_ndk-r23-release to aosp-ndk-release-r23?

I swapped out make's build system, which actually fixes this issue instead (but only on Windows, not macOS):

• https://android-review.googlesource.com/c/platform/ndk/+/1817587/
• https://android-review.googlesource.com/c/toolchain/make/+/1816840

I suppose we want one of these fixes in r23b, but I'm not sure which.

[DanAlbert]

First option (dropping -O) is the safest. We should probably start there, especially since it's what we intended to ship. Might end up doing the other in r23c depending on how the M1 work goes?

[DanAlbert]

We're well past r23 now :)

[rajatgupta1998]

Is this fixed? Not screaming that this is actually causing problems, but I see something similar on macOS as well.
Not sure if this is relevant either.

Environment details:

• macOS ventura 13.4 - Apple Silicon M2 Pro
• Android Studio Flamingo | 2022.2.1 Patch 2
  Build #AI-222.4459.24.2221.10121639, built on May 12, 2023.
  Runtime version: 17.0.6+0-17.0.6b802.4-9586694 aarch64
• NDK version 25.2.9519653
• Android SDK compile sdk and build tools 33.x
  Screenshot below: