search

mstorsjo / llvm-mingw

An LLVM/Clang/LLD based mingw-w64 toolchain
Other
1.75k stars 176 forks source link

Fatal error when build ffmpeg with PGO: 'sys/mman.h' file not found #390

Closed Andarwinux closed 5 months ago

Andarwinux commented 5 months ago 
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

Biswa96 commented 5 months ago

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.

mstorsjo commented 5 months ago

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.

mstorsjo commented 5 months ago

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.

Biswa96 commented 5 months ago

Shouldn't that mmap function be private (or not exported) in Windows?

mstorsjo commented 5 months ago

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.