Build error on cygwin for x86_64-win64-vs12

[Timothy Madden]

Hello

I am trying to build libvpx from git and I get this error on cygwin during make :

4>InitializeBuildStatus:
           Touching "x64\Debug\obj_int_extract\obj_int_extract.tlog\unsuccessfulbuild".

ClCompile:
           E:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\x86_amd64\CL.exe
                 /c /I.
                 /I/cygdrive/e/Work/Qodec/Libs/libvpx
                 /Zi /nologo /W3 /WX- /Od /D WIN32 /D DEBUG /D _CRT_SECURE_NO_WARNINGS /D _CRT_SECURE_NO_DEPRECATE
                 /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /MTd /GS /fp:precise /Zc:wchar_t /Zc:forScope
/Fo"x64\Debug\obj_int_extract\cygdrive_e_Work_Qodec_Libs_libvpx_build_make_obj_int_extract.obj"
                 /Fd"x64\Debug\obj_int_extract\vc120.pdb" /Gd /TC /errorReport:queue
.\\cygdrive\e\Work\Qodec\Libs\libvpx\build\make\obj_int_extract.c

           obj_int_extract.c
4>c1 : fatal error C1083: Cannot open source file:
'.\\cygdrive\e\Work\Qodec\Libs\libvpx\build\make\obj_int_extract.c':
            No such file or directory
 [E:\Work\Qodec\_Output\Win64\build_libVPX-prefix\src\build_libVPX-build\obj_int_extract.vcxproj]
 [E:\Work\Qodec\_Output\Win64\build_libVPX.vcxproj]

(formatting is mine).

I see the build script is trying to pass cygwin-style paths to VC++ compiler on the command line.

I tried to fix the listed project file manually to use the right path, and then a similar error shows up somewhere later during the build. After a second substitute to fix the generated files, I could eventually get the build going on 64-bits (not on 32-bits, but it still installed the header and lib despite the remaining errors listed).

Using Windows 7 Professional SP1, Version 6.1.7601
My configure command line is:

"/cygdrive/e/Work/Qodec/Libs/libvpx/configure"
            "--target=x86_64-win64-vs12"
            "--enable-pic" "--enable-vp9" "--enable-webm-io" "--enable-runtime-cpu-detect"
            "--enable-postproc"      "--enable-multithread" "--disable-shared" "--enable-static"
            "--enable-static-msvcrt" "--disable-docs" "--enable-error-concealment"
            "--enable-static-msvcrt"
            "--prefix=build_libVPX-prefix"
            "--disable-unit-tests" "--disable-examples"

and the make command is just `make`.

The configure command completes successuflly, the error appears during make. I also tried with other configure options, like only the --target, the issue always shows up.

I suppose there is a line in the configure script that shuold translate cygwin-path to windows-path.  If so, can someone please let me know what the line is so I can apply a local patch to it ?

Thank you,
Timothy Madden

[termin...@gmail.com]

I pulled new updates from git.

I still get the error during `make`:

     6>cl : Command line warning D9002: ignoring unknown option '/home/dev/packages/libvpx/vp8/encoder/vp8_asm_enc_offsets.c' [E:\cygwin64\home\dev\packages\libvpx\vpx.vcxproj]
     6>cl : Command line error D8003: missing source filename [E:\cygwin64\home\dev\packages\libvpx\vpx.vcxproj]
         'x64\Release\obj_int_extract.exe' is not recognized as an internal or external command,
         operable program or batch file.
     6>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): error MSB3073: The command "call obj_int_extract.bat /home/dev/packages/libvpx x64\Release [E:\cygwin64\home\dev\packages\libvpx\vpx.vcxproj]
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(122,5): error MSB3073: :VCEnd" exited with code 1. [E:\cygwin64\home\dev\packages\libvpx\vpx.vcxproj]

[Tom Finegan]

If you haven't already, please file a bug at http://code.google.com/p/webm/issues/entry

Please include all of the information you've posted in this thread.

Beyond that I don't have any suggestions for a work around to use within cygwin: I don't use it. 

