User forums > Nightly builds

The 24 March 2024 build (13493) is out.

<< < (2/3) > >>

eckard_klotz:
Hello Miguel Gimenez.

Actually I just wanted to support the discussion started by Nenin and Penny Mathenjwa with some details I have observed after changing to this nightly in the hope that they will confirm that this is what they have observed.

However this is nothing I would report as an issue by myself, since it happens not often enough. As long as Nenin and Penny Mathenjwa will not continue their discussion with adding more details about what they have actually faced, I will not bother you with this any more.

Best regards,
                    Eckard.

vatsaladitya:

--- Quote from: eckard_klotz on March 30, 2024, 10:18:05 am ---
I face temporarily a similar issue while building a single file. However by investigating the error-Output of Code::Blocks I came to the same conclusion as Miguel Gimenez:

* The initial root cause is crash of the compiler.
* MinGW 13.2.0 UCRT 64 published by MSYS2.
* running on Windows 10.

--- End quote ---

This may really be the problem with the compiler itself. I am using MinGW w64 MSVCRT (GCC 13.2.0) build from winlibs.com and there seems to be no issue compiling single files.

stahta01:

--- Quote from: vatsaladitya on March 30, 2024, 03:54:01 pm ---
--- Quote from: eckard_klotz on March 30, 2024, 10:18:05 am ---
I face temporarily a similar issue while building a single file. However by investigating the error-Output of Code::Blocks I came to the same conclusion as Miguel Gimenez:

* The initial root cause is crash of the compiler.
* MinGW 13.2.0 UCRT 64 published by MSYS2.
* running on Windows 10.

--- End quote ---

This may really be the problem with the compiler itself. I am using MinGW w64 MSVCRT (GCC 13.2.0) build from winlibs.com and there seems to be no issue compiling single files.

--- End quote ---

It might be a UCRT bug; I get weird issues from time to time using UCRT, so, I tend to see if the problem happens under MSYS2 MINGW64 which uses MSVCRT.

Tim S.

nenin:
To make things more complicated: I found that issue appeared with "static lib" project, not "exe". I`m not sure it is related to compiler. 

eckard_klotz:
Hello Nenin.

Since you don't provide screenshots or tool-outputs but assumptions only, it is not really possible to give you a hint.

Forced by your initial report in this forum-topic I have tried it out in my project and provided the Code::Blocks output.

* The output already provides the information needed to decide that the compiler has a problem and not Code::Blocks.
* Thus it sounds plausible for me to search for a resolution for the build-suite and not for Code::Blocks
Currently we know from your issue:

* You work with Windows 10.
* You try to build a single source file.
* You assume that Code::Blocks tries to run a staic library.
* Did I forget something???
Until we don't know:

* What is your build suite (compiler tool-chain) ?
* What is the Code::Blocks build-output ?
Your assumption that Code::Blocks tries to run your static library sounds not plausible, since a static library contains no executable ready to run but a collection of functions only. In the case you use a GNU compiler the static library is actually only an archive (similar to a zip-file) that contains the object-files of your compiled sources but no linker-result. This files are not ready to run anyway.

How do you come to your statement

--- Quote ---when I tried to compile single file, does not matter through menu, tree or hot key, C::B tries to run library instead of compile it.
--- End quote ---
Code::Blocks usually outputs the command-line of every binary called while building in the build log. Why don't you post it, as I have done? This would give us the chance to figure out what really happened instead of wondering about your assumptions.

Best regards,
                   Eckard.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version