[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.