Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
Nightly builds / Re: The 25 September 2024 build (13571) is out.
« Last post by stahta01 on Yesterday at 11:05:31 pm »
What std is being used to build CB and wxWidgets?
CXXFLAGS+="-std=c++11" or 14 or 17 or 20?

I'd like to set my wx build to the level being used for the nightlies.


C++11 is the correct value, C++14 worked for wxSmith plugin and C++17 failed my recent patch set it to C++11 under MSys2 MinGW.
Note: The [Windows] nightly does use C++11 with GNU extension for some CB Plugins I forgot if the CB Core App uses extension or not.
Edit: Before my patch listed above the bug in configure/make code resulted in GCC 14 trying to use the default of C++17 instead of C++11 as CB was set to use before GCC 14 or maybe 13 default value was for GCC. The m4 script update returned to C++11 for GCC 14 configure./make builds.

Tim S.
2
Nightly builds / Re: The 25 September 2024 build (13571) is out.
« Last post by Pecan on Yesterday at 07:25:29 pm »
What std is being used to build CB and wxWidgets?
CXXFLAGS+="-std=c++11" or 14 or 17 or 20?

I'd like to set my wx build to the level being used for the nightlies.
3
Works fine in CentOS Stream 9.

Thanks a lot!
4
General (but related to Code::Blocks) / How to build nightlies for openSUSE?
« Last post by nji on Yesterday at 03:48:19 pm »
I've been using release version of CB @ Win since years.
Recently I switched to openSUSE Leap - still not having much experience there.
The main IDEs there seem to be KDevelop, Qt-Creator and Eclipse.
But they all don't fit to my needs; I would like to stay at CB.

My questions:
Are CB's nightlies "fitting" into openSUSE's environment?
Are the yet stable enough to do at openSUSE?
What about wxWidgets (in openSUSE's environment)?
What about the built-chain (openSUSE: gcc, but CB seems to use clang recently)?
Has anyone experience with building CB at openSUSE recently
and provide a recipee?
(Up to now there are only "comunity pakets" for outdated CB 20.03)
https://software.opensuse.org/package/codeblocks
6
Help / Re: Problems including c files into a codeblocks project
« Last post by Miguel Gimenez on October 02, 2024, 01:42:31 pm »
General programming is OT here.
7
Help / Problems including c files into a codeblocks project
« Last post by Austromancy on October 02, 2024, 01:21:18 pm »
Hi! how are you doing. I know this may not be entirely C related but i'm having trouble with a bmp editor project while using codeblocks.

Context: This is a group project i made alongside 2 friends, all the functions work and its ready to be submited as a codeblocks project, but the delivery format specifies that we can only submit the following files (the names to the right correspond to the name of our files):

-group_functions.h / (in our project) funciones_grupo.h

-group_functions.c / funciones_grupo.c

-member1_functions.h / funciones_perez.h

-member1_functions.c / funciones_perez.c

-member2_functions.h / funciones_larriba.h

-member2_functions.c / funciones_larriba.c

-member3_functions.h / funciones_rios.h

-member3_functions.c / funciones_rios.c

in wich functions.h has to include the two files of each member.

While trying to test our project to see if it works, we created a new codeblocks project and included all these files into it.

All good at this point, but here is the problem: to mantain a same logic throughout the project, we made some "generic" structures. For example, one of these structures is called t_pixel, wich stores 3 unsigned int variables. Of course, a great number of our functions rely on these structures to work.

At first we decided to copy these structures into each and every one of our member.h files, but when we compiled we received a "conflicting types for..." error, so we decided to move all these structures to funciones_rios.h and include this file into the other member.h file. But now we receive a "unknown type name t_pixel" for example. What should we do so that funciones_perez and funciones_larriba can use the generic structures without causing a conflicting type error.

Here is a link to a drive folder that contains these files for a better picture of my problem.

https://drive.google.com/file/d/1H9FSaXQpHM8GxUQSUimAHrJwU0v6khgC/view?usp=sharing

Any kind of help would be greatly apreciated. Apologies for my english, it is not my first language.

Cheers!
8
My opinion is that lines 577 to 582 have been optimized out, but the log data in pastebin is not available:
Quote
Error, this is a private paste or is pending moderation

You can add it here as a zip file.
9
Development / Re: build bot in the github, I see one nice project
« Last post by ollydbg on October 02, 2024, 02:37:00 am »

Edit2: I am now going to look at scripted wizard changes for MSys2 MinGW GCC changes; those are not important enough that moving to SVN is needed and can just be copied to folder till they get approved by people who are using them.

Tim S.

I have 2 patches in my fork, one for wx, the other is for opencv.

Most of the libraries can be used by the pkg-config command in compiler or linker opinion.

I added your changes to my repo I will ignore those for now.

Tim S.

Fill free to modify my two patches about wx and opencv demo, I don't think they are very good, I think it is my hack to the wizard script code.
10
Hello ollydbg,

In dealing with the debugger, I learned something new.
Thanks!

I put the full debug log at https://pastebin.com/7S6jSzZR with superfluous information removed.

I have attached an image of this post showing a breakpoint at line 577 and the debugger stopping at line 583.

A relavant line from the debugger line is:
Code
[debug]> break "/SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:577"
[debug]Breakpoint 2 at 0xd9a4: file /SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp, line 583.
I do not know why Breakpoint 2 is created at line 583.

The breakpoint is skipped when I perform the process manually
Code
/usr/bin/gdb -nx -fullname -quiet  -args /SG3Data/CodeTemp/ins_LPOCode/LPO/Bin/Debian_x64_Debug_Static_GNU/lpo_d
Reading symbols from /SG3Data/CodeTemp/ins_LPOCode/LPO/Bin/Debian_x64_Debug_Static_GNU/lpo_d...
(gdb) set confirm off
(gdb) set args scan blerg probe -JDN 2459034.79167 -Lat 37.3688 Long=-122.0363 -Unk0 Val0 -Fucked= -f= Switch1 Switch2    Switch3  -dead=beef -Switch4 -Switch5
(gdb) break "/SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:577"
Breakpoint 1 at 0xd9a4: file /SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp, line 583.
(gdb) run
Starting program: /SG3Data/CodeTemp/ins_LPOCode/LPO/Bin/Debian_x64_Debug_Static_GNU/lpo_d scan blerg probe -JDN 2459034.79167 -Lat 37.3688 Long=-122.0363 -Unk0 Val0 -Fucked= -f= Switch1 Switch2    Switch3  -dead=beef -Switch4 -Switch5
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

... program output ...

[Thread 0x7ffff7a1e6c0 (LWP 158065) exited]

Thread 1 "lpo_d" hit Breakpoint 1, LPOProgram::DoCommandScan ( ... )
    at /SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:583
��/SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:583:14685:beg:0x5555555619a4
(gdb) q

I expected the debugger to break at line 577.

I am able to replicate the behavior throughout the program being debugged.
I see the behavior with assignment and flow control statements.


=thoth=
Pages: [1] 2 3 4 5 6 ... 10