User forums > Using Code::Blocks

Problem with svn 12294

<< < (3/4) > >>

Avan:

--- Quote from: sodev on February 26, 2021, 03:24:13 pm ---Wasn't there a bug in wxWidgets regarding rounding of font sizes resulting in one of such assertions to trigger? His version might be affected by that bug.

--- End quote ---

That's correct. I just took the line out in 2019 counting on the team to eventually getting to it during the transformation.

Avan:

--- Quote from: Miguel Gimenez on February 26, 2021, 01:27:29 pm ---That dll is there only if you installed the telemetry (read as spying) update, KB2952664. Looks like dbghelp.dll now sends your work to M$

--- End quote ---

Stuff like this gets blocked by my firewall and other agents. But thanks for pointing to the culprit. I'll uninstall it.

Edit: I'm not using any CompatTel dll's as I have a combination wx:CB that compiles. But that doesn't make it right, does it? Why can I just use the latest versions of both?

Edit2: A day or so later Winupdate installed KB2952664 again. Who said Win7 was dead?  :o

gd_on:
I have made a few tries and found a few workarounds to my svn 12294 problem (Am I alone ?).
For svn 12295, no changes ... normal.
If I use my previous working 12292 working version (the one built incrementally), it works as said before.
If I only replace codeblocks.exe in my svn 12295 build, the one found in my working svn 12292, it works too. Certainly not a good idea to mix versions, but it was just to try.
I also tried an other compiler found on winlibs.
I first tried the latest version (release 7) to build C::B 12295, but had the same trouble when launching a new compilation of every soft (my own, but not only). Not so surprising because they probably share the same sources versions if I look at the dates.
Then I tried a previous compiler set version (release 4), also found on Winlibs, generated in 2020/08, to build C::B 12295. Here, the resulting C::B works as expected.
So, I suppose that in C::B, and more precisely in the executable codeblocks.exe, there is something which is not correctly compiled with those recent compiler versions (Msys2 and/or latest winlibs), maybe somewhere when preparing the call to the compiler. Bug in C::B or in the compiler itself, I don't know.

gd_on:
Some other tries ...
The problem I meet, seems to be related with new versions in binutils (ar.exe but not only).
If I revert to binutils 2.35, compilation in C::B works again.
Same problems with Msys2 or Winlibs versions of binutils set.
In Winlibs versions, the last release which works for me is release 5 (the last one with binutils 2.35).

gd_on:
Some more informations.
I compiled C::B with cb_release_type = -g. It's now SVN 12302, but this doesn't change anything here. I have used the last updated Msys2 tools (using pacman -Syu). As told previously, it includes binutils 2.36, which may be the source of the problem. To be usable, it is necessary to delete libdep.a (in the subfolder mingw64\lib\bfd-plugins) because there is a problem in ar.exe which does not recognize this file as a valid Windows library ! Many posts on the web with that, but until now no corrections !!
I launch C::B, load a .cbp file (for example containing a simple hello program). When I click on the Build icon (or menu), C::B crash. It gives an RPT file which is more complete than the one I gave previously. May be for a specialist ....
I also tried to launch C::B under the gdb control, and tried the same operations, but the result displayed looked less interesting.
If I use a Mingw 64 version containing a previous binutils set (2.35), as for example the one found on winlibs site, release 4 or 5, all is OK. Note that starting with release 6 on Winlibs, containing a binutils 2.36, there is a libdep.dll, which does not produce problem in ar.exe, but make C::B crash also.

Navigation

[0] Message Index

[#] Next page

[*] Previous page