Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Help with debugging codeblocks build from sources

<< < (2/2)

AndrewCot:
Thanks gd_on. Looks like you have come across the problems I am encounting and the post will help a HUGE amount as the links make sense and appear to be related to the issues I have come accross. I created the post below before your post and was updating it based on the -Ox changes and then hit the post button and the web site coded poped up info that there was another post.

I am going to call it a night (Sydney OZ) and will pickup in the morning.

I will apply the patch and read the MSYS2 thread in the morning. Have you posted anything on the MSYS2 github issues list or a GNU bug list? Is there anything I can do to help out after applying the patch and reading the thread?


Original post below before sd_on response was seen:

I have been debugging the code and the problem is in code that has not changed in 8+ years, so I have discounted a bug in CB.

My debugging has traced the issue to src\plugins\compilergcc\depslib\src\fileent.c file on line 107:

--- Code: ---sprintf( filespec, "%s/*", dir );
--- End code ---

When I step to this line the dir variable becomes out of scope and therefor the filespec is "undefined" as in whet ever the underlying memory is......

The failing code above was built with "-g -O2" using gcc.exe (Rev2, Built by MSYS2 project) 10.3.0.
If I build with "-g -Og" then line 107 works, but there is still an exception thrown.
If I build with "-g -O0" then I get the following error when GDB tries to run the exe:
The procedure entry point _ZNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEC1Ev could not be located in the dynamic link library F:\Andrew_Development\codeblocks_sf\src\devel31_64\codeblocks.dll.

AndrewCot:
I am now able to build codeblocks from source and it runs correctly now with the fileent.c changed and using "-g -Og" compile options.

AndrewCot:
Any updates / eta when the  fileent.c changes will be completed (ticket #1086: https://sourceforge.net/p/codeblocks/tickets/1086/).

BTW my 2c on the change is that in the \src\plugins\compilergcc\depslib\src\hash.c  file there is a __LP64__ macro used that may be a better fit if the first patch is going to be used in addition to the _WIN64 as __LP64__ is applicable for GCC and looks like it is supported on Windows (Cygwin & MSYS2) and Linux and MacOS. I personally do not have a preference for which patch is applied, but it probably needs to be done sooner so devs like I have do not fall into the hole like I did going forward.

Navigation

[0] Message Index

[*] Previous page