64bit programs in backtics?

[cacb]

Hi,

I have been using the MSVC compilers with Code::Blocks on Windows for quite some time. Recently I began upgrading to Visual Studio 2013 compilers. This now seems to work, I am able to build both x86 (32bit) and x64 (64bit) program under Code::Blocks with the MSVC compilers. For x64 I am currently using the x86_amd64 cross compiler toolset in Visual Studio 2013 Express.

My project setups use the "backtick" feature, for example under under Project Options -> Compiler settings -> Other compiler options, I have things like this (notice the backticks):

`$(CPDE_USR)\bin\wx-config.exe --prefix=$(#wx) --wxcfg=$(#wx.release) --cxxflags`

wx-config.exe is a program compiled by me. When it is compiled using the x86 toolset everything works as expected, but when compiled using the x86_amd64 toolset it does not appear to run in the backtic context, i.e. no output at all. When tested on the command line there is no problem.

I am running the pre-compiled Nightly Build svn 10503 undet Windows 7 http://forums.codeblocks.org/index.php/topic,20676.0.html

Is there anything to prevent 64 bit programs to run in backtics?

[stahta01]

I would guess a 32 bit program (Code::Blocks) has issues running a 64 bit program.

Tim S.

[cacb]

I would guess a 32 bit program (Code::Blocks) has issues running a 64 bit program.

Tim S.

That was my initial guess too. I guess your guess is a confirmation 

If so, how exactly are programs called in the backtick context? Is it for example any different from how the compilers/linkers are called? I mean, is it likely to be a problem to use (from Code::Blocks) the native amd64 toolset found in MSVC 2013 Professional? It was my plan to do so on another machine.

If we can't run 64bit tools (including native 64bit compilers) from within Code::Blocks (32bit), is there a 64bit build of the Windows nightlies somewhere? If not, perhaps it could be an idea for an upcoming release.

[Jenna]

The function is in sdk/globals.cpp:837 .
It calls wxExecute and caches the output, on windows it's run through "cmd /c " on other platforms it runs directly.
So this is most likely an issue with wxExecute .

[oBFusCATed]

Is there any error printed somewhere? Does you program depend on some dll? If it does could it be that when run from inside cb it is not found?

[cacb]

The function is in sdk/globals.cpp:837 .
It calls wxExecute and caches the output, on windows it's run through "cmd /c " on other platforms it runs directly.
So this is most likely an issue with wxExecute .

Ok, I think I will try to confirm that by building a small console application and try to execute the program I am having issues with, using wxExecute. I can then try all combinations of x86 and x64 for both programs. This should make it clear if it is a wxExecute problem.

Is there any error printed somewhere? Does you program depend on some dll? If it does could it be that when run from inside cb it is not found?

I didn't see any messages, not sure where to look. I just didn't get any output at all via the backticks.  The program is simply a slight modification of https://sites.google.com/site/wxconfig/ and it does not refer to any dlls other than the runtime/system dll's (perhaps that is the problem).

[MortenMacFly]

Short question: Aren't the compiler (...) tools of the MinGW64 toolchain all pure, native 64 bit tools? This works pretty well. Especially if it is wrapped in a cmd.exe context I see no reason why this should not work.

[stahta01]

To cacb:
Did you try saving the project with the back ticks; then closing the project.
Then, reopen the project.

I have never been able to edit back ticks in a windows project and have them work more than 50 % of the time.
No idea what I do that makes the changes randomly fail.

Tim S.

[cacb]

To cacb:
Did you try saving the project with the back ticks; then closing the project.
Then, reopen the project.

I have never been able to edit back ticks in a windows project and have them work more than 50 % of the time.
No idea what I do that makes the changes randomly fail.

Tim S.

I have used backticks on Windows for several years without any problems (building for x86 so far).  I have many projects and open/close them all the time, every day.

Btw. My projects contain 4 build targets, build/release for the current MSVC compiler and the same for g++. Notice I don't use g++ under Windows, only Linux. I.e. I don't use MinGW anywhere. All my build targets use backticks, both on Windows and Linux.

[cacb]

Ok, I think I will try to confirm that by building a small console application and try to execute the program I am having issues with, using wxExecute. I can then try all combinations of x86 and x64 for both programs. This should make it clear if it is a wxExecute problem.

I did write that test program "Test-wx-config" calling the client program "wx-config" using wxExecute and compiled both as x64 and x86, then ran all 4 combinations:

                      wx-config(x86)   wx-config(x64)
Test-wx-config(x86)      OK              OK
Test-wx-config(x64)      OK              OK

Apparently, all 4 combinations worked fine.

[cacb]

Short question: Aren't the compiler (...) tools of the MinGW64 toolchain all pure, native 64 bit tools? This works pretty well. Especially if it is wrapped in a cmd.exe context I see no reason why this should not work.

I don't use MinGW in any form, but a quick search shows the existence of Windows mingw-w64 cross compiler  (i.e. x86 tools)
http://sourceforge.net/p/mingw-w64/wiki2/Cross%20Win32%20and%20Win64%20compiler/

I think it depends on exactly what you are using.

[oBFusCATed]

Have you checked what ExpandBackticks function in our codebase does?
wxExecute has different modes and each one behaves differently.

[cacb]

Have you checked what ExpandBackticks function in our codebase does?
wxExecute has different modes and each one behaves differently.

I just checked.

My fist test was like the line in sdk/globals.cpp:870
         wxExecute(cmd,  output, wxEXEC_NODISABLE);

Now I tried
        wxExecute(_T("cmd /c ") + cmd, output, wxEXEC_NODISABLE);

No difference observed.

[oBFusCATed]

Then you'll have to either debug codeblocks or modify it to log something to see what commands are executed and what is their output.

[cacb]

After reporting the problems, doing the tests and finding it should have worked, I went back and tried the original compile. To my surprise now it worked also when running 64bit in backtick! So it looks like I worked from the wrong assumption. Sorry about that.

I am now wondering whether I saw what Tim S. was talking about, intermittent behaviour when running in backticks. Maybe it was for example somehow taking too long to load the program, and something timed out, but once the OS cached it it worked. Just a guess.

Anyhow, explaining the problem seems to have fixed it :-) Sorry for the trouble. But now we know at least that it is possible to "wxExecute" a 64bit program from a 32 bit host program.