[x264:x86-windows] build failure #11765

lone-wolf-akela · 2020-06-04T07:30:59Z

Host Environment

OS: Windows 10 2004
Compiler: vs2019 16.6.1

To Reproduce
Steps to reproduce the behavior:
./vcpkg install x264

Failure logs

-- Configuring x86-windows-dbg
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
    Command failed: D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/bin/bash.exe --noprofile --norc --debug -c " CC='D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/share/automake-1.16/compile cl.exe -nologo' CXX='D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/share/automake-1.16/compile cl.exe -nologo' LD='link.exe -verbose' AR='D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/share/automake-1.16/ar-lib lib.exe -verbose' RANLIB=':' CCAS=':' NM='dumpbin.exe -symbols -headers -all' DLLTOOL='link.exe -verbose -dll' ./../src/14d026c3bd-bca2ebf740/configure --build=x86_64-pc-mingw32 --target=i686-pc-mingw32 --host=i686-pc-mingw32 --enable-strip --disable-lavf --disable-swscale --disable-avs --disable-ffms --disable-gpac --disable-lsmash --disable-asm --enable-debug --disable-silent-rules --verbose --enable-shared --disable-static --prefix=/D/source/test/vcpkg/installed/x86-windows/debug --bindir='${prefix}'/../tools/x264/debug/bin --sbindir='${prefix}'/../tools/x264/debug/sbin --includedir='${prefix}'/../include --datarootdir='${prefix}'/share/x264"
    Working Directory: D:/source/test/vcpkg/buildtrees/x264/x86-windows-dbg
    Error code: 1
    See logs for more information:
      D:\source\test\vcpkg\buildtrees\x264\config-x86-windows-dbg-out.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_configure_make.cmake:461 (vcpkg_execute_required_process)
  ports/x264/portfile.cmake:15 (vcpkg_configure_make)
  scripts/ports.cmake:76 (include)

config-x86-windows-dbg-out.log

The text was updated successfully, but these errors were encountered:

lone-wolf-akela · 2020-06-04T07:37:38Z

By the way, I notice the error message says it is trying to use D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/share/automake-1.16
but this folder does not exist.
I've tried manually install automake in mysy2. After installing automake, it gives me another error:

-- Configuring x86-windows-dbg
-- Configuring x86-windows-rel
-- Building x86-windows-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:136 (message):
    Command failed: D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/bin/make.exe -j 13 --trace -f Makefile all
    Working Directory: D:/source/test/vcpkg/buildtrees/x264/x86-windows-dbg
    See logs for more information:
      D:\source\test\vcpkg\buildtrees\x264\build-x86-windows-dbg-out.log
      D:\source\test\vcpkg\buildtrees\x264\build-x86-windows-dbg-err.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_build_make.cmake:200 (vcpkg_execute_build_process)
  scripts/cmake/vcpkg_install_make.cmake:24 (vcpkg_build_make)
  ports/x264/portfile.cmake:29 (vcpkg_install_make)
  scripts/ports.cmake:76 (include)


Error: Building package x264:x86-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: x264:x86-windows
  Vcpkg version: 2020.02.04-nohash

build-x86-windows-dbg-err.log
build-x86-windows-dbg-out.log

The .depend file in x86-windows-dbg folder

JackBoosY · 2020-06-04T08:47:34Z

Confirmed. That's a vcpkg_configure_make issue.

julianxhokaxhiu · 2020-06-05T13:13:31Z

After some investigations I've found that the CC env var is now valued as compile cl.exe -nologo and no more as cl or cl.exe.

This bring a wrong environment detection, and it thinks it is GNU while it should be MS. Even fixing the configure file by hand leads to some LINK 1189 issues which I can't yet figure out why they are showing up.

I'll update this issue as soon as I figure out what's the issue...

//EDIT1: So yes, I do agree the issue is vcpkg_configure_make and it seems the CC change was introduced by this commit 27c6c94
The funny fact although is that this very same commit did also update the x264 portfile, so I wonder if the author managed to build x264 successfully on its own workstation...
Another nasty thing I've found is that the commit forces the automake compile script, although it puts the automake binary behind the AUTOCONFIG flag. This would make any package that is being built via MSYS to basically be broken by default ( unless the flag is defined in the relative portfile )

