Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
Thanks for helping. I also have the same problems.
2
If you want to share/backup projects it is better to use something like git/svn/hg/etc.
3
Using Code::Blocks / [Solved]Re: Problem with svn 12446
« Last post by gd_on on Today at 10:45:30 am »
Cool. Nice work.
Many thanks  ;)
4
Help / Re: Project - compiler changes do not cause debugger to change
« Last post by AndrewCot on Today at 08:38:35 am »
I have found in the \src\plugins\compilergcc\compileroptionsdlg.cpp file in the void CompilerOptionsDlg::ProjectTargetCompilerAdjust() function if I add the following block at the end of the function and set the new boolean to true only when the code calls either of the SetCompilerID(...) function calls then I can change the compiler from MSYS2 to Cygwin or vice versa as many times I want in the project build options and the correct debugger executable is then called.

Code
    if (bNotifyUpdate == true)
    {
        CodeBlocksEvent event2(cbEVT_SETTINGS_CHANGED);
        event2.SetInt(cbSettingsType::Compiler);
        Manager::Get()->ProcessEvent(event2);
    }


Is this an acceptable solution? If not point me in the right direction please.
5
Help / Re: Project - compiler changes do not cause debugger to change
« Last post by AndrewCot on Today at 07:45:04 am »
Debugging analysis update below on what I have found in addition to the previous posts is below:

The root cause of the issue is that the current CB code does not call eventually call the cbDebuggerPlugin::SetActiveConfig(int index) in cbpplugin as this changes the CB debugger that is to be used when you start the debugger. This causes the debug config to not update, which then causes the cmdexe = GetActiveConfigEx().GetDebuggerExecutable(); line to return the previous exectable file!!!!

I have been able to proof this be hacking the code by adding the following lines to the derbuggergdb.cpp before the cmdexe = GetActiveConfigEx().GetDebuggerExecutable(); line:
Quote
    CodeBlocksEvent event2(cbEVT_SETTINGS_CHANGED);
    event2.SetInt(cbSettingsType::Compiler);
    Manager::Get()->ProcessEvent(event2);

THIS IS A HACK AS POC that my conclusion about calling SetActiveConfig(..) is correct.

This code is not correct in that it should be somewhere else in the code and potentially be a different block of code that fits better where the change should be done, but the code should still  end up calling the void DebuggerManager::FindTargetsDebugger() function as this is the function that I have found that should be called when you change the compiler based on my findings as it changes the debugger associated with the new compiler settings.  Be aware that I am not familiar with the Cb code and the correct function to call could be some other function.
6
Help / Re: Project - compiler changes do not cause debugger to change
« Last post by AndrewCot on Today at 05:24:06 am »
CB Setup Background:
1. Configure a MSYS2 debugger configuration to use the C:\msys64\mingw64\bin\gdb.exe executable
2. Configure a Cygwin debugger to use the C:\cygwin64\bin\gdb.exe executable
3. Update the existing Cygwin compiler setup to use the Cygwin configuration from step 2)
4. Copy the existing GCC GNU compiler to "MSYS2 GNN GCC Compiler" and then modify it as follows:
     4a. Change the install directory to C:\msys64\mingw64
     4b. Change the exe filenames to match the "standard" GNU exe. Change the names to use the !windows config options from the options_gcc.xml fie with the exception of the db,windres and make as per the following snippet:
        <Program name="C"         value="gcc"/>
        <Program name="CPP"       value="g++"/>
        <Program name="LD"        value="g++"/>
        <Program name="LIB"       value="ar"/>

The windres and make are not changed, but the db is changed to reference the db from step 1) above

Create working CB Projects:
1. Create a project for a simple hello world program configured for say Cygwin. Call the project as say "CygwinTest.cbp"
2. Start CB and load the project
3. Rename the C:\msys64 to c:\msys64.old
4. Build the project. If it fails then it is configured for msys2. Fix this and try building again
5. Run the debugger. If it fails then it is configured incorrectly or configured for MSYS2. Fix it and try again.
6. Save the project.
7. Rename the C:\msys64.old to c:\msys64
8. Save the project as as say "Msys2Test.cbp"
9. Select Project->Properties menu option.
10. Change the Title to "MSYS2 Test"
11. Select the Ok" button
12. Select Project->Build Options menu option.
13. Select default target on the left pane.
14. Change the selected compiler to MSYS2
15. Say "Yes" to the pop up dialogs
16. Save the project.
17. Rename the C:\cygwin64 to c:\cygwin64.old
18. Build the project. If it fails then it is configured for Cygwin. Fix this and try building again
19. Run the debugger. If it fails then it is configured incorrectly or configured for Cygwin. Fix it and try again.
20. Save the project.
21. Rename the C:\cygwin64.old to c:\cygwin64

