News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

The 01 September 2023 build (13344) is out.

Started by killerbot, September 01, 2023, 08:57:11 PM

Previous topic - Next topic

stahta01

Quote from: Miguel Gimenez on September 10, 2023, 02:07:43 PM
Thank you for reporting and the exhaustive information.

Commits in the range 13159-13166 are not related to global variables, are you sure 13159 works and 13166 does not?

Based on the images; I am guessing the compiler auto detection is the problem area; instead of the global variable area.

Tim S.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

AndyJ

Not specifically related to this nightly but I've recent moved from Windows 7 to 10 and now find that when remote debugging using either the J-Link or MCULink tools I can't stop a debug session reliably. Most of the time I get the message:

Trying to interrupt the process by sending CTRL-C event to the console!
Interrupting debugger failed :(

Using the same tools on Windows 7 things work as expected. I've tried several Win10 machines but they all seem to behave the same but Win7 machines seem fine. This has been going on for the last few nightlys and I've tried re-installing and updating the debugger/GDBservers.

Any thoughts?


Miguel Gimenez

Ticket 1353 refers to this issue.

I will update the ticket with your W7 vs W10 comment.

AndyJ

Thank you for the information. Has this really been broken since 2019?

I tried to download the nearest nightly that I could find before 11858 for some testing which was 11825 but unfortunately the wxWidgets files seem to be missing.

Is it possible to revert 11858 from nightly builds until a proper fix is found?

Thanks for the help!

Miguel Gimenez

QuoteIs it possible to revert 11858 from nightly builds until a proper fix is found?
I do not know, and the debugger plugin maintainer is no longer around. Look at the plugin history after that commit or just revert it.

eckard_klotz

Hello Miguel Gimenez and Tim.S.

Please accept my apologize for my late reply.

QuoteCommits in the range 13159-13166 are not related to global variables, are you sure 13159 works and 13166 does not?

I have tested it today again.

  • I can confirm, it is working with the nightly from the 22.01.2023 (13159) and it is not working with the nightly from the 29.01.2023 (13166) .
  • Please refer the 2 screen shots in the attached zip-file:

    • CB_13159_compiler_toolchain_executables.png
    • CB_13166_compiler_toolchain_executables.png

Actually I download every nightly. But for some reasons I don't change always to the newest one.

  • The attached zip-file provides a screen shot from my nightly root-directory:

    • NightlyFolderRoot.png
  • The highlighted folders were tested by me to figure out when the issue occurred.

QuoteBased on the images; I am guessing the compiler auto detection is the problem area; instead of the global variable area.

This sounds plausible since the auto-detection warning-dialogue occurs always while starting Code::Blocks when the issue is present.

  • However this was the case last year also.
  • The attached zip-file provides a screen shot from my MinGW root-directory

    • MinGWFolderRoot.png

  • As you can see, I don't use the traditional root-directory for the build-suite.

    • But I use an own root-directory parallel to other development tools.
    • Furthermore, I provided more than one version and flavour.
    • Thus, the auto-detection would always fail in my case.
  • I use different personalities (defined in different conf-files) to choose the version and flavour to work with while starting Code::Blocks.

    • Thus, I would expect that Code::Blocks is checking the paths configured in the global variables to use the build-tools configured there.
    • If the tool-chain configuration is referring to global variables than Code::Blocks may check if they are validly configured.
    • But if one of the global variable is not validly defined, than it is the responsibility of the user to correct its definition.
    • However, Code::Blocks replaces the global variable by standard tool-names, what should not be done from my understanding.

      • In my case the global variables are referring to valid build-suite locations.
      • This means a valid configuration will be replaced by an invalid one.

Nevertheless, please have a nice weekend.

Best regards,
                    Eckard Klotz.

Miguel Gimenez


Miguel Gimenez