//EDIT2: So, I found the core issue living in here but I'm not sure which is the correct patch to solve it. Long story short, the main issue is linked between:

CC/CCX default value ( which is cl.exe being called by automake compile script )
x264 -link flag
The automake compile script eating -l parameter out of the -link flag and thinking it needs to link ink.lib

So, to solve it, I patched the CC/CCX flags by removing the ${MSYS_ROOT}/usr/share/automake-1.16/compile path before cl.exe ( which will allow the compile to proceed as always ). Finally I patched the x264 portfile by adding the --disable-cli flag in the vcpkg_configure_make section.

Be aware that the current way CC/CCX flags are being set also trigger a false GNU detection by most of the scripts you build out of make. So I think it's just wise to remove the automake compile script path before cl.exe.

I can submit a PR if you're interested. Just let me know in case.

//EDIT3: It seems this approach works fine when running vcpkg from the Developer Console on VS2019. It does not work on a normal CMD session or on a CI environment ( unless you load the Dev Console session there too )

//EDIT4: Managed to get it fixed for AppVeyor too! Here you can find the project where I have all the patched files accordingly: https://github.com/julianxhokaxhiu/ffmpegCI ( I even bumped both ffmpeg and x264 library branches, so don't mind that part )

emptyVoid · 2020-06-08T04:36:35Z

I think it's better to summon the author of that change first, as he has done tremendous work improving/correcting make builds, there has to be a reason why call to cl.exe are routed via automake.

@Neumann-A, could you, please, comment on this issue?

Neumann-A · 2020-06-08T09:12:12Z

improving/correcting make builds, there has to be a reason why call to cl.exe are routed via automake.

If a port is truly using autotools there should not be a problem with routing it through automakes compile cl script which also helps configure do the right thing better.
ffmpeg seems to be a case of custom configure script since I cannot see any configure.ac in the repo which makes things always a bit complicated since the assumption/requirements vary a lot between different custom configure scripts. So it is hard to decide what is required and what not. x264 and ffmpeg seems to be such cases that require a bit of special attention since they do not follow autotools rules. The regression probably happend when I replaced the custom cl wrapper with the automake compile wrapper. Since it was a script change vcpkg probably did not properly detected the regression.
If only CC and CXX need to be correct this can be done by setting the environment variables in the portfile before calling vcpkg_configure_make. (If _vcpkg_append_to_configure_environment would be working correctly but there is a DEFINED missing in the if statement of that function)

MVoz · 2020-06-08T10:08:57Z

config-x86-windows-...-out.log

Unknown option --build=x86_64-pc-mingw32, ignored
Unknown option --target=i686-pc-mingw32, ignored
Unknown option --disable-silent-rules, ignored
Unknown option --verbose, ignored
Unknown option --disable-static, ignored
Unknown option --sbindir=${prefix}/tools/x264/sbin, ignored
Unknown option --mandir=${prefix}/share/x264, ignored
Unknown option --docdir=${prefix}/share/x264, ignored
Unknown option --datarootdir=${prefix}/share/x264, ignored

build-x86-windows-...-err.log

...

cl : Command line warning D9024 : unrecognized source file type 'x264dll.o', object file assumed
cl : Command line warning D9025 : overriding '/O1' with '/Od'
cl : Command line warning D9025 : overriding '/MDd' with '/MT'
cl : Command line warning D9002 : ignoring unknown option '-g'
cl : Command line warning D9002 : ignoring unknown option '-m32'
cl : Command line warning D9002 : ignoring unknown option '-std=gnu99'
cl : Command line warning D9002 : ignoring unknown option '-mpreferred-stack-boundary=6'
cl : Command line warning D9002 : ignoring unknown option '-fno-tree-vectorize'
cl : Command line warning D9002 : ignoring unknown option '-fno-zero-initialized-in-bss'
cl : Command line warning D9002 : ignoring unknown option '-MM'
cl : Command line warning D9002 : ignoring unknown option '-g0'
cl : Command line warning D9024 : unrecognized source file type 'example.o', object file assumed
make: *** [Makefile:313: .depend] Error 2

