Blender crashes under TravisCI windows VM

Environments Windows
1

Has any one tried to execute blender under the window version of TravisCI?

I have been trying to and it just bombs out.

$ cd …/blender-${BLENDER_VERSION}

The command “cd …/blender-${BLENDER_VERSION}” exited with 0.

$ ./blender --version

The command “./blender --version” exited with 127.

That command is a command-line only one, so no GUI is required (or wanted by me)

I started over on the blender dev forum, but this is beginning to feel like it is a TravisCI/powershell question. Even if the answer is, no, not supported

2

Can you add a link to your failed Travis build? (We need the exact commands – and how they were specified in the YAML – to diagnose this.)

3

Here is a failing build:

https://travis-ci.org/douglaskastle/blender-fake-addon/builds/608736558

and this was the contents of the Yaml file when it was executed:

4

OK, so in Build #493 the reason for the crash appeared delayed in stderr:

C:/Users/travis/build/douglaskastle/blender-2.80/blender.exe: error while loading shared libraries: libsndfile-1.dll: cannot open shared object file: No such file or directory

That file (libsndfile-1.dll) is shown in the preceding ls listing, but was not located by the DLL loader. In later builds you correctly cd-ed into ../blender-${BLENDER_VERSION} before running blender.exe from there, which allowed libsndfile-1.dll to be found.

(Although in Build #494 you forgot to prepend the executable file name with ./, so Git Bash searched for it only in the PATH (which doesn’t contain .) and failed.)

Builds #495 through #498 failed due to AVIFIL32.dll not found. This is most likely a Windows Multimedia component unavailable in Windows Server Core. See also this similar issue being faced by others.

Finally, Builds #499, #500, and #502 failed because of the /c argument to cmd.exe – note that Git Bash (just like MSYS / MSYS2) applies its path-conversion logic to change the /c to c: before cmd.exe sees it. To prevent that we need cmd //c.

I’m not familiar with PowerShell, so can’t comment on why Builds #501 and #503 failed silently. My guess at this point would be that it failed due to the same AVIFIL32.dll issue above.