Unable to compile under DOS since inclusion of mpqfs

[Srandista]

Operating System

Other (please specify)

DevilutionX version

Other (please specify version number)

Describe

During the compilation of a code, where libmpq was replaced by mpqfs for DOS, I get following errors:

/home/srandista/Downloads/DevilutionX/build-dos/_deps/mpqfs-src/src/mpq_archive.c:391:20: error: implicit declaration of function 'fdopen'; did you mean 'fopen'? [-Wimplicit-function-declaration]
  391 |         FILE *fp = fdopen(fd, "rb");
      |                    ^~~~~~
      |                    fopen
/home/srandista/Downloads/DevilutionX/build-dos/_deps/mpqfs-src/src/mpq_archive.c:391:20: error: initialization of 'FILE *' from 'int' makes pointer from integer without a cast [-Wint-conversion]

Commit before library replacing (e6f958b) compiles just fine. Windows (even SDL1) builds are also unaffected.

To Reproduce

Build latest source code for DOS with commands provided in Build from Source article on wiki.

Expected Behavior

No response

Additional context

No response

[AJenbo]

Could you please test #8538

[Srandista]

I did, but the error still occurred:

/home/srandista/Downloads/DiaDOS/DevilutionX/build-dos/_deps/mpqfs-src/src/mpq_archive.c:391:20: error: implicit declaration of function 'fdopen'; did you mean 'fopen'? [-Wimplicit-function-declaration]
  391 |         FILE *fp = fdopen(fd, "rb");
      |                    ^~~~~~
      |                    fopen
/home/srandista/Downloads/DiaDOS/DevilutionX/build-dos/_deps/mpqfs-src/src/mpq_archive.c:391:20: error: initialization of 'FILE *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
gmake[2]: *** [_deps/mpqfs-build/CMakeFiles/mpqfs.dir/build.make:79: _deps/mpqfs-build/CMakeFiles/mpqfs.dir/src/mpq_archive.c.obj] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2995: _deps/mpqfs-build/CMakeFiles/mpqfs.dir/all] Error 2

I checked in build-dos directory, and the changes from mpqfs commit did applied (string "&& !defined(DJGPP)" was removed).

[StephenCWills]

The inclusion of the fdopen declaration appears to depend on the __STRICT_ANSI__ compiler flag.

#ifndef __STRICT_ANSI__

#define L_ctermid 20
#define L_cusrid
/* #define STREAM_MAX   20 - DOS can change this */

int     dprintf(int _fd, const char *_format, ...) __attribute__ ((__format__ (__printf__, 2, 3)));
int     fileno(FILE *_stream);
FILE *  fdopen(int _fildes, const char *_type);
...

Building with make VERBOSE=1 gives me this.

cd /root/DevilutionX/build/dos/_deps/mpqfs-build && /opt/i386-pc-msdosdjgpp-toolchain/bin/i386-pc-msdosdjgpp-gcc -DMPQFS_HAS_BZIP2=1 -DMPQFS_HAS_ZLIB=1 -DSDL_DISABLE_EMMINTRIN_H -DSDL_DISABLE_IMMINTRIN_H -DSDL_DISABLE_MMINTRIN_H -DSDL_DISABLE_PMMINTRIN_H -DSDL_DISABLE_XMMINTRIN_H -I/root/DevilutionX/build/dos/_deps/mpqfs-src/include -I/root/DevilutionX/build/dos/_deps/mpqfs-src/src -I/root/DevilutionX/build/dos/_deps/zlib-build -I/root/DevilutionX/build/dos/_deps/zlib-src -I/root/DevilutionX/build/dos/_deps/bzip2-src -isystem /opt/i386-pc-msdosdjgpp-toolchain/i386-pc-msdosdjgpp/include -O3 -DNDEBUG -ffunction-sections -fdata-sections -fipa-pta -fdevirtualize-at-ltrans -Wall -Wextra -Wpedantic -Wconversion -Wsign-conversion -Wno-unused-function -std=c99 -MD -MT _deps/mpqfs-build/CMakeFiles/mpqfs.dir/src/mpq_archive.c.obj -MF CMakeFiles/mpqfs.dir/src/mpq_archive.c.obj.d -o CMakeFiles/mpqfs.dir/src/mpq_archive.c.obj -c /root/DevilutionX/build/dos/_deps/mpqfs-src/src/mpq_archive.c

The -std=c99 compiler flag makes sense, considering mpqfs explicitly targets C99 and turns compiler specific extensions off.

# --- C standard ---
# C99 is the baseline — it works on every toolchain DevilutionX targets,
# including PS2 (ee-gcc), DJGPP (DOS), and Emscripten.
set(CMAKE_C_STANDARD 99)
set(CMAKE_C_STANDARD_REQUIRED ON)
set(CMAKE_C_EXTENSIONS OFF)

Furthermore, the build seems to work if I turn extensions back on with set(CMAKE_C_EXTENSIONS ON). So I question whether mpqfs should be using fdopen() with compiler specific extensions off.

[StephenCWills]

@Srandista I just pushed a commit to #8538. I tested it myself already, but it wouldn't hurt to have another person check my work if you'd be willing to test again.

[Srandista]

Seems to be fine on my side too, code compiles and run under DOS as well.