flags gcc ?

julianxhokaxhiu · 2020-06-08T12:48:01Z

improving/correcting make builds, there has to be a reason why call to cl.exe are routed via automake.

If a port is truly using autotools there should not be a problem with routing it through automakes compile cl script which also helps configure do the right thing better.
ffmpeg seems to be a case of custom configure script since I cannot see any configure.ac in the repo which makes things always a bit complicated since the assumption/requirements vary a lot between different custom configure scripts. So it is hard to decide what is required and what not. x264 and ffmpeg seems to be such cases that require a bit of special attention since they do not follow autotools rules. The regression probably happend when I replaced the custom cl wrapper with the automake compile wrapper. Since it was a script change vcpkg probably did not properly detected the regression.
If only CC and CXX need to be correct this can be done by setting the environment variables in the portfile before calling vcpkg_configure_make. (If _vcpkg_append_to_configure_environment would be working correctly but there is a DEFINED missing in the if statement of that function)

So If I understand this correctly, all we need to do is redefine CC and CXX? I'll try that and let you know!

Neumann-A · 2020-06-08T13:53:00Z

Invoking cvtres.exe:
 /machine:x86
 /verbose
 /out:"C:\Users\ALEXAN~1\AppData\Local\Temp\lnk{66828486-1515-4CEE-AF4E-A35D4B86EDD3}.tmp"
 /readonly
 "x264res.o"
Microsoft (R) Windows Resource To Object Converter Version 14.26.28805.0
Copyright (C) Microsoft Corporation.  All rights reserved.

adding resource. type:VERSION, name:1, language:0x0409, flags:0x30, size:736

x264.o : error LNK2019: unresolved external symbol _CommandLineToArgvW referenced in function _get_argv_utf8

Unused libraries:
  C:\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\um\x86\shell32.lib

x264.exe : fatal error LNK1120: 1 unresolved externals

Is the error I see in #11836 (only in x86-windows)

ivanovmp · 2020-07-01T08:08:37Z

So how is it going? I still cannot install neither x264:x86-windows nor x264:x64-windows.

felix-h · 2020-07-03T07:18:39Z

I am hitting this as well. Happy to help testing fixes.

Neumann-A · 2020-07-03T07:27:08Z

waiting for #11550 to be merged before touching #11836 again

samofoz · 2020-08-10T10:26:54Z

--disable-cli

After some investigations I've found that the CC env var is now valued as compile cl.exe -nologo and no more as cl or cl.exe.

This bring a wrong environment detection, and it thinks it is GNU while it should be MS. Even fixing the configure file by hand leads to some LINK 1189 issues which I can't yet figure out why they are showing up.

I'll update this issue as soon as I figure out what's the issue...

//EDIT1: So yes, I do agree the issue is vcpkg_configure_make and it seems the CC change was introduced by this commit 27c6c94
The funny fact although is that this very same commit did also update the x264 portfile, so I wonder if the author managed to build x264 successfully on its own workstation...
Another nasty thing I've found is that the commit forces the automake compile script, although it puts the automake binary behind the AUTOCONFIG flag. This would make any package that is being built via MSYS to basically be broken by default ( unless the flag is defined in the relative portfile )

//EDIT2: So, I found the core issue living in here but I'm not sure which is the correct patch to solve it. Long story short, the main issue is linked between:

CC/CCX default value ( which is cl.exe being called by automake compile script )

x264 -link flag

The automake compile script eating -l parameter out of the -link flag and thinking it needs to link ink.lib

So, to solve it, I patched the CC/CCX flags by removing the ${MSYS_ROOT}/usr/share/automake-1.16/compile path before cl.exe ( which will allow the compile to proceed as always ). Finally I patched the x264 portfile by adding the --disable-cli flag in the vcpkg_configure_make section.

