My CB 20.03 on windows has two compilers installed and registered: The default MinGW 8.1 (still set as default compiler) and the new MinGW 14.2 from CodeBlocks 25.03 (selected in the project settings of some projects).
When I compile a C++ project with the new MinGW, the build is successful. But when I click the "Run" button, a Windows popup tells me that starting the program failed due to dll problems.
I tried to analyze the problem:
- The .exe file is linked against the runtime libs of the new MinGW.
- The gcc/stdc++ runtime lib's of both MinGW versions seem to have the same names.
- In the PATH which is implicitely set by CB for the CMD window in which the compiled program is started by "Run", the /bin directory of the old (default) MinGW preceedes the /bin directory of the MinGW used for compiling the program.
- So on program startup Windows seems to load the wrong (old) version of the gcc/stdc++ runtime dll's.
Starting the same .exe in a manually opened CMD windows with a manually set PATH works fine.
I would recommend to either link the GCC libs statically and the problem will permanently disappear or copy the right DLLs from the right MinGW folder into the folder where you have the executable compiles as a post.build step. Prepending the selected compilers bin-folder to the PATH is required as otherwise exactly the opposite would happen.
Keep in min you can setup the folder from where to run your applications, too. Additionally, there is the EnvVars plugin where you can "mess" with the PATH environment variable.
Given these options I consider the ticket as closed. If you believe there is still a issue, please open a new one.
Last edit: Morten MacFly 2 days ago
You describe correctly and exactly what should happen (and what I want to happen, that's why I opened this ticket): "Prepending the selected compilers bin-folder to the PATH is required ...." (i.e. the compiler selected for the project should be first in the PATH, preceeding the default compiler).
But exactly the opposite of what you said is actually happening in CB: The selected compiler's bin-folder is appended (not prepended) to the PATH, i.e. it is after the bin-folder of the default compiler.
Question: Is the PATH constructed for the "Run" button project-independent, or is it constructed individually whenever "Run" is clicked depending on the project settings?
It needs to be set depending on the project being run and the compiler set for this project!
Checked your alternatives. They are not valid alternatives in our environment.
We are not talking about the CB I use (in fact, I do not use CB. I compile on the command line for 45 years now...).
We are talking about the 200 CB's installed in the computer labs of our university for the beginner's programming courses. Most of these students have never used the command line, have never heard of PATH, and don't know what static linking is. They type their program, hit the "Build and Run" button and expect their program to run.
And static linking is prohibitive w.r.t. ressources: Static linking increases the size of the exe of small programs at least by an order of magnitude, and the projects of the students are (and must be) on a windows network drive. We already have bandwidth problems on the lab network and the student's fileserver.
Unfortunately, for some of our exercises we need the old gcc, and some depend on the new gcc.
OK, so what I don't get: You have 2 compilers installed, you need only one. Right? Why don't you uninstall the one that is conflicting? There are also C::B installers w/o the compiler. You could also invalidate its config by changing the master path.
Maybe I still misunderstood your requirements?
Ah, you explained it here. So you really have mixed exercises that require different compilers. Therefore these are in different projects, right? Who creates these projects? The students?
You could provide a customised project template with a post-build project step that always copies the right DLLs to the right BIN folder. Using macros you can do this in a generic fashion that would work for all compilers.
Last edit: Morten MacFly 12 hours ago