Note that configuring and building will work fine in MSYS. Using an MSYS shell instead of cygwin will avoid this problem entirely.

 

--
You received this message because you are subscribed to the Google Groups "Codec Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codec-devel...@webmproject.org.
To post to this group, send email to codec...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/codec-devel/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[James Zern]

Hi,

On Tue, Apr 22, 2014 at 10:23 AM, 'Tom Finegan
<tomfi...@google.com>' via Codec Developers

I submitted a few changes that should help [1][2]. There might still
be lingering issues with paths containing spaces.

[1] https://gerrit.chromium.org/gerrit/#/c/69858
[2] https://gerrit.chromium.org/gerrit/#/c/69859

[Timothy Madden]

I pulled updates from git.

The pathname error doesn't show up on cygwin anymore (though I *still* have the problem on *msys*: wrong pathname style building obj_int_extract.vcxproj),
but now for cygwin I have a new error:


       "E:\cygwin64\home\dev\packages\libvpx\vpx.sln" (Build target) (1) ->
       "E:\cygwin64\home\dev\packages\libvpx\vpxenc.vcxproj" (default target) (13) ->
       (ClCompile target) ->
         c1 : fatal error C1083: Cannot open source file: '.\webmenc.c': No such file or directory [E:\cygwin64\home\dev\packages\libvpx\vpxenc.vcxproj]


       "E:\cygwin64\home\dev\packages\libvpx\vpx.sln" (Build target) (1) ->
       "E:\cygwin64\home\dev\packages\libvpx\vpxdec.vcxproj" (default target) (6) ->
         c1 : fatal error C1083: Cannot open source file: '.\webmdec.c': No such file or directory [E:\cygwin64\home\dev\packages\libvpx\vpxdec.vcxproj]

    0 Warning(s)
    2 Error(s)

The missing files are named webmenc.cc and webmdec.cc instead of webmenc.c and webmdec.c.

Again, I can not understand how the build scripts work or generate the name, and I found no

line of code that would mention the wrong file name. Even `grep -R webmenc.c .` shows only results for the right file name: webmenc.cc.

Trying to manually fix the generated vpxenc.vcxproj file to include the correct file name, results in many 'Undefined reference' errors from the linker
 at the next build step

[Tom Finegan]

A couple of quick questions:

1) Are you running configure between running git pull and make? 

2) Are you running configure in the shell within which you are trying to build? (i.e. you're not trying to build in msys after configuring in cygwin, right?)

Manually fixing the MSVC projects is not the correct solution, but I need more information to understand what's going on. Please answer the above questions.

[Timothy Madden]

It appears I found my problem.

Cygwin won't see the proper access rights on a directory for the
current user, unless the Windows ACL on the directory explicitly lists
the current user with "full control" access rights, inherited to all
descendent objects (sub-directories / files).

If you try the build outside the cygwin home directory, you get the
funny situation that some of files generated by the build script are
listed by a cygwin shell session (for example with `ls`) as having no
access rights whatsoever, not even read for the owner u+r.

The Windows user has the needed permissions, so the build script
appears to start properly and do its work, but the cygwin session
(running under the same user) doesn't see any of the permissions and
sometimes reports access denied, sometimes fails silently !

Than the build fails.

I had to explicitly add the user running the cygwin shell session to
the directory ACLs for the vpx source and build directories, with
Windows `icacls` command, like :

USERNAME="$(whoami)"
icacls "${VPX_BUILD_DIR}" /Q /T /inheritance:e /grant "${USERNAME}:(OI)F"
icacls "${VPX_SRC_DIR}" /Q /T /inheritance:e /grant "${USERNAME}:(OI)F"


Can you pleas find a way to check for this situation and properly
return and error message after ./configure ? Or at least document it
in the README ?

Currently in this situation the build fails with what appears to be an
attempt to pass a cygwin-style path (starting with /cygdrive/c/...) to
the cl.exe compiler from visual studio.

Hope that helps,
Timothy Madden