Be aware that the current way CC/CCX flags are being set also trigger a false GNU detection by most of the scripts you build out of make. So I think it's just wise to remove the automake compile script path before cl.exe.

I can submit a PR if you're interested. Just let me know in case.

//EDIT3: It seems this approach works fine when running vcpkg from the Developer Console on VS2019. It does not work on a normal CMD session or on a CI environment ( unless you load the Dev Console session there too )

//EDIT4: Managed to get it fixed for AppVeyor too! Here you can find the project where I have all the patched files accordingly: https://github.com/julianxhokaxhiu/ffmpegCI ( I even bumped both ffmpeg and x264 library branches, so don't mind that part )

got this after the patches:

C:\vcpackage\vcpkg>vcpkg install ffmpeg[ffmpeg,x264]:x64-windows
Computing installation plan...
The following packages will be built and installed:
ffmpeg[avresample,core,ffmpeg,gpl,x264]:x64-windows

x264[core]:x64-windows
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-windows...
Starting package 1/2: x264:x64-windows
Building package x264[core]:x64-windows...
Could not locate cached archive: C:\Users\samof\AppData\Local\vcpkg\archives\8c\8c69993c6bda1cf9d79b896c35678372ab30c041.zip
-- Using cached C:/vcpackage/vcpkg/downloads/mirror-x264-303c484ec828ed0d8bfe743500e70314d026c3bd.tar.gz
-- Cleaning sources at C:/vcpackage/vcpkg/buildtrees/x264/src/14d026c3bd-bca2ebf740.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/vcpackage/vcpkg/downloads/mirror-x264-303c484ec828ed0d8bfe743500e70314d026c3bd.tar.gz
-- Applying patch uwp-cflags.patch
-- Using source at C:/vcpackage/vcpkg/buildtrees/x264/src/14d026c3bd-bca2ebf740.clean
-- Acquiring MSYS Packages...
-- Acquiring MSYS Packages... OK
-- Configuring x64-windows-dbg
-- Configuring x64-windows-rel
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Installing x64-windows-dbg
-- Installing x64-windows-rel
-- Fixing pkgconfig
-- Fixing pkgconfig - release
-- Checking file: C:/vcpackage/vcpkg/packages/x264_x64-windows/lib/pkgconfig/x264.pc
-- CHECK_LIB_x264_RELEASE:CHECK_LIB_x264_RELEASE-NOTFOUND
CMake Error at scripts/cmake/vcpkg_fixup_pkgconfig.cmake:239 (message):
Library "x264" was not found! If it is a system library use the
SYSTEM_LIBRARIES parameter for the vcpkg_fixup_pkgconfig call! Otherwise,
correct the *.pc file
Call Stack (most recent call first):
scripts/cmake/vcpkg_fixup_pkgconfig.cmake:316 (vcpkg_fixup_pkgconfig_check_files)
ports/x264/portfile.cmake:31 (vcpkg_fixup_pkgconfig)
scripts/ports.cmake:79 (include)

Error: Building package x264:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: x264:x64-windows
Vcpkg version: 2020.06.15-nohash

Additionally, attach any relevant sections from the log files above.

julianxhokaxhiu · 2020-08-10T10:41:38Z

@samofoz I'm currently using this patchset now https://github.com/julianxhokaxhiu/ffmpegCI/tree/master/patch

That post is "more or less" outdated now.

samofoz · 2020-08-10T10:55:37Z

@samofoz I'm currently using this patchset now https://github.com/julianxhokaxhiu/ffmpegCI/tree/master/patch

That post is "more or less" outdated now.

Same problem with these patches:

C:\vcpackage\vcpkg>vcpkg install ffmpeg[ffmpeg,x264]:x64-windows --recurse
Computing installation plan...
The following packages will be rebuilt:
ffmpeg[avresample,core,ffmpeg,gpl,x264]:x64-windows
The following packages will be built and installed:

