Recent Posts

1

Help / Re: Running debugger runs the output file, not the debugger (AGC)

« Last post by NeilFraser on Today at 01:03:19 am »

Have you run debugger from Debug->Start? You seem to directly run the executable!

Well.  I guess that's what I get for trying to solve this problem at 3 am...   

Thanks!

2

Using Code::Blocks / Auto activating projects in workspace

« Last post by Hakar on Yesterday at 08:38:39 pm »

Hello, sorry if this question has been asked before
is there a way that Codeblocks auto activates the project I'm working in?
when I edit a code and compile it, I have to go to this menu and manually activate it before compiling it.

3

General (but related to Code::Blocks) / Re: g++.exe what -std=c++ <what version>

« Last post by Miguel Gimenez on Yesterday at 06:37:10 pm »

You can print the __cplusplus macro, see this link for more information.

4

General (but related to Code::Blocks) / Re: g++.exe what -std=c++ <what version>

« Last post by stahta01 on Yesterday at 06:04:03 pm »

What ever is the default for the Compiler version installed!

Learn about the compiler you installed and the use a web search tool to find the default standard for C and C++.

Tim S.

5

General (but related to Code::Blocks) / g++.exe what -std=c++ <what version>

« Last post by jmClifford on Yesterday at 05:08:13 pm »

Hi. I understand that I have installed a compiler package in a folder MinGW.
If I do not specify in CB what to use, then how can I determine what has been used
(wrt C++ standard) ??

A sample of the built log follows;

-------------- Clean: Debug in ThreadNames (compiler: GNU GCC Compiler)---------------

Cleaned "ThreadNames - Debug"

-------------- Build: Debug in ThreadNames (compiler: GNU GCC Compiler)---------------

g++.exe -Wall -fexceptions -g -IC:\WxWidgetsSetup\include -IC:\WxWidgetsSetup\lib\gcc_dll -c C:\u\CodeBlock_C++\EasyLoggingpp_ThreadNames\ThreadNames\easylogging++.cc -o obj\Debug\easylogging++.o
g++.exe -Wall -fexceptions -g -IC:\WxWidgetsSetup\include -IC:\WxWidgetsSetup\lib\gcc_dll -c C:\u\CodeBlock_C++\EasyLoggingpp_ThreadNames\ThreadNames\main.cpp -o obj\Debug\main.o
g++.exe  -o bin\Debug\ThreadNames.exe obj\Debug\easylogging++.o obj\Debug\main.o   C:\WxWidgetsSetup\lib\gcc_dll\libwxmsw32ud.a C:\WxWidgetsSetup\lib\gcc_dll\libwxmsw32u.a
C:\u\CodeBlock_C++\EasyLoggingpp_ThreadNames\ThreadNames\easylogging++.cc: In member function 'el::Logger* el::base::RegisteredLoggers::get(const std::string&, bool)':

 

Regards JC.....

6

Help / Re: Running debugger runs the output file, not the debugger (AGC)

« Last post by Grit Clef on Yesterday at 01:03:43 pm »

Have you run debugger from Debug->Start? You seem to directly run the executable!

7

Help / Running debugger runs the output file, not the debugger (AGC)

« Last post by NeilFraser on Yesterday at 03:32:36 am »

Hello, I'm trying to use Code::Blocks to debug code for the Apollo Guidance Computer.  Compiling works great, it generates a valid binary output file.  But when I try to run the debugger, Code::Blocks forgets to include the specified debugger executable.

The build log states:

Code

-------- Run: Debug in Comanche051 (compiler: AGC YaYUL assembler)----------
Checking for existence: /home/pi/virtualagc/Comanche051/Comanche051.bin
Executing: /home/pi/virtualagc/Comanche051/Comanche051.bin (in /home/pi/virtualagc/Comanche051/.)
Process terminated with status -1 (0 minute(s), 0 second(s))

I believe the problem is that it's forgetting about the debugger; it should be executing:

Code

