User forums > Using Code::Blocks
Names of compiler executables: Self-built vs Official
AndrewCot:
Some things do not add up.
PB,
What compiler(s) do you have installed and what directory are they installed in? I have all of the compilers in ticket 374 plus Cygwin and MS Visual Studio 2019 CE.
Can I please get a copy of the default.conf and the new/modified compiler and option files you are currently using so I can have a look at them tomorrow and test them as it is too late tonight for me to look at it.
Be aware the options_gcc.xml file looks for the mingw32 files as per the following options_gcc.xml file snippet below, so when creating a new compiler from this can cause issues when the default.conf is deleted as the executable will revert to mingw32 until the compiler settings are changed.
<CodeBlocks_compiler_options>
<if platform="windows">
<Program name="C" value="mingw32-gcc.exe"/>
<Program name="CPP" value="mingw32-g++.exe"/>
<Program name="LD" value="mingw32-g++.exe"/>
<Program name="DBGconfig" value="gdb_debugger:Default"/>
<Program name="LIB" value="ar.exe"/>
<Program name="WINDRES" value="windres.exe"/>
<Program name="MAKE" value="mingw32-make.exe"/>
</if>
<else>
<Program name="C" value="gcc"/>
<Program name="CPP" value="g++"/>
<Program name="LD" value="g++"/>
<Program name="DBGconfig" value="gdb_debugger:Default"/>
<Program name="LIB" value="ar"/>
<Program name="WINDRES" value=""/>
<Program name="MAKE" value="make"/>
</else>
PB:
--- Quote from: oBFusCATed on June 30, 2021, 10:56:51 pm ---Can you start from a clean state and try to reproduce the problem and post the exact steps?
--- End quote ---
* I have Code::Blocks v20.03 and I have also installed the latest nightly (rev12462).
* I have removed folder %APPDATA%\CodeBlocks when Code::Blocks was not running.
* I launched v20.03, it asked about stuff indicating it was a clean run. Among else it told me it could not find any compiler which was not surprising as I do not have any in the PATH or known location.
* When running v20.03 I have set installation directory for "GNU GCC Compiler" to point "C:\Program Files (x86)\mingw-w64\i686-8.1.0-posix-sjlj-rt_v6-rev0\mingw32" and verified the names for the first three tools were correct (i.e., without "mingw32-" prefix).
* When running v20.03 I have built and ran a Hello World C++ application to make sure everything works as expected.
* I did not change any other setting in v20.03.
* I launched the nightly, it immediately showed a pop-up complaining about a compiler executable not found.
* When running the nightly, I went to the compiler settings, looked at settings for "GNU GCC Compiler" and again, the names for the first three tool names were incorrectly prefixed with "mingw32-".
To conclude, even after removing all Code::Blocks settings, I still experience the same issue I described in the first post of this thread. The issue is not with custom compiler configurations, the issue is rooted in the "GNU GCC Compiler", the custom compiler configurations derived from this compiler just inherit it.
PB:
--- Quote from: AndrewCot on July 01, 2021, 04:17:07 pm ---What compiler(s) do you have installed and what directory are they installed in?
--- End quote ---
Please read my previous post where I believe the issue is not with custom compiler configurations in C::B but with the base "GNU GCC Compiler".
I have 6 packages by mingw-64 project installed in their default locations in %ProgramFiles(x86)% and %ProgramFiles%:
i686-8.1.0-posix-sjlj-rt_v6-rev0
i686-8.1.0-win32-sjlj-rt_v6-rev0
i686-8.1.0-posix-dwarf-rt_v6-rev0
x86_64-8.1.0-posix-seh-rt_v6-rev0
x86_64-8.1.0-posix-sjlj-rt_v6-rev0
x86_64-8.1.0-win32-seh-rt_v6-rev0
I also have 2 mingw- and GCC-based MSYS2 packages installed in the default location (c:\msys64):
mingw-w64-i686-toolchain
mingw-w64-x86_64-toolchain
I have GCC v9 based TDM-GCC-32 and TDM-GCC-64 installed in C:\. I also have MSVS 2017 and 2019 which I never used in C::B.
None of the compilers are in the PATH. I did not have C::B compiler configurations for all of them but those few I had I could switch between in v20.03 with no issues.
--- Quote from: AndrewCot on July 01, 2021, 04:17:07 pm ---Be aware the options_gcc.xml file looks for the mingw32 files as per the following options_gcc.xml file snippet below, so when creating a new compiler from this can cause issues when the default.conf is deleted as the executable will revert to mingw32 until the compiler settings are changed.
<CodeBlocks_compiler_options>
<if platform="windows">
<Program name="C" value="mingw32-gcc.exe"/>
<Program name="CPP" value="mingw32-g++.exe"/>
<Program name="LD" value="mingw32-g++.exe"/>
<Program name="DBGconfig" value="gdb_debugger:Default"/>
<Program name="LIB" value="ar.exe"/>
<Program name="WINDRES" value="windres.exe"/>
<Program name="MAKE" value="mingw32-make.exe"/>
</if>
<else>
<Program name="C" value="gcc"/>
<Program name="CPP" value="g++"/>
<Program name="LD" value="g++"/>
<Program name="DBGconfig" value="gdb_debugger:Default"/>
<Program name="LIB" value="ar"/>
<Program name="WINDRES" value=""/>
<Program name="MAKE" value="make"/>
</else>
--- End quote ---
This looks incorrect to me.
In mingw-64 project with GCC 8.1 distributions, the 32-bit installations (e.g., i686-8.1.0-posix-dwarf-rt_v6-rev0) have unprefixed gcc and g++ executables as well as those prefixed with "i686-w64-mingw32-", e.g., i686-w64-mingw32-gcc.exe. The 64-bit ones (e.g., x86_64-8.1.0-posix-seh-rt_v6-rev0) also have both unprefixed and prefixed executables, with prefix being "x86_64-w64-mingw32-", e.g. x86_64-w64-mingw32-gcc.exe.
Interestingly, in MSYS mingw64 packages with GCC the 32-bit one has only unprefixed executables while the 64-bit one has both unprefixed and prefixed with "x86_64-w64-mingw32-".
TDM-GCC: both 32- and 64-bit installations have prefixed and unprefixed executables, the prefix being "mingw32-" for 32-bit and "x86_64-w64-mingw32-" for 64-bit. I think the difference is that TDM uses uses the original MinGW distribution for 32-bit package while the 64-bit one is based on mingw-64 project.
If the default "parent" compiler "GNU GCC Compiler" will have gcc and g++ with a prefix, the solution to my "problem" would be to remove the prefix from custom compiler configurations. This needs to be done just once for each configuration (or perhaps just once in the "GNU GCC Compiler" itself).
So it is a minor issue, it is just surprising if one does not know where the prefix in the custom configuration came from all of a sudden.
stahta01:
--- Quote from: PB on July 01, 2021, 06:56:14 pm ---Interestingly, in MSYS mingw64 packages with GCC the 32-bit one has only unprefixed executables while the 64-bit one has both unprefixed and prefixed with "x86_64-w64-mingw32-".
--- End quote ---
My MSys2 mingw32/bin has "i686-w64-mingw32-" prefix are you sure you looked at the full folder?
Tim S.
PB:
--- Quote from: stahta01 on July 02, 2021, 03:41:46 am ---My MSys2 mingw32/bin has "i686-w64-mingw32-" prefix are you sure you looked at the full folder?
--- End quote ---
Sorry, you are right I somehow managed to miss those files.
Although it seems that people moved away from MinGW to mingw-64, I have also downloaded the original MinGW package (with GCC 9.2). It has the unprefixed gcc and g++ executables and is the only package of all I tried having them also prefixed with "mingw32-".
The question remains: It seems that all relevant mingw distributions have gcc.exe and g++.exe so why use the prefix (be it correct or incorrect) for them?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version