x264[core]:x64-windows
Additional packages (*) will be modified to complete this operation.
Starting package 1/3: ffmpeg:x64-windows
Removing package ffmpeg:x64-windows...
Removing package ffmpeg:x64-windows... done
Elapsed time for package ffmpeg:x64-windows: 301.3 ms
Detecting compiler hash for triplet x64-windows...
Starting package 2/3: x264:x64-windows
Building package x264[core]:x64-windows...
Could not locate cached archive: C:\Users\samof\AppData\Local\vcpkg\archives\29\29c0006e028bef9d4232f3a7ff8d53b322c542b3.zip
-- Downloading https://github.com/mirror/x264/archive/stable.tar.gz...
-- Extracting source C:/vcpackage/vcpkg/downloads/mirror-x264-stable.tar.gz
-- Applying patch uwp-cflags.patch
-- Using source at C:/vcpackage/vcpkg/buildtrees/x264/src/stable-05ed9f7d66.clean
-- Acquiring MSYS Packages...
-- Acquiring MSYS Packages... OK
-- Configuring x64-windows-dbg
-- Configuring x64-windows-rel
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Installing x64-windows-dbg
-- Installing x64-windows-rel
-- Fixing pkgconfig
-- Fixing pkgconfig - release
-- Checking file: C:/vcpackage/vcpkg/packages/x264_x64-windows/lib/pkgconfig/x264.pc
-- CHECK_LIB_x264_RELEASE:CHECK_LIB_x264_RELEASE-NOTFOUND
CMake Error at scripts/cmake/vcpkg_fixup_pkgconfig.cmake:239 (message):
Library "x264" was not found! If it is a system library use the
SYSTEM_LIBRARIES parameter for the vcpkg_fixup_pkgconfig call! Otherwise,
correct the *.pc file
Call Stack (most recent call first):
scripts/cmake/vcpkg_fixup_pkgconfig.cmake:316 (vcpkg_fixup_pkgconfig_check_files)
ports/x264/portfile.cmake:31 (vcpkg_fixup_pkgconfig)
scripts/ports.cmake:79 (include)

Error: Building package x264:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: x264:x64-windows
Vcpkg version: 2020.06.15-nohash

Additionally, attach any relevant sections from the log files above.

julianxhokaxhiu · 2020-08-10T11:04:36Z

You can't just update the x264 patch, you need also the one in scripts/cmake as the core issue is around how msys builds with make ( long story short, most of the software, including x264 thinks are building on Linux rather than on MINGW ). Update that and you'll get a valid build.

samofoz · 2020-08-10T11:30:02Z

You can't just update the x264 patch, you need also the one in scripts/cmake as the core issue is around how msys builds with make ( long story short, most of the software, including x264 thinks are building on Linux rather than on MINGW ). Update that and you'll get a valid build.

Hi Julian,

I did copy both the patches. Check the logs carefully - the library is being compiled fine but the error seems to be during installation:

Library "x264" was not found! If it is a system library use the
SYSTEM_LIBRARIES parameter for the vcpkg_fixup_pkgconfig call! Otherwise,
correct the *.pc file

julianxhokaxhiu · 2020-08-10T13:07:32Z

Library "x264" was not found! If it is a system library use the
SYSTEM_LIBRARIES parameter for the vcpkg_fixup_pkgconfig call! Otherwise,
correct the *.pc file

I see, I'm personally building using x86-windows-static so it could be an issue regarding dynamic builds which I've never done before. I may check on that later but it's not under my targets atm. Sorry, can't help yet.

samofoz · 2020-08-14T06:55:13Z

New issue with latest vcpkg: ffmpeg[ffmpeg,x264] installation fails with "libx264 not found":

C:\vcpackage\vcpkg>vcpkg install ffmpeg[ffmpeg,x264]:x64-windows
Computing installation plan...
The following packages will be built and installed:
ffmpeg[avresample,core,ffmpeg,gpl,x264]:x64-windows

