Fatal error when build ffmpeg with PGO: 'sys/mman.h' file not found
Andarwinux opened this issue · comments
export CFLAGS="-fprofile-generate"
export LDFLAGS="-fprofile-generate -fuse-ld=lld"
git clone https://github.com/FFmpeg/FFmpeg.git
cd FFmpeg
./configure --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 --target-os=mingw32 --cc=x86_64-w64-mingw32-clang --disable-debug --disable-ffprobe --disable-ffplay --disable-doc
make -j$(nproc)
src/libswscale/utils.c:31:10: fatal error: 'sys/mman.h' file not found
31 | #include <sys/mman.h>
| ^~~~~~~~~~~~
llvm-mingw nightly
It appears that the issue may not be related to llvm-mingw. It is possible that there might be an underlying problem with the cross compilation environment.
It appears that the issue may not be related to llvm-mingw. It is possible that there might be an underlying problem with the cross compilation environment.
No, I can reproduce this issue with the instructions given. I presume that the chosen options for PGO somehow make some configure tests misdetect things.
See https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240111103300.68446-1-martin@martin.st/ for a potential fix for this issue. The issue is that the profiling runtime, which gets linked in when compiling with those flags, contains an implementation of the mmap function: https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/compiler-rt/lib/profile/WindowsMMap.c#L28 This caused ffmpeg's configure test to detect it, when it only tested for linking such a function with that name, without checking for the corresponding headers.
Shouldn't that mmap function be private (or not exported) in Windows?
Shouldn't that mmap function be private (or not exported) in Windows?
The profile runtime is statically linked into each executable, so any symbols in the compiler-rt runtime are exposed and available on the same level as the rest of the user's symbols. I guess it would be good to add suitable prefixes to this mmap implementation, to avoid clashes like this.