Recent Posts

91

Nightly builds / Re: The 24 March 2024 build (13493) is out.

« Last post by eckard_klotz on March 31, 2024, 10:07:11 am »

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

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.

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.

92

Nightly builds / Re: The 24 March 2024 build (13493) is out.

« Last post by nenin on March 31, 2024, 09:17:15 am »

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. 

93

Plugins development / Re: Show diagnostics on clicking error/warning marker

« Last post by christo on March 31, 2024, 06:35:01 am »

Is there any way to convert this patch so that it does not use std::move. My experience with std::move has been one crash after another.

For the time being, until I can figure out why my coding with std::move causes crashes, I do not want to apply any code containing it.

std::move causes crash only if the move constructors are not proper. If the class contains pointers, move constructor should handle the pointers in logically correct way. For eg. if the class has a pointer which is deleted in the destructor if not null, then the move constructor should make the pointer of the moved from object to null.

Secondly. Is this code introducing locks which can halt the main GUI thread?

It shouldn't as the mutex is to protect the map operations, and they are pretty quick.

94

Help / Re: codeblocks randomly crashes when writing

« Last post by stahta01 on March 31, 2024, 01:45:18 am »

Where are the links for the Linux version of the Code::Blocks nightly builds?

I suggest learning/using the name of your distro when asking questions; because you are starting to look like a bot to me also.

https://wxstuff.xaviou.fr/article/debian-repository.html

95

Help / Re: codeblocks randomly crashes when writing

« Last post by cdavalillo on March 30, 2024, 10:22:30 pm »

Where are the links for the Linux version of the Code::Blocks nightly builds?

96

Plugins development / Re: Show diagnostics on clicking error/warning marker

« Last post by Pecan on March 30, 2024, 07:57:21 pm »

Patch with support for "Apply fix" as well.

Is there any way to convert this patch so that it does not use std::move. My experience with std::move has been one crash after another.

For the time being, until I can figure out why my coding with std::move causes crashes, I do not want to apply any code containing it.

Secondly. Is this code introducing locks which can halt the main GUI thread?

97

Nightly builds / Re: The 24 March 2024 build (13493) is out.

« Last post by stahta01 on March 30, 2024, 04:01:40 pm »

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.

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.

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.

98

Nightly builds / Re: The 24 March 2024 build (13493) is out.

« Last post by vatsaladitya on March 30, 2024, 03:54:01 pm »

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.

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.

99

Nightly builds / Re: The 24 March 2024 build (13493) is out.

« Last post by eckard_klotz on March 30, 2024, 03:19:59 pm »

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.

100

General (but related to Code::Blocks) / Re: My experience after more than 10 years of using CB

« Last post by rechtsanwaltsteyer on March 30, 2024, 12:29:18 pm »

I've been using Code::Blocks for a long time. It has its quirks. If these bother me (keywords autosafe, bad autocomplete and no F1 help that branches to the keyword in CPP reference, Windows orientated, no Linux nightlies, etc.), I just use KDevelop (with some, but others Quirks) or the Qt Creator (with the fewest quirks). In other words, I would never rely on a single development environment alone. Because: What if CB is not developed further (e.g. so as not to have problems with Wayland). If KDevelop falls asleep or the Qt creator has to be paid. Maybe I'm only able to do this because I don't develop huge projects. If you use more than one IDE regularly, or even maintain your projects in the mentioned IDEs in parallel, you are on the safe side. If one IDE fails, you still have the others.
Regards