x264[core]:x64-windows
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-windows...
Starting package 1/2: x264:x64-windows
Building package x264[core]:x64-windows...
Using cached binary package: C:\Users\samof\AppData\Local\vcpkg\archives\80\803584d5f475e64bf2f465dfb329357606bc8ea4.zip
Building package x264[core]:x64-windows... done
Installing package x264[core]:x64-windows...
Installing package x264[core]:x64-windows... done
Elapsed time for package x264:x64-windows: 203.3 ms
Starting package 2/2: ffmpeg:x64-windows
Building package ffmpeg[avresample,core,ffmpeg,gpl,x264]:x64-windows...
Could not locate cached archive: C:\Users\samof\AppData\Local\vcpkg\archives\20\20a085d14f8e51af705bee60ebb9a68ee99fe9ad.zip
-- Using cached C:/vcpackage/vcpkg/downloads/ffmpeg-ffmpeg-n4.2.tar.gz
-- Cleaning sources at C:/vcpackage/vcpkg/buildtrees/ffmpeg/src/n4.2-a4d149a5c6.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/vcpackage/vcpkg/downloads/ffmpeg-ffmpeg-n4.2.tar.gz
-- Applying patch 0001-create-lib-libraries.patch
-- Applying patch 0003-fix-windowsinclude.patch
-- Applying patch 0004-fix-debug-build.patch
-- Applying patch 0005-fix-libvpx-linking.patch
-- Applying patch 0006-fix-StaticFeatures.patch
-- Using source at C:/vcpackage/vcpkg/buildtrees/ffmpeg/src/n4.2-a4d149a5c6.clean
-- Acquiring MSYS Packages...
-- Acquiring MSYS Packages... OK
-- Building Options: --enable-asm --enable-yasm --disable-doc --enable-debug --enable-runtime-cpudetect --enable-gpl --disable-openssl --enable-ffmpeg --disable-ffplay --disable-ffprobe --disable-libvpx --enable-libx264 --disable-opencl --disable-lzma --disable-bzlib --enable-avresample --disable-cuda --disable-nvenc --disable-cuvid --disable-libnpp --disable-avisynth --disable-static --enable-shared --extra-cflags=-DHAVE_UNISTD_H=0
-- Building Release Options: --extra-cflags=-MD --extra-cxxflags=-MD
-- Building ffmpeg for Release
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
Command failed: C:/vcpackage/vcpkg/downloads/tools/msys2/msys64/usr/bin/bash.exe --noprofile --norc C:/vcpackage/vcpkg/ports/ffmpeg\build.sh C:/vcpackage/vcpkg/buildtrees/ffmpeg/x64-windows-rel C:/vcpackage/vcpkg/buildtrees/ffmpeg/src/n4.2-a4d149a5c6.clean C:/vcpackage/vcpkg/packages/ffmpeg_x64-windows "--enable-asm --enable-yasm --disable-doc --enable-debug --enable-runtime-cpudetect --enable-gpl --disable-openssl --enable-ffmpeg --disable-ffplay --disable-ffprobe --disable-libvpx --enable-libx264 --disable-opencl --disable-lzma --disable-bzlib --enable-avresample --disable-cuda --disable-nvenc --disable-cuvid --disable-libnpp --disable-avisynth --disable-static --enable-shared --extra-cflags=-DHAVE_UNISTD_H=0 --extra-cflags=-MD --extra-cxxflags=-MD"
Working Directory: C:/vcpackage/vcpkg/buildtrees/ffmpeg/x64-windows-rel
Error code: 1
See logs for more information:
C:\vcpackage\vcpkg\buildtrees\ffmpeg\build-x64-windows-rel-out.log

Call Stack (most recent call first):
ports/ffmpeg/portfile.cmake:210 (vcpkg_execute_required_process)
scripts/ports.cmake:79 (include)

Error: Building package ffmpeg:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: ffmpeg:x64-windows
Vcpkg version: 2020.06.15-nohash

Additionally, attach any relevant sections from the log files above.

emptyVoid · 2020-08-14T07:00:54Z

@samofoz, I would advice openning a new issue -- comments in the closed issues sometimes are being ignored.

NancyLi1013 assigned JackBoosY Jun 4, 2020

JackBoosY added the category:port-bug The issue is with a library, which is something the port should already support label Jun 4, 2020