/home/pi/VirtualAGC/bin/yaAGC /home/pi/virtualagc/Comanche051/Comanche051.bin

Under "Settings", "Debugger...", "AGC" (my GDB/CDB debugger profile), the executable path is set to /home/pi/VirtualAGC/bin/yaAGC, but this info doesn't seem to be making it to the command being executed.

Under "Settings", "Compiler...", "Global compiler settings", "Toolchain executables", the debugger is set to "GDB/CDB debugger: AGC".

Any idea what I should be doing differently?  Thanks!

8

Using Code::Blocks / Re: new project wizard fails to locate glfw3.h

« Last post by Vigor on April 21, 2024, 11:45:32 pm »

So, I loaded up the default 20.03 version of codeblocks, intending to copy its wizard and paste it into notepad but the wizard it showed was the same as the nightly build wizard
except there were a few more options when I right clicked to edit it.   

Among the options were...
-a warning that the script had been edited and was stored globally in my local user directory (or something like that i can't see it any more)
-an option to delete the modified script

I deleted it and then was able to start a new glfw project which worked/built/linked properly.  I can then modify that project to work with glfw3.

So, I suppose my problem is solved.  I have found a workaround that allows me to make new projects that link and build correctly.

But, the strange thing is, when I then load up the nightly version of codeblocks it won't allow me to create new projects that build/link even with the old script.   It will make a new project and it will be a glfw project, that project just won't build/link.   However,

I meddled with project build options and by changing the working directory or adding working directories I could make some of the error messages go away.   But as soon as one error went away a new error showed up.  I was not able to find a directory or combination of directories which made everything work.

Also, I'm not sure why but I tried to change the compiler.  It appears i have 3 compilers so I tried them all.   GCC Default and GCC MinGW compiler produced the same errors i think.   GCC MinGW64 compiler produced only one "error" - cannot find -lglfw3: No such file or directory.   I don't even know what lglfw3 is.  It doesn't even show an extension and AFAIK there shouldn't be an lglfw3 anything.

Final thoughts...
-i think i liked the 20.03 problems more than the nightly problems
-when I had the original problem of not being able to find glfw3.h, i felt like I needed to lie to the wizard when it asked what the path to glfw3.h is.   Specifically the path to the glfw3.h was c:/program files/codeblocks/mingw/include/glfw3/glfw3.h but in order to give the wizard what it wanted rather than what it asked for I had to put the path as c:/program files/codeblocks/mingw/ and guess at where the file actually needed to be.  Changing the path I supplied to the wizard to the actual path would make everything else fail to work.
-I think spreading files around to a bunch of different directories is asking for trouble.  If for whatever reason it seems important to quarantine glfw3 files, why not quarantine them all in the same place.   But is there a reason to quarantine them?   Why not put all .h's in an include folder, all .a's in a lib folder etc.    Or why have a bin folder with the executable rather than putting the executable right next to the project file so there would be no need for a working directory?  The more directories there are the more potential there is for problems imho opinion.   I don't contend to be on the same level of programming ability as the devs of codeblocks but I try to keep things simple.   I can only wrap my head around so much complexity.

9

Help / Re: Abbreviation plugin (auto completion) CTRL+J does not work under comments

« Last post by ollydbg on April 21, 2024, 02:12:13 pm »

Maybe, some day, we need to publish some video tutorial about how to use those plugins.

Any way, it looks like currently, Abbreviation plugins works inside the C++ comments now, so I'm not sure why it did not work yesterday.

10

General (but related to Code::Blocks) / Re: problem with silent install in version codeblocks-20.03mingw-setup

« Last post by stahta01 on April 21, 2024, 02:46:44 am »

check if mingw directory exist inside your CB install dir. if so, then
1) go to menu Settings->Compiler
2) In settings window move to toolchain executables tab
3)  Remove 'mingw32-' prefix for upper 4 apps
4) Check mingw path
5) enjoy

Are you working to get banned?
Because your reply makes you look like a bot!

Tim S.