Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
Development / Re: SF Ticket Patches & SVN 12539 query
« Last post by Miguel Gimenez on Today at 12:54:47 pm »
I can't apply them, only developers can.

1131 has just been owned by ollydbg.
2
Are you using UCRT64 or MINGW64 command prompt to do the building?

Tim S.
3
Let me start by saying that the issues could be due to my Windows 11 setup and if you think they are let me know. I have W11 installed as a guest as I want to play with it before upgrading my main PC as IMHO I do not want to get stuck and have to reinstall everything again on my main PC.

I have Windows 11 configured as a virtual guest on Virtualbox 6.1.30 under Windows 10. I have installed MSYS 2 and installed a bunch of packages like I have on my W10 box. I copied my wxwidget 3.1.5 source tree from W10 to W11 and tried to build it, but it hung when creating the DLL using the bin utilities ar.exe. I tried again is the same thing occurred.

Anyone got any pointers or ideas on this one or should I try the wxwidget forums? I won't look at this tonight (Oz time).  O could try a different compiler  or bin utilites or the latest wxwidget source or TBA  or .....
4
Development / Re: SF Ticket Patches & SVN 12539 query
« Last post by AndrewCot on Today at 10:02:38 am »
I didn't go back too far. Let me know when you apply them so I can grab the updated SVN trunk.
5
Development / Re: SF Ticket Patches & SVN 12539 query
« Last post by Miguel Gimenez on Today at 09:13:13 am »
I have them (and five more) in my radar, I hope they will be applied soon.
Quote
1154  Disable "Copy To" button in global compiler options
1150  Document linker options without description
1149  Encoding mismatch
1148  Encoding mismatch when using split view
1147  wxSmith: add missing events to wxsFrame
1146  Add make_unique and make_unique_for_overwrite to the C++ lexer
1133  Compiler is checked for skipped targets
1131  Fix hack in CodeCompletion's regex
1103  Build Options: Problem sorting link libraries
1095  Check validity of text in Find & Replace dialog before exiting
6
Development / SF Ticket Patches & SVN 12539 query
« Last post by AndrewCot on Today at 02:03:21 am »
I was checking as I thought that it's been a while since I did one of my unofficial installer builds, but there is not allot of changes so it may not be worth it.

I see there are two changes applied since the last nightly 12537, but there are patches in some of the tickets that have not been commented on or reviewed as per the following tickets:

Any chance of looking at the patches in the tickets above and giving feedback and/or incorporating them so they do not become stale and get forgotten?
7
Using Code::Blocks / Re: Tools menu and Linux environment
« Last post by cacb on November 28, 2021, 10:25:03 am »
So the big question is, is this expected behaviour from codeblocks or not? I mean, isn't codeblocks adding its own paths to LD_LIBRARY_PATH, and when we use them in the Tools menu start, could this interfere?
When you start the built-in debugger in C::B, then C::B will modify the LD_LIBRARY_PATH setting for that debug run as reported in the C::B console, it includes the project's linker search directories I believe. That's a reasonable behavior for the debugger plug-in.

A different question is what happens when you run something from the Tools menu. It seems to me now that LD_LIBRARY_PATH is undefined in that context because neither codeblocks (the parent process) nor the Tools menu item is running in the context of a bash shell, so ~/.bashrc isn't involved. Because I had defined LD_LIBRARY_PATH there, it wasn't applied when I tried external debuggers. When i repeated the same command from a terminal window it worked because it was started from a bash shell.

So my guess is that codeblocks does not actively erase the LD_LIBRARY_PATH setting when running Tools menu items, it just doesn't apply any bash settings. That means the behavior should have been expected.

Placing the *.so search path in  /etc/ld.so.conf.d/myconfig.conf makes loading shared libraries independent of bash, so then it works in both cases. It is quite logical, the only thing is that the path /etc/ld.so.conf.d/ is quite odd :-)

At least this is my understanding, I am happy to be corrected if some of this is inaccurate.
8
Using Code::Blocks / Re: Tools menu and Linux environment
« Last post by BlueHazzard on November 27, 2021, 11:39:12 pm »
So the big question is, is this expected behaviour from codeblocks or not? I mean, isn't codeblocks adding its own paths to LD_LIBRARY_PATH, and when we use them in the Tools menu start, could this interfere?
9
As gd_on said you should use libstdc++-6.dll from the bin folder of your MinGW installation (the one you used to compile your program). The one near CodeBlocks may be from another version of the compiler, it may work at first but can give you errors later.

Copy it to the folder containig your executable, you may need to copy others afterwards.
10
Using Code::Blocks / Re: running code blocks programs directly from command prompt
« Last post by welderrprman on November 27, 2021, 03:31:53 pm »
I see the libstdc++-6.dll file in code blocks.  Is it possible to copy that file into my projects?  How would I link that to my projects so that I can go directly into command prompt and run the programs from there?
Pages: [1] 2 3 4 5 6 ... 10