This may be a tad off-topic, but I couldn't find any reference to this relative to XEmacs, and the problem seems to be peculiar to bjam. If I try to run bjam under XEmacs, e.g. via M-x compile, M-x shell-command, or even from inside an XEmacs shell buffer (running CMD), I get the error "spawn: Invalid argument". More specifically, if I run it via shell-command, I get this: ===================== ...found 331 targets... ...updating 1 target... gcc-Archive-action ..\phys_sim\bin\libphys_sim.lib\gcc-nocygwin\debug\architecture-native\debug-symbols-on\inlining-off\optimization-off\profiling-off\rtti-on\runtime-build-debug\runtime-link-dynamic\threading-single\vtable-thunks-default\libphys_sim.lib spawn: Invalid argument ====================== ... which indicates that bjam is in fact starting, but has some problem. Or maybe the tools do. If I run it in the same directory from a regular command window, it works fine. I'm running XEmacs 21.4, with recently updated packages. The bjam executable was downloaded yesterday. (I'm trying to use it for something other than Boost, BTW.) The toolset I'm using is MinGW, the latest stable full-package release, with no package updates. Anyone have an idea what might be wrong? I'm getting tired of looking at my build output in a command window and then hunting for line numbers in my source code. :-)
I've upgraded XEmacs to the latest stable release for Windows, and that didn't help with this problem. Perhaps I should build the latest bjam from sources? Dan Muller wrote:
This may be a tad off-topic, but I couldn't find any reference to this relative to XEmacs, and the problem seems to be peculiar to bjam.
If I try to run bjam under XEmacs, e.g. via M-x compile, M-x shell-command, or even from inside an XEmacs shell buffer (running CMD), I get the error "spawn: Invalid argument". More specifically, if I run it via shell-command, I get this:
===================== ...found 331 targets...
...updating 1 target...
gcc-Archive-action ..\phys_sim\bin\libphys_sim.lib\gcc-nocygwin\debug\architecture-native\debug-symbols-on\inlining-off\optimization-off\profiling-off\rtti-on\runtime-build-debug\runtime-link-dynamic\threading-single\vtable-thunks-default\libphys_sim.lib
spawn: Invalid argument ======================
... which indicates that bjam is in fact starting, but has some problem. Or maybe the tools do. If I run it in the same directory from a regular command window, it works fine.
I'm running XEmacs 21.4, with recently updated packages. The bjam executable was downloaded yesterday. (I'm trying to use it for something other than Boost, BTW.) The toolset I'm using is MinGW, the latest stable full-package release, with no package updates.
Anyone have an idea what might be wrong? I'm getting tired of looking at my build output in a command window and then hunting for line numbers in my source code. :-)
Dan Muller wrote:
I've upgraded XEmacs to the latest stable release for Windows, and that didn't help with this problem. Perhaps I should build the latest bjam from sources?
Dan Muller wrote:
This may be a tad off-topic, but I couldn't find any reference to this relative to XEmacs, and the problem seems to be peculiar to bjam.
If I try to run bjam under XEmacs, e.g. via M-x compile, M-x shell-command, or even from inside an XEmacs shell buffer (running CMD), I get the error "spawn: Invalid argument". More specifically, if I run it via shell-command, I get this: [text elided]
I'm running XEmacs 21.4, with recently updated packages. The bjam executable was downloaded yesterday. (I'm trying to use it for something other than Boost, BTW.) The toolset I'm using is MinGW, the latest stable full-package release, with no package updates.
Anyone have an idea what might be wrong? I'm getting tired of looking at my build output in a command window and then hunting for line numbers in my source code. :-)
To reply to myself once more: I found the problem. The default setting in XEmacs for the option "Explicit Msdos Shell File Name" was cmdproxy.exe -- a program that I don't seem to have anywhere on my system. Changing it to refer explicitly to c:\Windows\System32\cmd.exe fixed this problem for me. Thanks for listening. :-)
"Dan Muller"
To reply to myself once more: I found the problem. The default setting in XEmacs for the option "Explicit Msdos Shell File Name" was cmdproxy.exe -- a program that I don't seem to have anywhere on my system. Changing it to refer explicitly to c:\Windows\System32\cmd.exe fixed this problem for me.
Thanks for listening. :-)
Interesting. "cmdproxy.exe" is what's used by GNU emacs on Windows to launch shell commands. -- ----------------------------------------------------------- David Abrahams * Boost Consulting dave@boost-consulting.com * http://www.boost-consulting.com
participants (2)
-
Dan Muller -
David Abrahams