Code::Blocks Forums
User forums => Using Code::Blocks => Topic started by: cacb on November 07, 2015, 09:21:05 pm
-
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?
-
I would guess a 32 bit program (Code::Blocks) has issues running a 64 bit program.
Tim S.
-
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 :P
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.
-
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 .
-
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?
-
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).
-
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.
-
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.
-
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.
-
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.
-
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.
-
Have you checked what ExpandBackticks function in our codebase does?
wxExecute has different modes and each one behaves differently.
-
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.
-
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.
-
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.
-
Good it is working now. If you see problems don't hesitate to report them.
-
Good it is working now. If you see problems don't hesitate to report them.
Thank you. As a quick update, I have been using this feature successfully in 64bit mode for some days now, so it is definitely working.
A sidenote is that I have also managed to define sets of global variables making it possible to switch easily from 32bit building to 64bit building and vice versa, using the MSVC2013 toolchain. This without changing anything at all in the .cbp project files. More details can be provided if anyone is interested.
-
Thank you. As a quick update, I have been using this feature successfully in 64bit mode for some days now, so it is definitely working.
A sidenote is that I have also managed to define sets of global variables making it possible to switch easily from 32bit building to 64bit building and vice versa, using the MSVC2013 toolchain. This without changing anything at all in the .cbp project files. More details can be provided if anyone is interested.
I would like more details on the global variables.
Tim S.
-
Your issue is something that may be worth looking into more thoroughly.
There is no technical reason why a 32-bit process shouldn't be able to run a 64-bit process. Indeed, Process Explorer does just that, every single time you launch it on a 64-bit system. Firefox is a strictly 32-bit application, too, and it does not fail to launch applications to open media.
Which means there are 3 possible reasons:
- You just fucked up ---> can be ruled out rather safely if the exact same backtick that didn't work before works now
- Code::Blocks has a bug, probably uninitialized variable, somewhere in ExpandTicks ---> that'd be a rather serious defect that would need fixing
- wxExecute not only sucks notoriously, but indeed has a bug that triggers randomly in this scenario ---> not ours to fix, but still important, and should be reported upstream
-
I would like more details on the global variables.
Tim S.
I have a PDF to share about this but it is too big to post as attachment (~650 KB) here. I will upload it to my website and link to it this evening. It is a detailed description of my setup.
-
Your issue is something that may be worth looking into more thoroughly.
There is no technical reason why a 32-bit process shouldn't be able to run a 64-bit process. Indeed, Process Explorer does just that, every single time you launch it on a 64-bit system. Firefox is a strictly 32-bit application, too, and it does not fail to launch applications to open media.
Which means there are 3 possible reasons:
- You just fucked up ---> can be ruled out rather safely if the exact same backtick that didn't work before works now
- Code::Blocks has a bug, probably uninitialized variable, somewhere in ExpandTicks ---> that'd be a rather serious defect that would need fixing
- wxExecute not only sucks notoriously, but indeed has a bug that triggers randomly in this scenario ---> not ours to fix, but still important, and should be reported upstream
I can confirm that a 32bit process (Code::Blocks) can run a 64bit process, it works now.... almost all of the time. When I set up initially on a new computer I tend to have startup trouble, but after that it seems to work consistently.
I would not rule out the first bullet, I do that all the time :P , but yes it is the same backtick.
Somehow it feels like something needs to be cached in somewhere before it becomes reliable (just a hunch). Perhaps that is wxExecute misbehaving sometimes.
More later.
-
I have a PDF to share about this but it is too big to post as attachment (~650 KB) here. I will upload it to my website and link to it this evening. It is a detailed description of my setup.
I made a quick placeholder post on my blog for this topic: Code::Blocks with MSVC2013 (http://arnholm.org/codeblocks-with-msvc2013/)
The PDF mentioned is linked from there.