GNOME Bugzilla – Bug 542803
g_spawn_async_with_pipes fails on Win32 with GLib 2.16.4
Last modified: 2009-12-21 00:45:56 UTC
The attached test program fails with "g_spawn_async failed: Failed to execute helper program (Invalid argument)" when running against GLib 2.16.4 (happens also with 2.16.3). When running the same executable against GLib 2.14.2, it works and the result.txt contains "ok". Both gspawn-win32-helper.exe and gspawn-win32-helper-console.exe are present in both runtime environments. Tested on Windows 2000 Professional. Am I doing something wrong? NB: I wrote the output into a file because I can't see the output of printf on the Windows command prompt.
Created attachment 114482 [details] Test case The called 'gcc' is from the Mingw project and accessible through the PATH environment variable.
Created attachment 114483 [details] Additional file for the test case
Works fine here... both on XP and 2000. Try running with the environment variable G_SPAWN_WIN32_DEBUG set to some value, and post the output here, please.
I got the following messages: calling C:\geany_svn\gtk\bin\gspawn-win32-helper.exe with argv: argv[0]: C:\geany_svn\gtk\bin\gspawn-win32-helper.exe argv[1]: 5 argv[2]: 6 argv[3]: z argv[4]: - argv[5]: - argv[6]: - argv[7]: y argv[8]: y argv[9]: - argv[10]: gcc argv[11]: -Wall argv[12]: -o argv[13]: test.exe argv[14]: untitled.c argv[15]: NULL g_spawn_async failed: Failed to execute helper program (Invalid argument)
And I assume C:\geany_svn\gtk\bin\gspawn-win32-helper.exe is the correct path to that program? That looks 100% correct. I don't understand...
No, it's not the correct path. The correct one is C:\geany_svn\gtk\bin\gspawn-win32-helper.exe (without the 'bin' subdirectory). But this seems to be the cause. With the tested GLib 2.14.2, only "gspawn-win32-helper.exe" is called without any path specification and so it works but in GLib 2.16.x the wrong path is prepended. Why?
The full path is used so that the gspawn-win32-helper.exe program is found even if the folder where it is is not in PATH, and isn't the current working directory. It is a requirement that gspawn-win32-helper.exe is in the "bin" subfolder of the GLib installation directory, where the GLib DLLs also are. It has always been a requirement that the relative location of files of a GLib installation is not changed from what it is in the binary packages (zip files) it originates from. It was just a coincidence that gspawn-win32-helper.exe happened to be found in 2.14 if it was in PATH. What is your GLib installation's directory structure then? Where are the DLLs, the helper EXEs, and the message catalogs (.mo files)? Have you set up it yourself, or some 3rd-party installer?
I'm using your win32 packages (zips) from gtk.org. I unpack them and just move everything from the bin directory to the toplevel directory. E.g.: etc/ lib/ share/ gspawn-win32-helper.exe gspawn-win32-helper-console.exe libgtkwin32.dll libglib.dll ... (filenames aren't completely correct but I guess you got the point) Ok, I moved all the DLLs and EXEs back to bin/ and all is working again. Thanks for clarifying this, I just assumed it's intended to work one level above the bin/ dir because it did so in the past releases but it's not a big problem at all. Only the gettext problem I told you some time ago is annoying.
Actually, I guess it might be a bit too strict to require that the helper exes are in a "bin" folder. The code could well be changed a bit so that it would be enough if they were in the same folder as the GLib DLL. I'll try to do that.
I'm having the same problem with Midori. The binaries are in the toplevel directory, and not in a unix-style subfolder. And then spawning commands fails. As you suggested, it would be nice to retain the original behaviour.
Well, GLib is a "unix-style" library, just live with it.