#1534 Running compiled program fails because of wrong PATH

[Klaus Kusche]

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.

[Morten MacFly]

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.

[Klaus Kusche]

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.

[Klaus Kusche]

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!

[Klaus Kusche]

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.

[Morten MacFly]

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?

[Morten MacFly]

Unfortunately, for some of our exercises we need the old gcc, and some depend on the new gcc.

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.

[Klaus Kusche]

In the descriptions of the exercises, there is also a description on how to set up the project for each exercise. So the students are expected to be able to set up their projects by themselves in CB's build options: They should learn what compiler and linker options are, how header and lib dir's work and so on for projects with additional libs. Approximately one third of the students manages to set up their projects correctly by themselves, and the other two thirds mess it up and need my help...

Copying the dll's to the project's bin dir is not really appreciated for the same reason why we don't like static linking: The project folders of the students (including the bin dir) are on a network share, on a quite loaded network and server. Individually copying all the dll's to the network share of each student and loading them from there is not a good idea.

But I still wonder why in PATH, the lib dir of the compiler selected for the project follows the lib dir of CB's default compiler instead of preceeding it. This sounds like a bug to me...

However, there might be other options to solve the problem: All those third-party lib's are open source. I could try to provide versions of these libs to the students which have all been locally compiled with the same compiler. Then we would only need one compiler in CB. This would e.g. be needed for wxWidgets: For wxw 3.3.x, they only provide windows prebuilt libs for gcc 15, but not for the default gcc of CB 20 nor CB 25, and for wxw 3.2.x, they provide prebuilts for the old MinGW gcc 8.1, but their windows prebuilt for Msys gcc 14 is linking-incompatible with the MinGW gcc 14 coming with CB 25.

[Morten MacFly]

I've added a convenience function for that purpose in [r13731]. With the next nightly, this issue should be solved.

[ollydbg]

Hi, Morten, I report an issue about this change here:

The library search path is not included in the PATH in the compilergcc plugin