Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
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?
2
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.
3
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?
4
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.
5
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?
6
Using Code::Blocks / Re: running code blocks programs directly from command prompt
« Last post by welderrprman on November 27, 2021, 03:12:02 pm »
Yes I saw in the files that this question has been asked before.  The error message  states it cannot find libstdc++-6.dll.  In the process of using a utube video to work around this.  Release 20.03 rev 11983     Program is on c: \c++programs
7
General (but related to Code::Blocks) / Re: Welcome Newcomers - PLEASE READ!!!
« Last post by everSome on November 27, 2021, 10:07:40 am »
I am new, I am here
8
General (but related to Code::Blocks) / Re: C::B library name processing policy
« Last post by Miguel Gimenez on November 27, 2021, 09:44:50 am »
The processing of library filenames is made in CompilerCommandGenerator::SetupOutputFilenames() at compilercommandgenerator.cpp:648.

Variable PrefixPolicy is loaded with the value in Project -> Properties -> Build targets -> Auto-generate filename prefix.
9
General (but related to Code::Blocks) / Re: C::B library name processing policy
« Last post by mirai on November 27, 2021, 08:11:08 am »
No, C::B is converting project settings to linker commands and the question is when and how does it convert provided library names.
10
General (but related to Code::Blocks) / Re: C::B library name processing policy
« Last post by AndrewCot on November 27, 2021, 12:42:23 am »
You will need to lookup the linker documentation as C::B is an IDE and the linker does the linking not C::B.

The GNU linker docs are available at https://sourceware.org/binutils/docs/ld/  . The section you want is https://sourceware.org/binutils/docs/ld/Options.html . The two parameters you will be interested in are -l & -L .
Pages: [1] 2 3 4 5 6 ... 10