Reproduce CB Debugger bug:
1. Close CB
2. Load the "CygwinTest.cbp"
3. Build and run the debuger
4. In the debugger log check that the C:\cygwin64\bin\gdb.exe debugger was used.
5. Select Project->Build Options menu option.
6. Select default target on the left pane.
7. Change the selected compiler to MSYS2
8. Say "Yes" to the pop up dialogs
9. Rebuild the project
10. Run the debuger
11. In the debugger log check that the C:\cygwin64\bin\gdb.exe debugger was still used. This should have changed to C:\msys64\mingw64\bin\gdb.exe, but it did not!!!!

Notes:
1. Be aware that the Cygwin and MSYS2 debuggers can debug both exe's produced.

Current Debugging Status:
So far I have tracked the problem to debuggergdb.cpp following line that loads the wrong GDB.exe. The code above it correctly loads the currently selected compiler, which in the "Reproduce CB Debugger bug:" is the MSYS2 compiler.
Code
cmdexe = GetActiveConfigEx().GetDebuggerExecutable();


7
Using Code::Blocks / Re: Problem with svn 12446
« Last post by AndrewCot on Today at 03:14:29 am »
I pulled the latest github changes and rebuilt the exe and it now does not crash on file->new->project.

8
Feedback on feedback:
1). "Disable startup scripts (-nx) (GDB only)" option.
Quote
In the Menu->Settings->Debugger settings. Open the debugger plugin setting dialog and uncheck the "Disable startup scripts (-nx) (GDB only)" option.
>> I think this option should be "checked on", I mean we don't need the startup scripts.

If I leave the option checked [X] then the pretty printer does not work and the watch looks like it does when no pretty printer is defined for wxWidget. If uncheck [ ] the option then the GDB pretty printer watch displays a wxString in a human read able format. See attachment showing this.

2.gdbinit file:
Quote
If you are using the https://github.com/wxWidgets/wxWidgets/blob/master/misc/gdb/print.py file then add the following to the gdbinit file:
    sys.path.insert(0, 'D:/temp')         
    from wxprint import register_wxwidgets_printers
    register_wxwidgets_printers (None)
    Rember to change the directory to where you have saved the print.py file.

>>I don't do like that, I just shows what I did in this post:
>>Re: Debugger: use gdb python pretty printer for the libstdcxx under msys2
>>You don't need the "hard-coded path" in those settings.

I think the page still needs an update to add the info so someone does not need to find in the forum post (like I had to do as it did not work due to item 1), but I also had to get the syntax correct in the gdbinit):
a) Copy the https://github.com/wxWidgets/wxWidgets/blob/master/misc/gdb/print.py into :
      Linux: /etc    (checked on Linux Mint 20.1 Virtual machine)
      Windows - MSYS2: x:\msys64\mingw64\etc or x:\msys64\mingw32\etc where x: is the drive you installed Msys2 onto and depending on if you are using the 32 or 64 bit compiler
      Windows - Cygwin: - Looks like it supports pretty printing, but by default no gdbinit file exists.
      Windows - Mingw64: TBA
      MacOSx: TBA
a) Add the following to gdbinit  in the directory in the step above:
Code
sys.path.insert(0, sys.path[0] + '/../../../etc')
import wxprint
9
What is the file system of the other drive? Is it linux compatible?
If it is fat or ntfs, you're probably out of luck or at least you'll have to read about umasks during mounting.

found this on another forum:

Quote
In the options, when you add user it also implies noexec.
noexec will not allow any binaries on the mounted file system to be executed.

Take a look at the mount MAN page for more information concerning the available options

I think I may be on the right track
10
NFS should support unix permissions, so it should be fine if you mount it correctly, but I'm not a sysadmin, so I might be wrong.
Pages: [1] 2 3 4 5 6 ... 10