Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
Before you use a nightly make sure you understand how it works (http://forums.next.codeblocks.org/index.php/topic,3232.0.html).
A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc452-TDM.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc452-TDM.7z
The 17 June 2012 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20120617_rev8059_win32.7z
- Linux :
none
Resolved Fixed:
- fixed crash candidate when working w/o workspace
- applied patch #3247: Remember folding (thanks marazm)
- applied patch #3253: Lexer updates (filemasks and keywords), (thanks alpha0010)
- applied patch #3270: CMake lexer (thanks alpha0010)
- compiler: Improved the 'Force target relink' featuer introduced in r7595 - now the relinking is done correctly even if the library is set in the project or in the compiler settings;
- support -std=c++11 compiler flag on the gnu compiler family
- debugger: Fix parsing watches output for static member with optimized values (thanks OsminohejTygr :) for providing the test case)
- debugger: Changed the UI name of the GDB debugger to GDB/CDB, so users are less confudes searching for the CDB debugger settings;
- project options dialog: allow to quickly enable/disable all files that belong to a target
- fixed bug described here: http://forums.next.codeblocks.org/index.php/topic,16412.msg111565.html#msg111565
- CC: avoid showing a call tip twice (in case same tip from different parents)
- SDK: remove the virtual modifier of the operator=() functions, this silence compiler warnings. see: http://forums.next.codeblocks.org/index.php/topic,16416.msg111245.html#msg111245 for more details.
- fix an issue that was introduced in commit 7543; console applications only run in console, if "Pause if execution ends" was checked; now the application runs in a terminal, if it is a console-application or if the host application should run in a terminal (set in programs arguments for the actual target); see http://forums.next.codeblocks.org/index.php/topic,16432.msg111404.html#msg111404
- fix an issue, that sometimes prevents debugger from finding the tty the app runs in, if not xterm is used as terminal; see http://forums.next.codeblocks.org/index.php/topic,16207.msg109484.html#msg109484
- SDK: Add a new virtual function: GetToolBarPriority(), which define the priority of the plugin's toolbar position, and remove the compiler warning. See: http://forums.next.codeblocks.org/index.php/topic,16416.msg111345.html#msg111345 for more details.
- new script binding: ExecuteAndGetOutputAndError
- partially applied patch #3293: Tabs: tidy context menus
- implemented ability to move/select cursor according CamelCase with CTRL (CTRL+SHIFT) in editor (options must be enabled) - is a scintilla built-in function.
- applied patch #3278: EditorTweaks: implement strip trailing blanks
- applied patch #3283: Context menu: Open link in browser (on behalf of ollydbg)
- added compiler warnings for gcc >= 4.7 to regex-list
Regressions/Confirmed/Annoying/Common bugs:
I've tried several times, but the script console never shows up.
And, the issue with relative paths I described in June 3 nightly is still there.
Other than that, working fine.
Great, well done.
Thanks
Correction: The issue with script console seems to be mine alone. Just a bad view configuration getting it out of the screen.
However, it would be nice to have some small check at loading to prevent a window being out of the desktop area.
As usual:
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (http://apt.jenslody.de/).
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc15, fc16 and fc17) can be found in my fedorarpm-repo (http://rpm.jenslody.de) .
Important note for debian (and ubuntu) users:
I changed the layout of my debian-repo, to fix the issue described in this thread:
http://forums.next.codeblocks.org/index.php/topic,16357.msg110806.html#msg110806 (http://forums.next.codeblocks.org/index.php/topic,16357.msg110806.html#msg110806)
Please (re)read the instructions on my website (http://apt.jenslody.de/), and fix your entries in /etc/apt/sources.list[.d] accordingly.
Nighly packages for RedHat/CentOS 5 and 6 are now available from my rpm-repo (http://rpm.jenslody.de) .
You need additional packages from other repos, see my site for details.
I tested the packages on CentOS 5 and 6 (64-bit).
As usual: any feedback is welcome !
Thanks for the Fedora repository
I noticed that when I build my project in this nightly, the log shows that it passed "-Wall -g" compiler parameters twice each to the command used to compile each of the source files. I doubt a well-designed compiler would care (GCC doesn't seem to mind) if such parameters were given multiple times, but I don't remember seeing this before, is it some new kind of behavior that shouldn't be happening?
Quote from: raynebc on June 26, 2012, 10:08:00 PM
I noticed that when I build my project in this nightly, the log shows that it passed "-Wall -g" compiler parameters twice each to the command used to compile each of the source files. I doubt a well-designed compiler would care (GCC doesn't seem to mind) if such parameters were given multiple times, but I don't remember seeing this before, is it some new kind of behavior that shouldn't be happening?
The parameters are a sum of the global compiler options (including additional options), the project options, the target options and attached scripts. It such options appear multiple times they might be defined in more than one place by
you. Check the settings of you compiler/project accordingly. Nevertheless, as long as these options don't conflict (i.e. debug vs. optimisation) the compiler doesn't care and simply skips options appearing twice.
I went back into the 4-14 nightly to try it again, and I indeed hadn't noticed this earlier because as of that revision, it didn't display the command line for each source file that was compiling in the build log tab. It would just say:
Compiling: file1
Compiling: file2
...
I didn't really that it would append the global/project options that way, so I've removed the redundant -g -Wall options from my project. I did notice that there seems to be an option to change the compiler logging options to go back to summary "compiling: filename" logging, and I'll probably give that a shot. Thank you for your help.
I did mention this a while ago regarding the April 14 nightly, but when building a project, Codeblocks doesn't seem to compile the source files by alphabetical order anymore. I did prefer that, because it was an easy way to tell how far the build process was without having to enable a status bar (which I see is an option). Is there a way to make it build files in alphabetical order once again?
Quote from: raynebc on June 27, 2012, 08:01:48 AM
Is there a way to make it build files in alphabetical order once again?
No. Files are compiled in order of their weight (which you can adjust in the file's property). Compiling alphabetically would break that important feature.
All of my source files are using the default build weight of 50. If the weight of all files are the same, what is the next criterion used to determine which file is built next? When none of the files have a unique weight, I don't see how building alphabetically by name would break any such feature.
crashes on vs2012 sln and vcxproj files, please fix
Quote from: keichee on June 27, 2012, 10:43:24 PM
crashes on vs2012 sln and vcxproj files, please fix
Project (file) to reproduce, please?
Quote from: raynebc on June 27, 2012, 07:44:06 PM
All of my source files are using the default build weight of 50. If the weight of all files are the same, what is the next criterion used to determine which file is built next? When none of the files have a unique weight, I don't see how building alphabetically by name would break any such feature.
Can you provide a minimal test case?
Quote from: MortenMacFly on June 28, 2012, 07:21:29 AMCan you provide a minimal test case?
I opened one of my old projects that had only one source file. I added a second source file to it and when I did a full rebuild of the project, it compiled them out of alphabetical order. Both files had a build priority weight of 50, but even after I set the priority for each file to 0, they still built out of alphabetical order. I don't think I can really simplify the problem further, since two files is the minimum for this problem to even be possible.
Possible build issue on Windows.
Building the SDK now causes an zip command error on post build steps.
Happens if the folders CodeBlocks does not exist.
Months ago, the problem did not exist.
Now, I have to create the folders share/CodeBlocks or run the update.bat after I delete or rename the devel folder.
zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
Note: It is possible the zip command I used has changed.
Tim S.
Quote from: stahta01 on July 01, 2012, 06:17:40 AM
Possible build issue on Windows.
Building the SDK now causes an zip command error on post build steps.
Happens if the folders CodeBlocks does not exist.
Months ago, the problem did not exist.
Now, I have to create the folders share/CodeBlocks or run the update.bat after I delete or rename the devel folder.
zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
I have the same error here: When build C::B (from a refresh git clone)
See the log:
QuoteCreating library file: devel\libcodeblocks.a
Output size is 52.62 MB
[ 50.0%] Running target post-build steps
[100.0%] zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
zip I/O error: No such file or directory
zip error: Could not create output file (devel/share/CodeBlocks/manager_resources.zip)
Process terminated with status 15 (13 minutes, 41 seconds)
0 errors, 16 warnings (13 minutes, 41 seconds)
Can zip command automatically create a folder?
Quote from: ollydbg on July 01, 2012, 07:46:01 AM
Can zip command automatically create a folder?
I think we should revert the commit 7972 completely and instead call update[.bat] from the projects post-build step.
Or would this break anything else ?
If I understand correctly, this patch was made to be able to run C::B from inside (or outside) without explicitely call update[.bat], to avoid crashes because of missing xrc-files.
It never made it into linux by the way.
Quote from: jens on July 01, 2012, 10:29:37 AM
Quote from: ollydbg on July 01, 2012, 07:46:01 AM
Can zip command automatically create a folder?
I think we should revert the commit 7972 completely and instead call update[.bat] from the projects post-build step.
Or would this break anything else ?
If I understand correctly, this patch was made to be able to run C::B from inside (or outside) without explicitely call update[.bat], to avoid crashes because of missing xrc-files.
It never made it into linux by the way.
After I read the file "update.bat", I agree with you. "update.bat" do more things than just compact the xrc files.
Quote
call update[.bat] from the projects post-build step
If so, which target can we put the "update.bat" in post-build step?
Quote from: ollydbg on July 01, 2012, 11:53:55 AM
If so, which target can we put the "update.bat" in post-build step?
Quote from: jens on July 01, 2012, 10:29:37 AM
[...] call update[.bat] from the projects post-build step.
There is critical bug in C++ parser. If you insert "magic" code in any unit/header file (included in C++ project) then Code::Blocks will hangs up.
Magic code (copy exactly all quote):
Quotetypedef std::enable_if<N > 1, get_type_N<N-1, Tail...>> type;
Looks like parser gets stuck on "N > 1". If to surround it by parentheses, then all works fine.
Quote from: jens on July 01, 2012, 10:29:37 AM
If I understand correctly, this patch was made to be able to run C::B from inside (or outside) without explicitely call update[.bat], to avoid crashes because of missing xrc-files.
True. We basically use two ways to update the resources in all plugins / projects: Either we call an
update.bat or we
zip the resources form inside the project's post-build steps (in that case these steps should
always be executed - that is a common error).
So I see two solutions: Either we add a pre-build command which creates the required output folders
OR we run update.bat as project's post-build step as Jens suggested. The latter has one drawback though: If you compile a specific target (like I do sometimes) this won't work probably. That's why I liked the idea of having the steps bound to the targets. So I tend to solution 1: Add the creation of that output folders either to the pre- or post-build steps.
Quote from: MortenMacFly on July 01, 2012, 02:58:24 PM
[...]
The latter has one drawback though: If you compile a specific target (like I do sometimes) this won't work probably.
[...]
What does not work ?
A project postbuild step should be executed for single targets and for the whole project.
And normally it should be enough to execute it only if the target project was not uptodate.
Calling update.bat will mean that the output folder copy of Code::Blocks can not be used to build the devel copy of code::blocks.
Tim S.
If the required directory structure is to be created from pre- and post-build steps by the plugin projects, maybe adding those steps to the C::B plugin project generated by the wizard would be a good idea.
Quote from: ptDev on July 01, 2012, 04:55:05 PM
If the required directory structure is to be created from pre- and post-build steps by the plugin projects, maybe adding those steps to the C::B plugin project generated by the wizard would be a good idea.
the wizard created plugins should create a cbplugin-file (packed library and resources), that can be installed by C::B's pluginmanager.
Doing this in pre- and postbuild steps would make the compiled plugins undeployable.
Quote from: jens on July 01, 2012, 05:26:00 PM
Quote from: ptDev on July 01, 2012, 04:55:05 PM
If the required directory structure is to be created from pre- and post-build steps by the plugin projects, maybe adding those steps to the C::B plugin project generated by the wizard would be a good idea.
the wizard created plugins should create a cbplugin-file (packed library and resources), that can be installed by C::B's pluginmanager.
Doing this in pre- and postbuild steps would make the compiled plugins undeployable.
I don't understand what the problem is.
Doing it in the pre- and postbuild steps
instead of in deployment would break deployment, of course. But if this step is also done when a build is done, it would make development much easier.
Quote from: MortenMacFly on July 01, 2012, 02:58:24 PM
So I tend to solution 1: Add the creation of that output folders either to the pre- or post-build steps.
I like this solution, because I think each target should contain its own "update" script(not copy or zip other target's data).
I think put the creation of folders in the target's post-build step is better than pre-build :)
This can also solve the problem as Tim said:
Quote from: stahta01 on July 01, 2012, 04:24:37 PM
Calling update.bat will mean that the output folder copy of Code::Blocks can not be used to build the devel copy of code::blocks.
Tim S.
Mainly, the update.bat do three things:
1, create necessary folders under devel folder
2, copy/zip necessary XRC files to devel folder
3, copy all the necessary files from devel folder to output folder, and run strip.
I think the step 3 is not necessary when I'm developing/debugging C::B.
Quote from: japplegame on July 01, 2012, 01:32:50 PM
There is critical bug in C++ parser. If you insert "magic" code in any unit/header file (included in C++ project) then Code::Blocks will hangs up.
Magic code (copy exactly all quote):
Quotetypedef std::enable_if<N > 1, get_type_N<N-1, Tail...>> type;
Looks like parser gets stuck on "N > 1". If to surround it by parentheses, then all works fine.
The code is toooooo magic for me that I can't understand the grammar, but the parser should not hang in any case, so I will dig into it.
Quote from: ollydbg on July 02, 2012, 04:10:03 AM
The code is toooooo magic for me that I can't understand the grammar, but the parser should not hang in any case, so I will dig into it.
This patch can avoid the loop.
src/plugins/codecompletion/parser/parserthread.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/plugins/codecompletion/parser/parserthread.cpp b/src/plugins/codecompletion/parser/parserthread.cpp
index d193e0d..9062ded 100644
--- a/src/plugins/codecompletion/parser/parserthread.cpp
+++ b/src/plugins/codecompletion/parser/parserthread.cpp
@@ -2504,7 +2504,7 @@ void ParserThread::ReadClsNames(wxString& ancestor)
else // unexpected
{
TRACE(_T("ReadClsNames() : Unexpected token '%s'."), token.wx_str());
- m_Tokenizer.UngetToken();
+ //m_Tokenizer.UngetToken();
break;
}
}
but I don't think the magic code can parse correctly, the grammar/semantic is too complex.
Quote from: jens on July 01, 2012, 03:46:58 PM
What does not work ?
It means that pre-requisite might not be fulfilled and therefore the script can fail.
Very good, ollydbg. I don't need correct parsing. Hangless work is enough. :)
Hello!
First - thanks for your great job. I have recognized since some time that the multi-line edit does not work correctly with using the tab-key or deleting in multi-line edit mode. The first attached screenshot shows the multi-line selection spanning three lines. After pressing the tab-key, the cursor jumps to the first column and selects a region before the previous position (see second screenshot). Using the delete-key (starting from situation in the first screenshot), the result becomes even more strange (see third screenshot). Could you please fix this? Thanks!
Best, Daniel
-- Just see that there is a new nightly. But the issue remains with 8081 as well (on Win7).
Quote from: stg on July 04, 2012, 08:56:50 PM
Hello!
First - thanks for your great job. I have recognized since some time that the multi-line edit does not work correctly with using the tab-key or deleting in multi-line edit mode. The first attached screenshot shows the multi-line selection spanning three lines. After pressing the tab-key, the cursor jumps to the first column and selects a region before the previous position (see second screenshot). Using the delete-key (starting from situation in the first screenshot), the result becomes even more strange (see third screenshot). Could you please fix this? Thanks!
Best, Daniel
-- Just see that there is a new nightly. But the issue remains with 8081 as well (on Win7).
I do not have such issues here.
What are your Code::Blocks version (nightly?) and your operating system ?
What are your settings in : "Settings -> Editor... -> Margins and caret -> Selections" ?
Now, nightly 8081 on Win7 using Settings/Editor/.../Selections:
[ ] Enable virtual space
[ x ] Allow multiple sections
[ x ] Enable typing ...
Quote from: stg on July 04, 2012, 09:31:16 PM
Now, nightly 8081 on Win7 using Settings/Editor/.../Selections:
[ ] Enable virtual space
[ x ] Allow multiple sections
[ x ] Enable typing ...
Works here with the same settings (fedora 17 64 bit).
I will test it on win7 as soon as possible.
Quote from: jens on July 04, 2012, 10:12:30 PM
Works here with the same settings (fedora 17 64 bit).
I will test it on win7 as soon as possible.
With a clean installation/download, all works fine, I have just figured out. By checking out the diff between my old codeblocks directory and the clearn one, I have found that all works find when I remove the dictionary files in the SpellChecker folder (which I had have added myself):
en_US.aff
en_US.dat
en_US.dic
en_US.idx
I have downloaded the files "en_US.aff, en_US.dat" from OpenOffice again and copied it into a clean installation/download of CodeBlocks nightly 8081. Actually, I downloaded "en_US.oxt", opened it with 7z and copied the files into the SpellChecker folder.
Anyway - again, I can reproduce the above behaviour with the multiline edit. Can someone else reproduce it as well?
Best, Daniel
Quote from: stg on July 05, 2012, 09:23:27 PM
I have downloaded the files "en_US.aff, en_US.dat" from OpenOffice again and copied it into a clean installation/download of CodeBlocks nightly 8081. Actually, I downloaded "en_US.oxt", opened it with 7z and copied the files into the SpellChecker folder.
Anyway - again, I can reproduce the above behaviour with the multiline edit. Can someone else reproduce it as well?
Best, Daniel
i still cannot reproduce it.
You can try what happens, if you disable the spellchecker-plugin from "Plugins -> Manage plugins..." and if that helps, what happens if you play with the spellchecker settings (not really much, I know).
Quote from: jens on July 05, 2012, 10:12:17 PM
i still cannot reproduce it.
You can try what happens, if you disable the spellchecker-plugin from "Plugins -> Manage plugins..." and if that helps, what happens if you play with the spellchecker settings (not really much, I know).
Seems to be very obvious that its the SpellChecker plugin. Having it disabled, everything works fine. Enabling it with the en_US dictionary, deletion in multiline edit mode works not properly. Maybe, it has something to do with the dictionaries? But as I said, I have just downloaded it from OpenOffice.
Edit: Note that I have disabled the SpellChecker plugin via Settings / Editor / SpellChecker
Quote from: ollydbg on July 02, 2012, 05:11:38 AM
This patch can avoid the loop.
...but introduces a lot other hangs / freezes on "not so complex" code. BE careful, this introduces even more serious hangs!
This complete noob can't figure out how to get the "Can't find compiler executable in your configured search path's for GNU GCC Compiler" error to not appear.
I followed the instructions from the nightly sticky thread here exactly:
Quote3. How to install a nightly build
Allrighty, time for a small recap :
1) CB nightly
2) mingwm10.dll
3) wxmsw28u_gcc_cb.dll
Those are the 3 things we need to install and start up a nigthly build. All 3 of them are available in their own zip file, zipped by using the free and excellent 7-zip (www.7-zip.org). Just get your copy of 7-zip for unzipping.
Final steps :
1) unzip the CB nightly in some directory
2) unzip both dll's : requirement : they need to be in your PATH, most easiest is to unzip both of them into the same directory where you unzipped the nightly, so they reside next to the codeblocks.exe .
By performing these simple steps you nightly is ready to roll.
The 8059 nightly, mingwm10.dll, and wxmsw28u_gcc_cb.dll are all in the C:\Program Files (x86)\CodeBlocks directory, yet I see this error every time I start up CodeBlocks and programs simply do not respond to the Compile button (surprise, surprise).
Some browsing on the forum made it seem like it has something to do with changing Settings > Compiler > (GNU GCC Compiler) > Search Directories to include this path under the Compiler sub-tab ("they need to be in your PATH"), but this only makes the error appear again. Help setting this us would be very appreciated!
Quote from: Epicurus on July 07, 2012, 07:36:26 AM
Some browsing on the forum made it seem like it has something to do with changing Settings > Compiler > (GNU GCC Compiler) > Search Directories to include this path under the Compiler sub-tab ("they need to be in your PATH"), but this only makes the error appear again. Help setting this us would be very appreciated!
Well you have to install a
full compiler suite (which is not part of the nightlies) and adjust the path to the tool chain executables in the compiler options accordingly. There is a note given what path you have to provide: the "master path" to your compiler, so
not the
bin sub-folder or alike.
Quote from: MortenMacFly on July 07, 2012, 09:08:02 AM
Quote from: Epicurus on July 07, 2012, 07:36:26 AM
Some browsing on the forum made it seem like it has something to do with changing Settings > Compiler > (GNU GCC Compiler) > Search Directories to include this path under the Compiler sub-tab ("they need to be in your PATH"), but this only makes the error appear again. Help setting this us would be very appreciated!
Well you have to install a full compiler suite (which is not part of the nightlies) and adjust the path to the tool chain executables in the compiler options accordingly. There is a note given what path you have to provide: the "master path" to your compiler, so not the bin sub-folder or alike.
I hope i don't come off as too dense or disrepectful with this but i think it would be a good idea ( perhaps as a feature request ) to have a separate "nightlyUpdate.exe" created that could be called from a C::B menu option which would close C::B and then run that exe. I would love if your team could have that designed to ask with a small form and a browse button where the desired nightly is located on the user's hard drive.
or did i completely miss the idea O:-)
Hi,
there is apparently a small error introduced at line 71 in sdk/autodetectcompilers.cpp (svn 8086) which makes xgettext fail to prepare strings for CB Translation. It's a non ascii character following the word *probably*.
Its :
else // The compiler is *probably*Ü invalid, but at least a master-path is set
I suppose the good line should be :
else // The compiler is *probably* invalid, but at least a master-path is set
gd_on
Quote from: gd_on on July 07, 2012, 04:13:27 PM
there is apparently a small error introduced at line 71 in sdk/autodetectcompilers.cpp (svn 8086) which makes xgettext fail to prepare strings for CB Translation.
My fault. Fixed in SVN.
Noticed a warning in the wxSmith build; no idea how long it has been there.
I am using MinGW GCC version 4.6.x and 4.7.0 doing testing to see how they work.
It might be a new warning with one of those versions.
Tim S.
src\plugins\contrib\wxSmith\wxwidgets\wxsitemresdataobject.cpp|127|warning: converting 'false' to pointer type 'wxsItem*' [-Wconversion-null]|
Patch untested for working; compiled on Windows OK
Index: src/plugins/contrib/wxSmith/wxwidgets/wxsitemresdataobject.cpp
===================================================================
--- src/plugins/contrib/wxSmith/wxwidgets/wxsitemresdataobject.cpp (revision 8093)
+++ src/plugins/contrib/wxSmith/wxwidgets/wxsitemresdataobject.cpp (working copy)
@@ -124,7 +124,7 @@
if ( !Item )
{
Item = wxsItemFactory::Build(_T("Custom"),Data);
- if ( !Item ) return false;
+ if ( !Item ) return 0;
}
Item->XmlRead(Root,true,true);
Tim S.
Thanks again for your help MortenMacFly! I installed MinGW and my ProjectEuler exercise compiled and ran beautifully!
Do I need to worry about adding the directory for MinGW every time I upgrade the nightly? Presumably, I would delete my old version and install the new version in the same directory, including the two necessary DLLs.
Quote from: Epicurus on July 09, 2012, 06:31:49 AM
Do I need to worry about adding the directory for MinGW every time I upgrade the nightly?
Usually not. The path is stored in the
default.conf configuration file of Code::BLocks which is by default not in the installation folder. However, if you are using a portable installation - then it is. If you remove it, you have to setup the path again afterwards.
I've just switched from 10.05 to nightly build 8059 and have encountered a problem with linker settings (using Ubuntu 12.04, 64-bit). In 10.05 I could specify $ORIGIN in the linker settings by putting '-Wl,-R\\$$ORIGIN' in the 'other linker options' section, but this doesn't work any more. The build log shows '-Wl,-R\\', but no mention of $ORIGIN. Is there a better/different way of specifying $ORIGIN now?
DrShred: have you tried to find a suitable variable here: http://wiki.codeblocks.org/index.php?title=Variable_expansion
I suppose origin was an internal variable, so you've not meant to use it.
Quote from: DrShred on July 10, 2012, 09:53:53 AM
I've just switched from 10.05 to nightly build 8059 and have encountered a problem with linker settings (using Ubuntu 12.04, 64-bit). In 10.05 I could specify $ORIGIN in the linker settings by putting '-Wl,-R\\$$ORIGIN' in the 'other linker options' section, but this doesn't work any more. The build log shows '-Wl,-R\\', but no mention of $ORIGIN. Is there a better/different way of specifying $ORIGIN now?
Since some revisions we replace macros and variables in the linker settings.
You can try to triple the $-sign (
-Wl,-R\\$$$ORIGIN).
Triple $$$ works great! Thanks for the quick replies!