Open Gnumaru opened 9 years ago
I'll try to build WebGL, but I don't know when I'll have time for it. In the meantime, how did you install Unity? Winetricks, PoL, or just plain Wine? What components? What wine? Etc.
The environment was: Ubuntu 14.10 64 bits Playonlinux using 32 bits wine version 1.7.37 Unity 5 32 bits
Unity was installed on playonlinux with the following options
POL_Wine_InstallFonts POL_Call POL_Install_directx9 POL_Call POL_Install_dotnet20 POL_Call POL_Install_dotnet35 POL_Call POL_Install_dotnet40 POL_Call POL_Install_tahoma POL_Call POL_Install_vcrun2008 POL_Call POL_Install_vcrun2010 POL_Call POL_Install_mono210 POL_Call POL_Install_d3dx9_36 POL_Call POL_Install_d3dcompiler_43 POL_Call POL_Install_dxdiag POL_Call POL_Install_dxfullsetup POL_Call POL_Install_physx POL_Call POL_Install_corefonts POL_Call POL_Install_wininet POL_Call POL_Install_msxml6 POL_Call POL_Install_ie8 Set_OS "winxp" "sp3" POL_Wine_OverrideDLL "native, builtin" "mscore" POL_Wine_OverrideDLL "builtin, native" "dnsapi" POL_Wine_OverrideDLL "" "mscorsvw.exe"
The build error occurs in any project, even a blank one, one which has just been created, with only an empty scene and no asset or gameobject.
The error seems to occur when unity calls il2cpp ("/home/username/.PlayOnLinux/wineprefix/Unity3D500/drive_c/Program Files/Unity/Editor/Data/il2cpp/il2cpp.exe") to convert the dotnet bytecode (intermediate language if you preffer) to c++ sourcecode, or maybe when it calls emscripten ("/home/username/.PlayOnLinux/wineprefix/Unity3D500/drive_c/Program Files/Unity/Editor/Data/PlaybackEngines/webglsupport/BuildTools/Emscripten/emscripten.py") to convert the c++ source code to javascript.
Soonner I tought it could be related to il2cpp (because the stack trace points to UnityEditorInternal.IL2CPPBuilder), but now I thinks it is probably related to emscripten (even though it is not mentioned in the stack trace), because il2cpp is also used for the iOS builds, and my iOS builds are working just fine.
My guess is that the way dotnet (the real microsoft dotnet, installed under wine) calls a process and get it's exit code does not work as intended when running on wine. If il2cpp works fine (because my iOS builds also work fine), then maybe the way dotnet calls another dotnet process works under wine. But emscripten is a python script, and maybe the way dotnet calls another non dotnet executable does not work fine on wine, therefore the dotnet code cant get back the exprected exite code from the called process (the "UnityEditor.Utils.Program.get_ExitCode ()" of the stack trace).
Dotnet/mono runs "foreign" processes with
System.Diagnostics.Process.Start("C:\\path\\to\\my\\executable.exe");
or
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = "C:\\executable.exe";
startInfo.Arguments = "some list of arguments";
Process.Start(startInfo);
and the process exit code can be get this way:
Process p = Process.Start(startInfo);
while(!p.HasExited){
System.Threading.Thread.Sleep(100); // sleep 100 miliseconds
}
int exitCode = p.ExitCode;
doSomethingWithTheExitCode(exitCode);
As can be seen on the stack trace, the getter method for the ExitCode property is where the exception occurs
InvalidOperationException: The process must exit before getting the requested information.
System.Diagnostics.Process.get_ExitCode ()
So maybe the called process is not exiting (maybe it is looping), or the called process is not returning any exit code, or something like that...
Install Unity again, but only with the fonts. My guess is that the whole problem is there. Unity 5 runs just fine with only fonts (assuming you're using wine 1.7.34 or newer).
As you sugested, I have installed unity with absolutely nothing but "Microsoft Core Fonts", on playonlinux using wine 1.7.40 (At first I installed event without ms core fonts, but then unity showed no texts besides the ones for the application menus).
I created a new project, no assets, only one empty scene with a camera, and then I tried again the webgl build.
Unity hanged for a few seconds (really hanged, the application windown went black, that's what ubuntu does with hanging application windows), and after that it went back to respond, but produced no artifacts and presented me with two stack trace error bubbles.
The first was:
Win32Exception: ApplicationName='"C:\Program Files\Unity\Editor\Data\PlaybackEngines\webglsupport/BuildTools/Emscripten_Win/python/2.7.5.3_64bit/python.exe"', CommandLine='"C:\Program Files\Unity\Editor\Data\PlaybackEngines\webglsupport/BuildTools/Emscripten/emcc" -Oz -s NO_EXIT_RUNTIME=1 -o "C:/users/gnumaru/Meus Documentos/New Unity Project 1/Assets/../Temp/StagingArea/Data\Native\UserAssembly.bc" @"C:\users\gnumaru\Temp\tmp390e7c50.tmp"', CurrentDirectory='C:/users/gnumaru/Meus Documentos/New Unity Project 1/Assets/../Temp/EmscriptenWork'
System.Diagnostics.Process.Start_noshell (System.Diagnostics.ProcessStartInfo startInfo, System.Diagnostics.Process process)
System.Diagnostics.Process.Start_common (System.Diagnostics.ProcessStartInfo startInfo, System.Diagnostics.Process process)
System.Diagnostics.Process.Start ()
(wrapper remoting-invoke-with-check) System.Diagnostics.Process:Start ()
UnityEditor.Utils.Program.Start () (at C:/buildslave/unity/build/Editor/Mono/Utils/Program.cs:33)
NativeCompiler.RunProgram (System.Diagnostics.ProcessStartInfo startInfo) (at C:/buildslave/unity/build/Editor/Mono/BuildPipeline/Il2Cpp/NativeCompiler.cs:42)
NativeCompiler.Execute (System.String arguments, System.String compilerPath) (at C:/buildslave/unity/build/Editor/Mono/BuildPipeline/Il2Cpp/NativeCompiler.cs:26)
UnityEditor.WebGL.Il2Cpp.EmscriptenCompiler.LinkObjects (IEnumerable`1 sources, System.String outfile)
UnityEditor.WebGL.Il2Cpp.EmscriptenCompiler.MultiThreadedCompile (System.String outfile, IEnumerable`1 sources, IEnumerable`1 includePaths, Boolean exceptionSupport)
UnityEditor.WebGL.Il2Cpp.EmscriptenCompiler.CompileDynamicLibrary (System.String outFile, IEnumerable`1 sources, IEnumerable`1 includePaths, IEnumerable`1 libraries, IEnumerable`1 libraryPaths)
UnityEditorInternal.IL2CPPBuilder.Run () (at C:/buildslave/unity/build/Editor/Mono/BuildPipeline/Il2Cpp/IL2CPPUtils.cs:290)
UnityEditorInternal.IL2CPPUtils.RunIl2Cpp (System.String stagingAreaData, IIl2CppPlatformProvider platformProvider, System.Action`1 modifyOutputBeforeCompile, UnityEditor.RuntimeClassRegistry runtimeClassRegistry) (at C:/buildslave/unity/build/Editor/Mono/BuildPipeline/Il2Cpp/IL2CPPUtils.cs:218)
UnityEditor.WebGL.WebGlBuildPostprocessor.PostProcess (BuildPostProcessArgs args)
UnityEditor.PostprocessBuildPlayer.Postprocess (BuildTarget target, System.String installPath, System.String companyName, System.String productName, Int32 width, Int32 height, System.String downloadWebplayerUrl, System.String manualDownloadWebplayerUrl, BuildOptions options, UnityEditor.RuntimeClassRegistry usedClassRegistry) (at C:/buildslave/unity/build/Editor/Mono/BuildPipeline/PostprocessBuildPlayer.cs:316)
UnityEditor.HostView:OnGUI()
And the second was:
Error building Player: Win32Exception: ApplicationName='"C:\Program Files\Unity\Editor\Data\PlaybackEngines\webglsupport/BuildTools/Emscripten_Win/python/2.7.5.3_64bit/python.exe"', CommandLine='"C:\Program Files\Unity\Editor\Data\PlaybackEngines\webglsupport/BuildTools/Emscripten/emcc" -Oz -s NO_EXIT_RUNTIME=1 -o "C:/users/gnumaru/Meus Documentos/New Unity Project 1/Assets/../Temp/StagingArea/Data\Native\UserAssembly.bc" @"C:\users\gnumaru\Temp\tmp390e7c50.tmp"', CurrentDirectory='C:/users/gnumaru/Meus Documentos/New Unity Project 1/Assets/../Temp/EmscriptenWork'
The stack trace is slightly differente from what I had the previous times, and now emscripten seems to really be the culprit.
Searching the project folder, I can see the generated cpp source code:
cd ~/New Unity Project;
find ./ -iname "*.cpp" | sort;
./Temp/StagingArea/Data/il2cppOutput/AssemblyAttributes_g_Mono_Security_Assembly.cpp
./Temp/StagingArea/Data/il2cppOutput/AssemblyAttributes_g_mscorlib_Assembly.cpp
./Temp/StagingArea/Data/il2cppOutput/AssemblyAttributes_g_replacements_Assembly.cpp
./Temp/StagingArea/Data/il2cppOutput/AssemblyAttributes_g_System_Assembly.cpp
./Temp/StagingArea/Data/il2cppOutput/AssemblyAttributes_g_System_Core_Assembly.cpp
./Temp/StagingArea/Data/il2cppOutput/AssemblyAttributes_g_UnityEngine_Assembly.cpp
./Temp/StagingArea/Data/il2cppOutput/AssemblyAttributes_g_UnityEngine_UI_Assembly.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Arrays_0.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Arrays_1.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Arrays_2.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Arrays_3.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Arrays_4.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_0.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_10.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_11.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_12.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_13.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_14.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_15.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_16.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_17.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_18.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_19.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_1.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_20.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_21.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_22.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_23.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_24.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_25.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_26.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_27.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_28.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_29.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_2.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_30.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_31.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_32.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_3.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_4.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_5.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_6.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_7.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_8.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Generics_9.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_Mono.Security_0.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_mscorlib_0.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_mscorlib_1.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_mscorlib_2.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_mscorlib_3.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_mscorlib_4.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_mscorlib_5.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_mscorlib_6.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_mscorlib_7.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_replacements_0.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_System_0.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_System.Core_0.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_UnityEngine_0.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_UnityEngine_1.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_UnityEngine_2.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_UnityEngine.UI_0.cpp
./Temp/StagingArea/Data/il2cppOutput/Bulk_UnityEngine.UI_1.cpp
./Temp/StagingArea/Data/il2cppOutput/GeneratedInvokers.cpp
./Temp/StagingArea/Data/il2cppOutput/GenericMethods0.cpp
./Temp/StagingArea/Data/il2cppOutput/GenericMethods1.cpp
./Temp/StagingArea/Data/il2cppOutput/GenericMethods2.cpp
./Temp/StagingArea/Data/il2cppOutput/GenericMethods3.cpp
./Temp/StagingArea/Data/il2cppOutput/GenericMethods4.cpp
./Temp/StagingArea/Data/il2cppOutput/GenericMethods5.cpp
./Temp/StagingArea/Data/il2cppOutput/Il2CppGenericInstDefinitions.cpp
./Temp/StagingArea/Data/il2cppOutput/Il2CppMetadataCacheData.cpp
./Temp/StagingArea/Data/il2cppOutput/Il2CppTypeDefinitions.cpp
./Temp/StagingArea/Data/il2cppOutput/Mono.Security.cpp
./Temp/StagingArea/Data/il2cppOutput/mscorlib.cpp
./Temp/StagingArea/Data/il2cppOutput/replacements.cpp
./Temp/StagingArea/Data/il2cppOutput/stringLiterals.cpp
./Temp/StagingArea/Data/il2cppOutput/System.Core.cpp
./Temp/StagingArea/Data/il2cppOutput/System.cpp
./Temp/StagingArea/Data/il2cppOutput/UnityClassRegistration.cpp
./Temp/StagingArea/Data/il2cppOutput/UnityEngine.cpp
./Temp/StagingArea/Data/il2cppOutput/UnityEngine.UI.cpp
./Temp/StagingArea/Data/il2cppOutput/UnityICallRegistration.cpp
But unity is failing to use emscripten on them to generate the javascript sources. Probably emscripten enters an endless loop, unity awaits for a few moments, give it up after the timeout and present us with the stack traces.
Other two more things. First, some paths on the stack trace have paths with mixed slash and backslash, like the following:
C:\Program Files\Unity\Editor\Data\PlaybackEngines\webglsupport/BuildTools/Emscripten_Win/python/2.7.5.3_64bit/python.exe
Since microsoft windows always use backslash, and unix systems use slashes, maybe wine is passing paths to unity using slashes instead of backslashes, wich causes dotnet to be unable to execute python and emscripten with it.
Second, the path to unity's python tells it is a 64 bit version, even though I installed a 32 bit version of unity on a 32 bit version of wine. If it is indeed a 64 bit version, the webgl build should not work even on machines runing native 32 bit versions of microsoft windows.
Before running the build, I have openned up a terminal an executed the following.
while [ 1 ]; do ps aux | grep -i il2; sleep 1; done;
Wich, before the build, gave me nothing. But, during the build, gave me three different outputs, in sequence. First:
C:\Program Files\Unity\Editor\Data\MonoBleedingEdge\bin\mono.exe C:\Program Files\Unity\Editor\Data\il2cpp/AssemblyPatcher/AssemblyPatcher.exe -a C:\users\gnumaru\Meus Documentos\New Unity Project 1\Temp\StagingArea\Data\Managed/mscorlib.unpatched.dll -o C:\users\gnumaru\Meus Documentos\New Unity Project 1\Temp\StagingArea\Data\Managed/mscorlib.dll -c C:\Program Files\Unity\Editor\Data\il2cpp/assemblypatcher_config.txt --log-config C:\Program Files\Unity\Editor\Data\il2cpp/AssemblyPatcher.Log.Config.xml -s C:\users\gnumaru\Meus Documentos\New Unity Project 1\Temp\StagingArea\Data\Managed
Then:
C:\Program Files\Unity\Editor\Data\MonoBleedingEdge\bin\mono.exe C:\Program Files\Unity\Editor\Data\Tools/UnusedByteCodeStripper2/UnusedBytecodeStripper2.exe -out C:\users\gnumaru\Meus Documentos\New Unity Project 1\Temp\StagingArea\Data\Managed -l none -c link -x C:\Program Files\Unity\Editor\Data\Tools\native_link.xml -f C:\Program Files\Unity\Editor\Data\il2cpp\LinkerDescriptors -x C:\users\gnumaru\Meus Documentos\New Unity Project 1/Temp/StagingArea/Data/methods_pointedto_by_uievents.xml -d C:\users\gnumaru\Meus Documentos\New Unity Project 1\Temp\StagingArea\Data\Managed -a C:\users\gnumaru\Meus Documentos\New Unity Project 1\Temp\StagingArea\Data\Managed\UnityEngine.UI.dll
And then:
C:\Program Files\Unity\Editor\Data\MonoBleedingEdge\bin\mono.exe C:\Program Files\Unity\Editor\Data\PlaybackEngines\webglsupport/BuildTools/InternalCallRegistrationWriter/InternalCallRegistrationWriter.exe -assembly=C:\users\gnumaru\Meus Documentos\New Unity Project 1\Temp\StagingArea\Data\Managed\UnityEngine.dll -output=Temp/StagingArea/Data\il2cppOutput/UnityICallRegistration.cpp
but, doing the same grep for "emc" (a substring of emscripten) and for "pyth" (for python) never returned one single output (except for the python instance that was running playonlinux's main window). It seems that python, and therefore emscripten, doesnt get called at all, probably due to the slash/backslash mixing in the paths.
This does look like a wine bug. Final thing, are you running Unity in a 32 bit prefix or a regular 64 bit?
32 bit prefix.
OK, so the problem's not there. Well, this is an upstream issue, so I suggest you file a bug on Wine, there's not much we can do here right now. If you really want the fix now the best thing to do is probably start hacking Wine and create a patch, I doubt someone from Wine will take care of this. Sorry.
Recently I was implementing an asset postprocessor when I bumped into something interesting.
dotnet/mono runtime have a class named "System.IO.Directory" which contains a static method "Directory.GetCurrentDirectory()" that returns a string with the full path to the current directory the application is running (eg.: C:/projectdir/).
Unity has a class "UnityEngine.Application" wich contains a static property "Application.dataPath" that returns the full path to the Assets folder (eg.: C:/projectdir/Assets).
Now comes the interesting part: "System.IO.Directory.GetCurrentDirectory()" from within a behaviour script returns the project directory with back slashes only, whereas "UnityEngine.Application.dataPath" returns the assets path with forward slashes only.
I wrote the folowing behaviour script and ran it
public class TestComponent : MonoBehaviour{
public void Start(){
UnityEngine.Debug.Log(System.IO.Directory.GetCurrentDirectory());
UnityEngine.Debug.Log(UnityEngine.Application.dataPath);
}
}
Which gave me the folowing outputs (they are in order, the firs one is for Directory.GetCurrentDirectory() and the second for Application.dataPath):
Z:\home\user\unityProject
UnityEngine.Debug:Log(Object)
TestComponent:Start()
Z:/home/user/unityProject/Assets
UnityEngine.Debug:Log(Object)
TestComponent:Start()
I made this test both on linux with wine and on Windows, and the behaviour was the same: "Directory.GetCurrentDirectory()" game me back slashes and "Application.dataPath" game me forward slashes. It seems that unity's own methods of listing directories uses always forward slashes, whereas dotnet/mono framework methods use the OSs default directory separator. I have also tested calling "System.IO.Directory.GetCurrentDirectory()" from within a native mono REPL (interpreter) on linux and it gave me forward slashes, as expected, since I was using a linux native mono build, and linux directory separator is a forward slash.
What is weird is thath, since windows only accepts '\' as directory separator, and we now know that unity mixes '\' and '/', every external process call made by unity should fail, which we know is not the case since the webglbuilds work on windows...
Trying to do webgl builds on unity 5 results in errors and produces no artifacts. The errors shown on the editor log are the following:
This bug has been shared on the unity forum here:
http://forum.unity3d.com/threads/webgl-build-target-fails-on-linux-with-wine.307074/
Unity 5 introduced a new build target, WebGL, that produces games that can be run in any javascript+webgl enabled browsers without the use of the unity npapi plugin.
Starting from september 2015, the chromium browser (the open source base for google chrome) will be removing entirely the support for npapi plugins, and every other major browsers (firefox, ie, safari etc) will also be dropping support, although they don't seem to have a timeline yet, wich will make the webgl build target the ONLY way of building unity games for the web. There is, and will be, no real cross-browser solution for replacing npapi but using javascript, webgl and the likes. Therefore, making wegl builds work on wine is a major concern for every unity developer which uses only linux.