emptyVoid mentioned this issue Jun 8, 2020

[vcpkg-acquire-msys] Improvement #11810

Merged

emptyVoid mentioned this issue Jun 8, 2020

[libmesh] Support Windows #11835

Open

Neumann-A mentioned this issue Jun 8, 2020

[vcpkg/scripts/make] trying to iron out some issues #11836

Merged

JackBoosY added category:tool-update The issue is with build tool or build script, which requires update or should be executed correctly and removed category:port-bug The issue is with a library, which is something the port should already support labels Jun 12, 2020

JackBoosY mentioned this issue Jun 17, 2020

[x264] build failure #11979

Closed

Sibras mentioned this issue Jun 18, 2020

[ffmpeg] Add feature support for zlib, iconv, fdk-aac, mp3lame, opus, soxr, theora. #11277

Merged

NancyLi1013 mentioned this issue Jul 17, 2020

[x264] build failure #12447

Closed

sbr-dev mentioned this issue Jul 29, 2020

[x264] build failure on previous vcpkg version #12632

Closed

PhoebeHui mentioned this issue Jul 31, 2020

[ffmpeg] CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message): #12648

Closed

strega-nil closed this as completed in #11836 Aug 13, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[x264:x86-windows] build failure #11765

[x264:x86-windows] build failure #11765

lone-wolf-akela commented Jun 4, 2020 •

edited by JackBoosY

Loading

lone-wolf-akela commented Jun 4, 2020 •

edited by JackBoosY

Loading

JackBoosY commented Jun 4, 2020 •

edited

Loading

julianxhokaxhiu commented Jun 5, 2020 •

edited

Loading

emptyVoid commented Jun 8, 2020

Neumann-A commented Jun 8, 2020

MVoz commented Jun 8, 2020 •

edited

Loading

julianxhokaxhiu commented Jun 8, 2020

Neumann-A commented Jun 8, 2020 •

edited

Loading

ivanovmp commented Jul 1, 2020

felix-h commented Jul 3, 2020

Neumann-A commented Jul 3, 2020

samofoz commented Aug 10, 2020

julianxhokaxhiu commented Aug 10, 2020

samofoz commented Aug 10, 2020

julianxhokaxhiu commented Aug 10, 2020

samofoz commented Aug 10, 2020

julianxhokaxhiu commented Aug 10, 2020

samofoz commented Aug 14, 2020

emptyVoid commented Aug 14, 2020

[x264:x86-windows] build failure #11765

[x264:x86-windows] build failure #11765

Comments

lone-wolf-akela commented Jun 4, 2020 • edited by JackBoosY Loading

lone-wolf-akela commented Jun 4, 2020 • edited by JackBoosY Loading

JackBoosY commented Jun 4, 2020 • edited Loading

julianxhokaxhiu commented Jun 5, 2020 • edited Loading

emptyVoid commented Jun 8, 2020

Neumann-A commented Jun 8, 2020

MVoz commented Jun 8, 2020 • edited Loading

julianxhokaxhiu commented Jun 8, 2020

Neumann-A commented Jun 8, 2020 • edited Loading

ivanovmp commented Jul 1, 2020

felix-h commented Jul 3, 2020

Neumann-A commented Jul 3, 2020

samofoz commented Aug 10, 2020

julianxhokaxhiu commented Aug 10, 2020

samofoz commented Aug 10, 2020

julianxhokaxhiu commented Aug 10, 2020

samofoz commented Aug 10, 2020

julianxhokaxhiu commented Aug 10, 2020

samofoz commented Aug 14, 2020

emptyVoid commented Aug 14, 2020

lone-wolf-akela commented Jun 4, 2020 •

edited by JackBoosY

Loading

lone-wolf-akela commented Jun 4, 2020 •

edited by JackBoosY

Loading

JackBoosY commented Jun 4, 2020 •

edited

Loading

julianxhokaxhiu commented Jun 5, 2020 •

edited

Loading

MVoz commented Jun 8, 2020 •

edited

Loading

Neumann-A commented Jun 8, 2020 •

edited

Loading