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 14 April 2012 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20120414_rev7932_win32.7z
- Linux :
none
Resolved Fixed:
- debugger plugin: Adjust the regular expression to match the pending breakpoint of gdb 7.5 and later. See: http://forums.next.codeblocks.org/index.php/topic,16116.msg109217.html#msg109217 for the detailed discussion
- debugger: Try to use the project's compiler first, if there is no active target, then try the default compiler (thanks to Pecan)
- SpellChecker plugin: fixed another crash-candidate, remove duplicate code
- fixed inconsistency in wxSmith plugin (out of sync with wxSmith files) as reported here: http://forums.next.codeblocks.org/index.php/topic,16195.0/topicseen.html (thanks frithjofh)
Regressions/Confirmed/Annoying/Common bugs:
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo (http://apt.jenslody.de/).
I have tested the Windows release briefly under XP SP3. It works, but everything lags notably compared to the previous nightly I had installed (7452). I am using MSVC2008 compiler.
For example, I am just testing a small console program using boost. When using 7392 it takes 10 seconds before I see anything in the build log window (i.e. that no rebuild is required) after pressing the toolbar build button. With the old nightly (7452), the respons is immediate.
Even exiting 7392 takes notably longer.
I am really interested in the new release for Linux, due to the new debugger integration. I want to use the same nightlies under both OSes, but the lag issue on Windows is currently a problem.
Quote from: cacb on April 15, 2012, 07:03:45 PM
I have tested the Windows release briefly under XP SP3. It works, but everything lags notably compared to the previous nightly I had installed (7452). I am using MSVC2008 compiler.
For example, I am just testing a small console program using boost. When using 7392 it takes 10 seconds before I see anything in the build log window (i.e. that no rebuild is required) after pressing the toolbar build button. With the old nightly (7452), the respons is immediate.
Even exiting 7392 takes notably longer.
I am really interested in the new release for Linux, due to the new debugger integration. I want to use the same nightlies under both OSes, but the lag issue on Windows is currently a problem.
Rev7452 is too old, I'm not sure which branch did you use? the debugger branch nightly or the trunk? After that, many code changes have made to the debugger branch.We laso have many nightly build released, did you try those?
Quote from: ollydbg on April 16, 2012, 02:16:08 AM
Rev7452 is too old, I'm not sure which branch did you use? the debugger branch nightly or the trunk? After that, many code changes have made to the debugger branch.We laso have many nightly build released, did you try those?
I don't build CB myself, i simply download the nightlies as provided here. Usually, that is quite adequate (thanks guys...).
7452 as I used it is this one
http://forums.next.codeblocks.org/index.php/topic,15263.0.html
7452 is much faster on my XP machine, as explained.
If didn't checked the "Enhanced multi-monitor dialog placement" , the "About" dialog will not shown at center of screen. why?
Hello,
I am under Ubuntu 11.10 64 bit using Jens's ppa.
I've noticed that after installing "libwxsmithlib0" (and all its dependencies) codeblocks is stucked and doesn't show up.
The process stays in the background.
Starting it from comand line displays the following :
=================================================
Initialize EditColourSet .....
Initialize EditColourSet: done.
Loading toolbar...
ReopenEditor: loaded
MouseSap: loaded
ToolsPlus: loaded
Autosave: loaded
Debugger: loaded
AutoVersioning: loaded
BYOGames: loaded
lib_finder: loaded
ProjectsImporter: loaded
Exporter: loaded
ClassWizard: loaded
EnvVars: loaded
HeaderFixup: loaded
CB_Koders: loaded
SpellChecker: loaded
NassiShneidermanPlugin: loaded
ToDoList: loaded
copystrings: loaded
wxSmith: loaded
wxSmithMime: loaded
FileManager: loaded
ScriptedWizard: loaded
CppCheck: loaded
AStylePlugin: loaded
Cscope: loaded
Cccc: loaded
wxSmithAui: loaded
SymTab: loaded
IncrementalSearch: loaded
CodeSnippets: loaded
Abbreviations: loaded
HexEditor: loaded
CodeCompletion: loaded
BrowseTracker: loaded
OpenFilesList: loaded
Profiler: loaded
DoxyBlocks: loaded
FilesExtensionHandler: loaded
wxSmithContribItems: loaded
HelpPlugin: loaded
RegExTestbed: loaded
Valgrind: loaded
ThreadSearch: loaded
EditorTweaks: loaded
cbDragScroll: loaded
cbKeyBinder: loaded
Compiler: loaded
CodeStat: loaded
ReopenEditor plugin activated
MouseSap plugin activated
ToolsPlus plugin activated
Autosave plugin activated
Debugger plugin activated
AutoVersioning plugin activated
BYO Games plugin activated
(codeblocks:8068): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 18 and height -17
Library finder plugin activated
Foreign projects importer plugin activated
Source Exporter plugin activated
Class wizard plugin activated
Environment variables plugin activated
Header Fixup plugin activated
Koders query plugin activated
=================================================
After removing "libwxsmithlib0" all goes back to normal.
I don't know at which nightly this problem started to occur.
Thanks a lot for your work.
cacb: Can you try the nightlies after 7452 and then tell us which is the first one where you see the slowness?
Quote from: nanyu on April 16, 2012, 08:29:05 AM
If didn't checked the "Enhanced multi-monitor dialog placement" , the "About" dialog will not shown at center of screen. why?
See this: 005516 (https://developer.berlios.de/feature/?func=detailfeature&group_id=5358&feature_id=5516)
We have discussed already, but I'm not quite sure other developer's option.
Quote from: nanyu on April 16, 2012, 08:29:05 AM
why?
Because its not implemented using the "centred" flag.
Quote from: oBFusCATed on April 16, 2012, 01:32:02 PM
cacb: Can you try the nightlies after 7452 and then tell us which is the first one where you see the slowness?
I'm on a different XP computer right now, although somewhat similar setup. Here I have 7789 installed with apparently no noticeable slowness. I.e. 7789 as found at http://forums.next.codeblocks.org/index.php/topic,15945.0.html
I'll try to backtrack from 7932 on the other computer to see if I can determine when the lag appears. Until later.
Same problem with lags, after rev 7918 and later (main brunch, not debugger brunch)
Platform: Win 7 Home Premium x64.
NilC:
What is the last nightly that has no lag?
Can you try the debugger's branch nightly from the same date?
7932 has the lag
7925 appears to have the lag
7917 appears to have the lag
7452 no lag
7385 no lag
cacb: What about 7789, 7678, 7550?
Quote from: cacb on April 16, 2012, 11:11:03 PM
7932 has the lag
7925 appears to have the lag
7917 appears to have the lag
7452 no lag
7385 no lag
I do not have such lag.
QuoteWhen using 7392 it takes 10 seconds before I see anything in the build log window (i.e. that no rebuild is required) after pressing the toolbar build button. With the old nightly (7452), the respons is immediate.
In my Computer (WinXP, C::B nightly build 7932), the build log shows immediate after I press the toolbar button.
Did you use "debugger branch nightly" or "normal trunk nightly". Can you do some test to see from which nightly build version, the lag begins. Thanks.
oBFusCATed,
7790 - no lags,
7918 (debugger brunch), 7917 (main brunch) - first builds with lags
Hi,
I'm new to windows and was looking for a nice alternative to MS Visual Studio 2010. So I wanted to try CB for the first time and installed the nightly 7932 as described in the first post of this thread on a Win7 64 bit machine. Then I chose the installed MSVC 2010 compiler, skipped the spellchecker installation and file association and tried to import a *.sln file. I said yes to using the default compiler and yes to import all settings, but then CB dies and I'm offered to close or debug the program. When starting the debugger I can't figure out much though b/c I don't have the sources installed.
How can I help debugging this problem?
You gave steps, but there is also the crash log which could help them.
Quote from: vollkorn on April 18, 2012, 10:48:25 AM
How can I help debugging this problem?
Provide a simple test case (i.e. a minimal MSVS project) to reproduce.
In this post you can find the report file with three crashs and a test.sln I tried to open during the last crash.
Quote from: vollkorn on April 19, 2012, 09:54:04 AM
In this post you can find the report file with three crashs and a test.sln I tried to open during the last crash.
Having just the solution file is not enough, because there is nothing to import. Please provide a full minimal sample, including at least the project files. To try, please copy your solution / project / other files (step-by-step, as needed) into a new folder an try to import from there until C::B crashes, that provide exactly that full set of files (zipped) here.
I deleted the debug folders and the SQL server's file to meet the space limit of this upload funciton.
[attachment deleted by admin]
Sorry, I forgot to mention: The crash occurs already with the test.sln only. No other files needed, but I included as much as possible just to make sure.
Not found any lags at 7932 and do not remember ones with DEBUGGER BRANCH. Now I use niXman mingw package (http://sourceforge.net/projects/mingwbuilds/), but similar situation was with TDM mingw + ollydbg gdb. Lags occurs when I try to view large STL containers.
Quote from: nenin on April 19, 2012, 04:05:36 PM
Lags occurs when I try to view large STL containers.
Explain please. What does it mean view?
Quote from: oBFusCATed on April 19, 2012, 04:08:40 PM
Quote from: nenin on April 19, 2012, 04:05:36 PM
Lags occurs when I try to view large STL containers.
Explain please. What does it mean view?
"View" means "watch under debugger".
OK, this is normal and it is unfixable at the moment.
Quote from: oBFusCATed on April 19, 2012, 05:55:15 PM
OK, this is normal and it is unfixable at the moment.
I wonder if it possible to tune gdb to show, for example, first 100 elements in container by default.
You have to edit the python scripts or the stl-views.gdb script in C::B to do it.
Quote from: ollydbg on April 17, 2012, 05:25:39 AM
Did you use "debugger branch nightly" or "normal trunk nightly". Can you do some test to see from which nightly build version, the lag begins. Thanks.
Sorry, I have been away, ongoing family issue. I have never used debugger branch, never built CB myself. Only downloaded pre-built nihgtlies, always main version which I presume is based on trunk.
Quote from: cacb on April 19, 2012, 08:21:34 PM
I have never used debugger branch, never built CB myself. Only downloaded pre-built nihgtlies, always main version which I presume is based on trunk.
The latest nightly is basically the debugger branch as it has been merged into trunk meanwhile.
Quote from: nenin on April 19, 2012, 06:00:36 PM
Quote from: oBFusCATed on April 19, 2012, 05:55:15 PM
OK, this is normal and it is unfixable at the moment.
I wonder if it possible to tune gdb to show, for example, first 100 elements in container by default.
See:Why C::B over write gdb's set print element value? (http://forums.next.codeblocks.org/index.php/topic,15620.msg105073.html#msg105073)
And you can use:
set print elements 100
In your custom startup .gdb script file.
Quote from: ollydbg on April 20, 2012, 02:27:52 AM
See:Why C::B over write gdb's set print element value? (http://forums.next.codeblocks.org/index.php/topic,15620.msg105073.html#msg105073)
And you can use:
set print elements 100
In your custom startup .gdb script file.
Not works when I watch std::container. :(
With array it works.
I've installed this built on a few machines. To my surprise I can't seem to use the Watches window on one of them. I can't seem to get my head around to why is that. The Watch window is empty - It should show local variable and function arguments but it doesn't. I can add a watch manually - then the entire entry turns red.
I've tried doing this with multiple versions of nightly builts as well as mingws. It seems that on one of my machines I the Watches window just doesn't work.
It works fine on the normal Code::Blocks 10.5 though.
Any ideas?
I'm running windows 7 x64, copied all the dlls from the post, using MinGW attached to Code::Blocks 10.5 or MinGW 5.16.
the nightlies and the MinGW are in a path without spaces, the C::B 10.5 contains spaces in it's path - could this somehow be an issue?
Local variables and function arguments are not reimplemented in the new watches window, sorry...
The red entries in the watches window means that the value of the watch has just changed, this pretty usefull if you step through the code.
And the first time you add a watch it is red, but the values should be correct. Are they correct?
CB + TortoiseSVN: CB crashes when I choose project folder in File Explorer (win 7, Tortoise 1.7 build r22413)
Here is log:
Error occured on Friday, April 20, 2012 at 06:23:16.
D:\codeblocks\nightly\codeblocks.exe caused an Access Violation at location 63082ca2 in module D:\codeblocks\nightly\share\codeblocks\plugins\FileManager.dll Reading from location 00000000.
Registers:
eax=00000000 ebx=00000000 ecx=7ffde000 edx=00000000 esi=00000000 edi=03ce1580
eip=63082ca2 esp=0022f71c ebp=0022f7a4 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
Call stack:
63082CA2 D:\codeblocks\nightly\share\codeblocks\plugins\FileManager.dll:63082CA2
63082FBB D:\codeblocks\nightly\share\codeblocks\plugins\FileManager.dll:63082FBB
6308C50E D:\codeblocks\nightly\share\codeblocks\plugins\FileManager.dll:6308C50E
6CCC7670 D:\codeblocks\nightly\wxmsw28u_gcc_cb.dll:6CCC7670 _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
6CCC77A9 D:\codeblocks\nightly\wxmsw28u_gcc_cb.dll:6CCC77A9 _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler
6CCC7B74 D:\codeblocks\nightly\wxmsw28u_gcc_cb.dll:6CCC7B74 _ZN12wxEvtHandler12ProcessEventER7wxEvent
6CCC7528 D:\codeblocks\nightly\wxmsw28u_gcc_cb.dll:6CCC7528 _ZN12wxEvtHandler20ProcessPendingEventsEv
6CC417AE D:\codeblocks\nightly\wxmsw28u_gcc_cb.dll:6CC417AE _ZN12wxAppConsole20ProcessPendingEventsEv
6D05E549 D:\codeblocks\nightly\wxmsw28u_gcc_cb.dll:6D05E549 _ZN18wxIconLocationBaseC2ERK8wxString
757C7B45 C:\Windows\system32\USER32.dll:757C7B45 GetUserObjectInformationA
757D31EB C:\Windows\system32\USER32.dll:757D31EB GetClassNameW
757D4260 C:\Windows\system32\USER32.dll:757D4260 ChangeWindowMessageFilter
7725642E C:\Windows\SYSTEM32\ntdll.dll:7725642E KiUserCallbackDispatcher
6CCF569A D:\codeblocks\nightly\wxmsw28u_gcc_cb.dll:6CCF569A _ZN11wxEventLoop8DispatchEv
6CD8D518 D:\codeblocks\nightly\wxmsw28u_gcc_cb.dll:6CD8D518 _ZN17wxEventLoopManual3RunEv
6CD6BB19 D:\codeblocks\nightly\wxmsw28u_gcc_cb.dll:6CD6BB19 _ZN9wxAppBase8MainLoopEv
0044D016 D:\codeblocks\nightly\codeblocks.exe:0044D016
6CC73248 D:\codeblocks\nightly\wxmsw28u_gcc_cb.dll:6CC73248 _Z14wxUninitializev
6CCCD392 D:\codeblocks\nightly\wxmsw28u_gcc_cb.dll:6CCCD392 _Z7wxEntryP11HINSTANCE__S0_Pci
004492F9 D:\codeblocks\nightly\codeblocks.exe:004492F9
00487EA6 D:\codeblocks\nightly\codeblocks.exe:00487EA6
004010DB D:\codeblocks\nightly\codeblocks.exe:004010DB
00401158 D:\codeblocks\nightly\codeblocks.exe:00401158
75991174 C:\Windows\system32\kernel32.dll:75991174 BaseThreadInitThunk
7726B3F5 C:\Windows\SYSTEM32\ntdll.dll:7726B3F5 RtlInitializeExceptionChain
7726B3C8 C:\Windows\SYSTEM32\ntdll.dll:7726B3C8 RtlInitializeExceptionChain
Quote from: kimp on April 22, 2012, 08:40:27 AM
CB + TortoiseSVN: CB crashes when I choose project folder in File Explorer (win 7, Tortoise 1.7 build r22413)
Shall we use our magic balls to know the steps to reproduce? Mine is broken, sorry.
Look: I have another tool, when I press a button in C::B it crashes - can you help me with that information provided? >:(
I'm sorry. C::B crashes if "View->SVN decorators" is selected
ollydbg, I found source of the problem. C::B after upgrades "lost" pyton gdb scripts. If pyton gdb properly tuned, "set print elements 100" in config works.
I confirm something strange with this nighlty. When opening large source files (> 10.000 lines) or switching from one to an other using the tabs it is very slow.
Latest build I'm using is 7789 and this doesn't occur.
Disable the TODO plugin and it will be fast again.
Indeed, thanks.
Hi,
I debug my code in build (7932) but codeblocks freezed.
std::vector<_int> out;
std::vector<_int> in;
in.resize(num.length());
for(;i<num.length();++i) // when debugger going into this line, codeblocks freezed.
in[i] = num[i]-'0';
out.resize(num.length());
num was defined as a string with 100000 chars. I tried to shrink num into 10000 or so then it needed 2 minutes to get the result. It is so slow to debug a large data.
hooluupog: Read few post about about "set print elements"
Quote from: oBFusCATed on April 23, 2012, 04:23:16 PM
hooluupog: Read few post about about "set print elements"
Thanks for your reply. I tried again,when I delete all watches and it works well. But after i added "out" or "in" into watches the codeblocks freezed when runing into that line(see my code in #43).
Hm, I've should written "above about" not "about about".
I don't know what #43 and I don't know how to answer you.
Quote from: oBFusCATed on April 23, 2012, 04:48:29 PM
Hm, I've should written "above about" not "about about".
I don't know what #43 and I don't know how to answer you.
Sorry for my poor english. My code is as follows:
std::vector<_int> out;
std::vector<_int> in;
in.resize(num.length());
for(;i<num.length();++i) // I added 'out' into watches and when debugger going into this line, codeblocks freezed 2 minutes or so before continue
debuggin next line. But it works well after i delete 'out' from watches.
in[i] = num[i]-'0';
out.resize(num.length());I have read gdb "set print elements", i just don't know where to do it within codeblocks. Various info--->Print Elements --->change the value from 'ulimited' into '50', it doesn't work.
You should put it in the initial commands of the gdb in the Settings -> Debugger.
Various info--->Print Elements worked last time, if you provide self contained example I can try it.
Quote from: oBFusCATed on April 23, 2012, 05:51:52 PM
You should put it in the initial commands of the gdb in the Settings -> Debugger.
Various info--->Print Elements worked last time, if you provide self contained example I can try it.
Ok,here is my example code.
#include <vector>
#include <string>
#include <iostream>
using namespace std;
int main()
{
freopen("data.in","r",stdin);//data.in is a file with long characters(100000 chars or so)
string s;
cin>>s;
vector<int> in; //if adding 'in' into watches codeblocks will freeze even if set the print limits at Various info--->Print Elements
in.resize(s.length());
for(int i=0;i<(int)s.length();++i)
in[i] = s[i]-'0';
return 0;// If nothing was added into watches, debugger would stop here with a black screen terminal.I clicked the "stop debug" button but
// it doesn't work. The debugger output log is "Trying to pause the running process... Continuing..."
// At last i have to exit my application by killing its process from windows task manager.
}
Thank you for CodeBlocks!.I have set up a portable version with Biplap's CBlauncher and MS C++ 2008 compiler from a SDK and downloaded MS cdb debugger via a Windows 7 SDK. After copying the Microsoft SDKs ,Microsoft Visual Studio 9.0 and Debugging Tools for Windows(x86) folders to the CodeBlocks folder on the USB stick and setting paths with $(CODEBLOCKS) the portable setup works fine with a running debugger with the 10.05 ver. of CodeBlocks. Unfortunately I am not able to get this april 2012 nightly build to recognize the cdb debugger, although additional paths are set in the same way under toolchain executables as in ver. 10.05. In the toolchain setup dialog (with Microsoft c++ 2005/2008 selected as compiler) the c++ compiler, linker etc. are recognised, but say --invalid debugger-- when coming to cdb.exe. I could have messed something up, or this could be a thing needing attention.Unfortunately I cannot contribute myself as not coder at all. Thank you again
Create new debugger configuration in Settings -> Debugger and then choose it in the compiler's toolchain settings
Perfect, just what was needed, works on the portable setup. Thanks a lot.
I can no longer close the files opened in the editor with a middle mouse click on its tab. It works on rev7790 and before.
OS: Win 7 x64
I've been a fan of Code::Blocks for quite a while now, but I did have a couple observations:
When I did a rebuild of projects in older versions of Code::Blocks (like the 10-30-11 nightly), it seemed to compile the project's files in alphabetical order. They seem to compile in random order now, was there a change that caused this?
When I load up a project, have no files open and bring up the "Find in files" feature via the menu or the keyboard shortcut, the dialog window opens up with the "Find" tab activated and no fields displayed. I can manually change to the "Find in files" tab, but if I have at least one file open, launching "find in files" brings up the dialog with the "Find in files" tab opened as expected. This is different from previous nightlies I've used (such as the 2-11-12 debugger nightly), where the "Find" tab is removed completely from the dialog if no files are opened for editing.
When I changed from the 10-30-11 to the 2-11-12 nightly, I liked the changes with the watches window, especially being able to quickly dereference pointers, or add a "complex" watch (ie. a specific member of a structure variable) by highlighting it in the code and right clicking on it as opposed to copying and pasting. With 2-11-12 as well as this nightly, I'm seeing that when I start a new debugging session, the column widths I set on the watches window are destroyed and I have to correct them to my liking with the mouse. It does seem like Code::Blocks would be better if it left the columns alone, but until that functionality gets added, is there a way I can get the column widths to be permanent, such as by editing a config file?
Thanks in advance for your help, and let me know if I should open bugs for these on the bug tracker.
Quote from: raynebc on April 25, 2012, 08:25:02 PM
...With 2-11-12 as well as this nightly, I'm seeing that when I start a new debugging session, the column widths I set on the watches window are destroyed and I have to correct them to my liking with the mouse...
This is not a feature, but a random bug I can't reliably reproduce.
I'll be happy to fix it, if someone is able to find the exact steps, that are needed to reproduce this bug.
If you restart Codeblocks, the columns will stop getting resized with every new debugging session (until the next time you are hit by the bug, of course).
Quote from: oBFusCATed on April 25, 2012, 08:39:26 PMIf you restart Codeblocks, the columns will stop getting resized with every new debugging session (until the next time you are hit by the bug, of course).
I can't find a way to reproduce it on demand either.
Quote from: scarphin on April 25, 2012, 11:05:21 AM
I can no longer close the files opened in the editor with a middle mouse click on its tab. It works on rev7790 and before.
OS: Win 7 x64
This should be fixed in svn r7943.
Thanks for reporting.
I also recognized it, but thought it was a problem with my mouse.
I've built Code::Blocks SVN 7945:
Code::Blocks SVN 7945 GCC 4.7.0 32-bit Windows (http://www.mediafire.com/?rv8yjdyp8psjhgj) (This build is bad).
Using GCC 4.7.0 on Windows (MinGW-Builds (http://sourceforge.net/projects/mingwbuilds/)). The "-fpermissive" compilation option is used throughout. It is a 32-bit build.
The very first time I built it, it was SVN 7944, and I had to skip "NassiShneiderman" from building in the "ContribPlugins.workspace" project as it errored out.
Now, with SVN 7945, I also had to skip "Tools Plus Plugin" from building in the same workspace as it now also errored out.
As given, the above build with those two plugins skipped appears to work fine.
I'm new both to C::B and C++ in general. With that, is there anything I can do towards resolving those two build issues as above?
Quote from: headkase on April 27, 2012, 04:10:49 PM
I'm new both to C::B and C++ in general.
You are a brave man to use the latest and greatest (buggiest) compiler to compile some random code on the net.
The minimal way you can help us is by providing the full build log. The better is if you can find why the errors are happening,
but I guess this will be a tough job for a c++ beginner.
Quote from: oBFusCATed on April 27, 2012, 04:21:48 PM
Quote from: headkase on April 27, 2012, 04:10:49 PM
I'm new both to C::B and C++ in general.
You are a brave man to use the latest and greatest (buggiest) compiler to compile some random code on the net.
The minimal way you can help us is by providing the full build log. The better is if you can find why the errors are happening,
but I guess this will be a tough job for a c++ beginner.
Ok, I'm pretty sure I've tracked it down. However, I don't know if the issue exists in my GCC 4.7.0 or if the issue exists in the build scripts of Code::Blocks SVN 7945.
Compiling C::B SVN 7945
with SVN 7945, there is a linker error (big wall of text):
-------------- Build: default in Tools Plus Plugin (compiler: GNU GCC Compiler)---------------
Compiling: ToolsPlus.cpp
In file included from ..\..\..\include/sdk_common.h:43:0,
from ..\..\..\include/sdk.h:14,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\ToolsPlus.h:20,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\ToolsPlus.cpp:1:
..\..\..\include/prep.h:32:1: warning: identifier 'nullptr' is a keyword in C++11 [-Wc++0x-compat]
Compiling: ShellCtrlBase.cpp
In file included from ..\..\..\include/sdk_common.h:43:0,
from ..\..\..\include/sdk.h:14,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\ShellCtrlBase.h:16,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\ShellCtrlBase.cpp:4:
..\..\..\include/prep.h:32:1: warning: identifier 'nullptr' is a keyword in C++11 [-Wc++0x-compat]
Compiling: PipedProcessCtrl.cpp
In file included from ..\..\..\include/sdk_common.h:43:0,
from ..\..\..\include/sdk.h:14,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\PipedProcessCtrl.h:13,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\PipedProcessCtrl.cpp:4:
..\..\..\include/prep.h:32:1: warning: identifier 'nullptr' is a keyword in C++11 [-Wc++0x-compat]
Compiling: CmdConfigDialog.cpp
In file included from ..\..\..\include/sdk_common.h:43:0,
from ..\..\..\include/sdk.h:14,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\ToolsPlus.h:20,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\CmdConfigDialog.cpp:18:
..\..\..\include/prep.h:32:1: warning: identifier 'nullptr' is a keyword in C++11 [-Wc++0x-compat]
Compiling: shellproperties.cpp
In file included from ..\..\..\include/sdk_common.h:43:0,
from ..\..\..\include/sdk.h:14,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\shellproperties.h:13,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\shellproperties.cpp:1:
..\..\..\include/prep.h:32:1: warning: identifier 'nullptr' is a keyword in C++11 [-Wc++0x-compat]
Compiling: se_globals.cpp
In file included from ..\..\..\include/sdk_common.h:43:0,
from ..\..\..\include/sdk.h:14,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\se_globals.h:10,
from E:\Data\CB_Build\CB\trunk\src\plugins\contrib\ToolsPlus\se_globals.cpp:1:
..\..\..\include/prep.h:32:1: warning: identifier 'nullptr' is a keyword in C++11 [-Wc++0x-compat]
Linking dynamic library: ..\..\..\devel\share\codeblocks\plugins\ToolsPlus.dll
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla6CreateEP8wxWindowiRK7wxPointRK6wxSizelRK8wxString':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:182: undefined reference to `__imp___ZN9wxControl6CreateEP8wxWindowiRK7wxPointRK6wxSizelRK11wxValidatorRK8wxString'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:184: undefined reference to `__imp___Z17wxSafeShowMessageRK8wxStringS1_'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:195: undefined reference to `__imp___Z17wxSafeShowMessageRK8wxStringS1_'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:197: undefined reference to `__imp___ZN11wxStopWatch5StartEl'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla18MarkerDefineBitmapEiRK8wxBitmap':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:653: undefined reference to `__imp___ZN20wxMemoryOutputStreamC1EPvj'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:654: undefined reference to `__imp___ZNK8wxBitmap14ConvertToImageEv'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:656: undefined reference to `__imp___ZN7wxImage18ConvertAlphaToMaskEh'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:657: undefined reference to `__imp___ZNK7wxImage8SaveFileER14wxOutputStreami'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:658: undefined reference to `__imp___ZNK12wxStreamBase7GetSizeEv'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:660: undefined reference to `__imp___ZNK20wxMemoryOutputStream6CopyToEPvj'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:663: undefined reference to `__imp___ZN20wxMemoryOutputStreamD1Ev'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:663: undefined reference to `__imp___ZN20wxMemoryOutputStreamD1Ev'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla13RegisterImageEiRK8wxBitmap':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:1265: undefined reference to `__imp___ZN20wxMemoryOutputStreamC1EPvj'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:1266: undefined reference to `__imp___ZNK8wxBitmap14ConvertToImageEv'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:1268: undefined reference to `__imp___ZN7wxImage18ConvertAlphaToMaskEh'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:1269: undefined reference to `__imp___ZNK7wxImage8SaveFileER14wxOutputStreami'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:1270: undefined reference to `__imp___ZNK12wxStreamBase7GetSizeEv'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:1272: undefined reference to `__imp___ZNK20wxMemoryOutputStream6CopyToEPvj'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:1275: undefined reference to `__imp___ZN20wxMemoryOutputStreamD1Ev'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:1275: undefined reference to `__imp___ZN20wxMemoryOutputStreamD1Ev'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla12StyleSetSpecEiRK8wxString':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4223: undefined reference to `__imp___ZN17wxStringTokenizerC1ERK8wxStringS2_21wxStringTokenizerMode'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4225: undefined reference to `__imp___ZN17wxStringTokenizer12GetNextTokenEv'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4224: undefined reference to `__imp___ZNK17wxStringTokenizer13HasMoreTokensEv'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla12StyleGetFontEi':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4264: undefined reference to `__imp___ZN6wxFont12SetPointSizeEi'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4265: undefined reference to `__imp___ZN6wxFont11SetFaceNameERK8wxString'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4267: undefined reference to `__imp___ZN6wxFont9SetWeightEi'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4269: undefined reference to `__imp___ZN6wxFont9SetWeightEi'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4272: undefined reference to `__imp___ZN6wxFont8SetStyleEi'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4274: undefined reference to `__imp___ZN6wxFont8SetStyleEi'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla8SaveFileERK8wxString':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4468: undefined reference to `__imp__wxConvCurrent'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla8LoadFileERK8wxString':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4488: undefined reference to `__imp___ZNK6wxFile6LengthEv'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4494: undefined reference to `__imp___ZN6wxFile4ReadEPvj'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4497: undefined reference to `__imp__wxConvCurrent'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4497: undefined reference to `__imp___ZN8wxStringC1EPKcRK8wxMBConvj'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla7OnPaintER12wxPaintEvent':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4671: undefined reference to `__imp___ZN9wxPaintDCC1EP8wxWindow'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4674: undefined reference to `__imp___ZN9wxPaintDCD1Ev'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4674: undefined reference to `__imp___ZN9wxPaintDCD1Ev'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla8OnScrollER13wxScrollEvent':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4687: undefined reference to `__imp___ZN11wxScrollBar12ms_classInfoE'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla15OnMouseLeftDownER12wxMouseEvent':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4708: undefined reference to `__imp___ZNK11wxStopWatch4TimeEv'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla13OnMouseLeftUpER12wxMouseEvent':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4721: undefined reference to `__imp___ZNK11wxStopWatch4TimeEv'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN11wxScintilla12OnMouseWheelER12wxMouseEvent':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4761: undefined reference to `__imp___ZNK11wxStopWatch4TimeEv'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:4767: undefined reference to `__imp___ZNK11wxStopWatch4TimeEv'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `_ZN16wxScintillaEventC2Eii':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:5093: undefined reference to `__imp___ZN14wxCommandEventC2Eii'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `__static_initialization_and_destruction_0':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:80: undefined reference to `__imp___Z14wxNewEventTypev'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:81: undefined reference to `__imp___Z14wxNewEventTypev'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:82: undefined reference to `__imp___Z14wxNewEventTypev'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:83: undefined reference to `__imp___Z14wxNewEventTypev'
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:84: undefined reference to `__imp___Z14wxNewEventTypev'
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o):E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:85: more undefined references to `__imp___Z14wxNewEventTypev' follow
..\..\..\devel/libwxscintilla_cb.a(wxscintilla.o): In function `__static_initialization_and_destruction_0':
E:/Data/CB_Build/CB/trunk/src/sdk/wxscintilla/src/wxscintilla.cpp:121: undefined reference to `__imp___ZN8wxWindow13sm_eventTableE'
Process terminated with status 1 (0 minutes, 18 seconds)
50 errors, 6 warnings (0 minutes, 18 seconds)
Anyway, while building the parent C::B project (CodeBlocks.cbp) with SVN 7945 there is this error message:
Unable to resolve 1 external dependencies:
\devel\libcodeblocks.a
This file is NOT in devel, but it IS in the parent folder, src.
Building the entire project using SVN 7932: the "libcodeblocks.a" file DOES get correctly placed into \devel AND then entire project, CodeBlocks.cbp AND ContribPlugins.workspace ALL compile successfully.
It is only when then building SVN 7945 again using SVN 7945 that libcodeblocks.a doesn't end up in the correct location and later on this causes a linking error.
So, there are two possibilities: either the GCC 4.7.0 I'm using has a regression for handling files, OR the SVN 7945 build scripts/file handling code has a regression. I don't know which. However, I'm leaning towards the SVN 7945 being the regression as using SVN 7932 to build the complete project I am still using my system's GCC 4.7.0 as well.
headkase:
Have you built c::b before using compiler known to work?
Gcc 4.5 for example?
Also have you build wxWidgets with the same compiler you're trying to build c::b.
This is pretty important!
btw: What is your final goal? To contribute to C::B? Write a plugin? To test yourself if you can build c::b?
I've only tried to build C::B using GCC 4.7.0 as I linked before. I built wx using the exact same compiler. wx I had to use the
CXXFLAGS ?= -fno-keep-inline-dllexport
flag in config.gcc as the linker ran out of memory without it. Other than that wx was compiled exactly as given on the wiki (http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows).
So, no known "good" compile with another compiler.
If nothing obvious stands out to you in SVN 7945 however then I am willing to go get another compiler and repeat the entire process, wx and up. However, if you would like me to do this I would likely not have results until Monday - I'm working over the weekend so it's just a matter of free time.
Edit: My eventual goal? To have the most current version of C::B at all times! Mwhahahahahaha. ;)
Edit2: If you would like me to try another compiler, please link to it!
Then why don't you use the nightlies? If you feel there is no new nightly for a long time you can bug us :)
Quote from: oBFusCATed on April 27, 2012, 10:58:31 PM
Then why don't you use the nightlies? If you feel there is no new nightly for a long time you can bug us :)
;) I'm hoping there will we a 12.05 release soon.. :P Most Linux distributions only package the latest stable releases, just sayin', .. :)
Anyway, I'm doing it really because I can. Please link to me another compiler if you like and I will definitely try it. If there is a regression in this GCC 4.7.0 I'm using I'd like to know sooner rather than banging my head against a wall later saying "Why you no work!!!!?" :)
Search for GCC TDM.
Quote from: oBFusCATed on April 27, 2012, 11:16:16 PM
Search for GCC TDM.
Ok, will do (http://tdm-gcc.tdragon.net/): won't be until Monday though until I post results.
Quote from: oBFusCATed on April 27, 2012, 11:16:16 PM
Search for GCC TDM.
Ok, I uninstalled GCC 4.7.0 and installed TDM GCC 4.6.1 32-bit (http://tdm-gcc.tdragon.net/).
Built wxWidgets 2.8.12 Unicode from scratch, as directed exactly by the wiki, with TDM GCC.
Renamed AppData/Roaming/CodeBlocks to give default environment.
Launched Code::Blocks SVN 7932. TDM GCC detected.
Built Code::Blocks SVN 7945 using Code::Blocks SVN 7932. Build successful, both project and plugins.
Renamed AppData/Roaming/CodeBlocks to give default environment.
Launched Code::Blocks SVN 7945. TDM GCC detected.
Initiated Build of CodeBlocks.cbp using Code::Blocks SVN 7945 as built in previous step. All targets returned this error:
"WARNING: Target 'Code::Blocks wx2.8.x - XP look & feel': Unable to resolve 1 external dependencies:
devel\libcodeblocks.a"
(Last targets error message given as the example)
This is same error as when building with GCC 4.7.0.
For both builds started with a completely fresh source tree. Deleted the previous builds source tree and restored an untouched SVN 7945 source tree for each build attempt.
"libcodeblocks.a" exists in parent folder of devel (src), not devel. Link errors ensue. Ball's in your court, what would you like to do next?
Edit: and "libcodeblocks.a" does not exist in src until the build of CodeBlocks.cbp is initiated.
Edit2: didn't mention it but the "NassiShneiderman" plugin requires Boost. Boost 1.49 used and no issues building that plugin with SVN 7932.
@headkase:
Did you delete the pre-compiled header(PCH) files (*.gch)?
Any time you have a Code::Blocks build issues that the normal things do not fix I try that.
Note: Deleting the Code::Blocks source tree should have deleted the PCH files.
Are you positive your are building the CB "all" target?
Did you remember to run update.bat after building the Code::Blocks project?
Tim S.
Quote from: stahta01 on April 28, 2012, 03:13:46 AM
Did you delete the pre-compiled header(PCH) files (*.gch)?
Any time you have a Code::Blocks build issues that the normal things do not fix I try that.
Note: Deleting the Code::Blocks source tree should have deleted the PCH files.
Are you positive your are building the CB "all" target?
Tim S.
I would assume so. I kept the build that successfully built and found some .gch files here: E:\Data\Development\CB.old\trunk\src\.objs\include
The new build, with SVN 7945, was done in a different CB folder. Both CB folders came from an archive which was the svn checkout *untouched*. So, if any of those files exist within "trunk" of the svn checkout then yes, they were nuked as the trunk was not reused between build attempts. As stated I also started with a default environment with each build of C::B. Besides the trunk and the user-specific configuration files - which are both accounted for - then where else would the precompiled headers exist?
Yes, I built the all target. I built both attempts exactly the same.
Edit: I can't include the complete build log as it makes this post exceed 20000 characters. However, it is all basically "libcodeblocks.a" not found in \devel
Quote from: headkase on April 28, 2012, 02:02:09 AM
"libcodeblocks.a" exists in parent folder of devel (src), not devel. Link errors ensue.
I can confirm that libcodeblocks.a and libwxpropgrid.a are place in the source folder when compiling with self compiled CB 7945
Note: The codeblocks.dll and libwxscintilla_cb.a was placed in devel folder.
Tim S.
Quote from: stahta01 on April 28, 2012, 03:42:06 AM
Quote from: headkase on April 28, 2012, 02:02:09 AM
"libcodeblocks.a" exists in parent folder of devel (src), not devel. Link errors ensue.
I can confirm that libcodeblocks.a and libwxpropgrid.a are place in the source folder when compiling with self compiled CB 7945
Note: The codeblocks.dll was placed in devel folder.
Tim S.
So, it looks like there are something wrong between rev7945 and rev7932. Especially, rev7945 generate the dll/a file to a wrong place.
Maybe, this is the cause of this regression:
Quote
Commit:3db06060fddd327c867bc404ab3ff2a4e99a2805
* * save/load dynamic link library lib name and def file into project file -> *backward compatible* change in project file
git-svn-id: svn://svn.berlios.de/codeblocks/trunk@7940 98b59c6a-2706-0410-b7d6-d2fa1a1880c9
src/sdk/compiletargetbase.cpp | 6 +++---
src/sdk/projectloader.cpp | 23 +++++++++++++++++++++--
src/wxsmith/debuggersettingspanel.wxs | 3 +--
3 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/src/sdk/compiletargetbase.cpp b/src/sdk/compiletargetbase.cpp
index 9a47037..2c099d9 100644
--- a/src/sdk/compiletargetbase.cpp
+++ b/src/sdk/compiletargetbase.cpp
@@ -61,7 +61,7 @@ void CompileTargetBase::GetTargetFilenameGenerationPolicy(TargetFilenameGenerati
{
prefixOut = m_PrefixGenerationPolicy;
extensionOut = m_ExtensionGenerationPolicy;
-} // end of GetTargetFilenameGenerationPolicy
+}
const wxString& CompileTargetBase::GetFilename() const
{
@@ -100,7 +100,7 @@ void CompileTargetBase::SetImportLibraryFilename(const wxString& filename)
{
if (filename.IsEmpty())
{
- m_ImportLibraryFilename = _T("$(TARGET_NAME)");
+ m_ImportLibraryFilename = _T("lib$(TARGET_OUTPUT_BASENAME).a");
SetModified(true);
return;
}
@@ -114,7 +114,7 @@ void CompileTargetBase::SetDefinitionFileFilename(const wxString& filename)
{
if (filename.IsEmpty())
{
- m_DefinitionFileFilename = _T("$(TARGET_NAME)");
+ m_DefinitionFileFilename = _T("$(TARGET_OUTPUT_BASENAME).def");
SetModified(true);
return;
}
diff --git a/src/sdk/projectloader.cpp b/src/sdk/projectloader.cpp
index 5c5207f..491d9ce 100644
--- a/src/sdk/projectloader.cpp
+++ b/src/sdk/projectloader.cpp
@@ -527,6 +527,8 @@ void ProjectLoader::DoBuildTargetOptions(TiXmlElement* parentNode, ProjectBuildT
bool use_console_runner = true;
wxString output;
+ wxString imp_lib;
+ wxString def_file;
wxString working_dir;
wxString obj_output;
wxString deps_output;
@@ -560,6 +562,12 @@ void ProjectLoader::DoBuildTargetOptions(TiXmlElement* parentNode, ProjectBuildT
if (node->Attribute("output"))
output = UnixFilename(cbC2U(node->Attribute("output")));
+ if (node->Attribute("imp_lib"))
+ imp_lib = UnixFilename(cbC2U(node->Attribute("imp_lib")));
+
+ if (node->Attribute("def_file"))
+ def_file = UnixFilename(cbC2U(node->Attribute("def_file")));
+
if (node->Attribute("prefix_auto"))
prefixPolicy = atoi(node->Attribute("prefix_auto")) == 1 ? tgfpPlatformDefault : tgfpNone;
@@ -649,6 +657,8 @@ void ProjectLoader::DoBuildTargetOptions(TiXmlElement* parentNode, ProjectBuildT
target->SetTargetFilenameGenerationPolicy(prefixPolicy, extensionPolicy);
target->SetTargetType((TargetType)type); // type *must* come before output filename!
target->SetOutputFilename(output); // because if no filename defined, one will be suggested based on target type...
+ target->SetImportLibraryFilename(imp_lib);
+ target->SetDefinitionFileFilename(def_file);
target->SetUseConsoleRunner(use_console_runner);
if (!working_dir.IsEmpty())
target->SetWorkingDir(working_dir);
@@ -1166,9 +1176,13 @@ bool ProjectLoader::ExportTargetAsProject(const wxString& filename, const wxStri
if (extensionPolicy == tgfpPlatformDefault)
{
wxFileName fname(outputFileName);
- fname.ClearExt();
- outputFileName = fname.GetFullPath();
+ if (fname.HasExt())
+ {
+ fname.ClearExt();
+ outputFileName = fname.GetFullPath();
+ }
}
+
if ( (prefixPolicy == tgfpPlatformDefault)
&& ( (!platform::windows && target->GetTargetType() == ttDynamicLib)
|| (target->GetTargetType() == ttStaticLib) ) )
@@ -1195,6 +1209,11 @@ bool ProjectLoader::ExportTargetAsProject(const wxString& filename, const wxStri
}
TiXmlElement* outnode = AddElement(tgtnode, "Option", "output", outputFileName);
+ if (target->GetTargetType() == ttDynamicLib)
+ {
+ outnode->SetAttribute("imp_lib", cbU2C(target->GetDynamicLibImportFilename()));
+ outnode->SetAttribute("def_file", cbU2C(target->GetDynamicLibDefFilename()));
+ }
outnode->SetAttribute("prefix_auto", prefixPolicy == tgfpPlatformDefault ? "1" : "0");
outnode->SetAttribute("extension_auto", extensionPolicy == tgfpPlatformDefault ? "1" : "0");
diff --git a/src/wxsmith/debuggersettingspanel.wxs b/src/wxsmith/debuggersettingspanel.wxs
index 1ca329f..0e5a02d 100644
--- a/src/wxsmith/debuggersettingspanel.wxs
+++ b/src/wxsmith/debuggersettingspanel.wxs
@@ -41,11 +41,10 @@
<label>Info</label>
<object class="sizeritem">
<object class="wxTextCtrl" name="ID_TEXTCTRL_INFO" variable="textInfo" member="no">
- <value>Text</value>
<size>186,243</size>
<enabled>0</enabled>
</object>
- <flag>wxALL|wxEXPAND|wxALIGN_LEFT|wxALIGN_BOTTOM</flag>
+ <flag>wxEXPAND|wxALIGN_LEFT|wxALIGN_BOTTOM</flag>
<border>5</border>
<option>1</option>
</object>
Whew. It's nice to be a "correct" n00b instead of a "wrong" n00b. I'll let you wizards duke it out now and try to build again when a new SVN is out! :D
Here
if (extensionPolicy == tgfpPlatformDefault)
{
wxFileName fname(outputFileName);
- fname.ClearExt();
- outputFileName = fname.GetFullPath();
+ if (fname.HasExt())
+ {
+ fname.ClearExt();
+ outputFileName = fname.GetFullPath();
+ }
}
Do we need a "else" like:
if (extensionPolicy == tgfpPlatformDefault)
{
wxFileName fname(outputFileName);
if (fname.HasExt())
{
fname.ClearExt();
outputFileName = fname.GetFullPath();
}
else
......
}
because the old logic is:
if (extensionPolicy == tgfpPlatformDefault)
{
wxFileName fname(outputFileName);
fname.ClearExt();
outputFileName = fname.GetFullPath();
}
??
Quote from: ollydbg on April 28, 2012, 04:11:46 AM
??
Nope, this slipped in by accident as it seems. The correct way would be:
if (extensionPolicy == tgfpPlatformDefault)
{
wxFileName fname(outputFileName);
if (fname.HasExt()) fname.ClearExt();
outputFileName = fname.GetFullPath();
}
Sorry for that, I am playing with that feature and this snippet was not supposed to be committed. Will fix...
Build issue still exists in SVN 7948.
Quote from: headkase on April 28, 2012, 06:32:55 PM
Build issue still exists in SVN 7948.
I can confirm that this issue still exists in rev 7948. :(
@morten:
@@ -100,7 +100,7 @@ void CompileTargetBase::SetImportLibraryFilename(const wxString& filename)
{
if (filename.IsEmpty())
{
- m_ImportLibraryFilename = _T("$(TARGET_NAME)");
+ m_ImportLibraryFilename = _T("lib$(TARGET_OUTPUT_BASENAME).a");
SetModified(true);
return;
}
@@ -114,7 +114,7 @@ void CompileTargetBase::SetDefinitionFileFilename(const wxString& filename)
{
if (filename.IsEmpty())
{
- m_DefinitionFileFilename = _T("$(TARGET_NAME)");
+ m_DefinitionFileFilename = _T("$(TARGET_OUTPUT_BASENAME).def");
SetModified(true);
return;
}
I believe this cause the issue.
I have debugged how the link command was generated, and found that:
switch (target->GetTargetType())
{
case ttDynamicLib:
{
TargetFilenameGenerationPolicy PrefixPolicy;
TargetFilenameGenerationPolicy ExtensionPolicy;
target->GetTargetFilenameGenerationPolicy(PrefixPolicy, ExtensionPolicy);
wxString importLibraryFileNameString(target->GetDynamicLibImportFilename());
Manager::Get()->GetMacrosManager()->ReplaceMacros(importLibraryFileNameString, target);
wxFileName importLibraryFileName(importLibraryFileNameString);
// apply prefix if needed
if ( (PrefixPolicy == tgfpPlatformDefault)
&& !importLibraryFileName.GetName().StartsWith(compiler->GetSwitches().libPrefix) )
importLibraryFileName.SetName(compiler->GetSwitches().libPrefix + importLibraryFileName.GetName());
// apply extension if needed
if (ExtensionPolicy == tgfpPlatformDefault)
{
wxString current_ext = importLibraryFileName.GetExt();
wxString requested_ext = compiler->GetSwitches().libExtension;
if (!current_ext.IsSameAs(requested_ext, false))
importLibraryFileName.SetFullName(importLibraryFileName.GetFullName() + wxFILE_SEP_EXT + requested_ext);
}
result = UnixFilename(importLibraryFileName.GetFullPath());
QuoteStringIfNeeded(result);
FixPathSeparators(compiler, result);
m_StaticOutput[target] = result;
Here, the target is sdk, and I see the importLibraryFileNameString is "lib$(TARGET_OUTPUT_BASENAME).a", which finally becomes "libcodeblocks.a", and finally the command generator have such code:
"g++.exe -shared -Wl,--output-def=$def_output -Wl,--out-implib=$static_output -Wl,--dll -Lbase\\tinyxml -LE:\\code\\cb\\wxWidgets-2.8.12\\lib\\gcc_dll -Ldevel -Lsdk\\scripting\\lib -Lsdk\\propgrid .objs\\sdk\\co"...
and the value $static_output is replaced by "libcodeblocks.a", but it should be "devel\libcodeblocks.a" before rev7940.
BTW:
When debugging, I found a some code when the command generator try to generate the compile command, but I see for each file, there is always some function call like:
macro.Replace(_T("$static_output"), m_StaticOutput[target]);
The interesting thing is, the value "macro" is always "g++.exe", and I believe it have no change to do a replacement actually. So it just waste some CPU cycles. Any comments.
...should be fixed in SVN now.
Quote from: MortenMacFly on April 29, 2012, 03:37:46 PM
...should be fixed in SVN now.
I can confirm the fix in rev7949. Thanks.
Quote from: ollydbg on April 29, 2012, 04:01:21 PM
Quote from: MortenMacFly on April 29, 2012, 03:37:46 PM
...should be fixed in SVN now.
I can confirm the fix in rev7949. Thanks.
Not fixed for me; I still am getting libcodeblocks.a and libwxpropgrid.a in the src folder instead of the devel folder.
I will try testing it again and see if I get different results.
Edit: I must have edited the codeblocks project file when checking it for causing the problem.
Once, I reverted all my project edits, the issue was fixed.
Tim S.
Using TDM-GCC 4.6.1 32-bit
Using wxWidgets 2.8.12 Unicode
Using Boost 1.49.0
Update SVN checkout to Code::Blocks SVN 7950.
Using SVN 7932 Nightly, build C::B SVN 7950. Build successful, both project and plugins.
Using C::B SVN 7950, as built in previous step, build C::B SVN 7950. Build successful, both project and plugins.
* libcodeblocks.a does get correctly placed into \devel when building with SVN 7950.
* both builds started with an untouched SVN source tree.
* both builds started with a default user-environment (deleted: AppData/Roaming/CodeBlocks).
Gentlemen, thank you: we have the technology.. Again.. ;)
Edit: @stahta01, just checked with a quick build of 7950 project only with 7950: libwxpropgrid.a and libwxscintilla_cb.a are also both present in \devel upon completion of the project build.
can someone check if there's a problem with indentation within nested code blocks please? It does awkward things occasionally. for example, if i type for() and press enter, it does not move the cursor at right; it just places it beneath f character...
stefanos_: As I said in IRC - provide exact steps to reproduce the problem, because it almost works here, but there is no way to reproduce it. For me it happens only once and then it works (for the 'for' example).
After I restarted Code::Blocks, I have tried to reproduce it and unfortunately could not; but it does so once in a while unexpectedly leaving me clueless of why is doing so.
Anyway, I will consider it as "false alarm".
My apologies.
hi,
im working on Win7 32bit and always get this strange error, even if im in admin mode
Linking executable: ..\..\bin\Win32-gcc\My.exe
c:/home/firestarter/dev/sdk/mingw-tdm-4.6.1/bin/../lib/gcc/mingw32/4.6.1-dw2/../../../../mingw32/bin/ld.exe: reopening ..\..\bin\Win32-gcc\My.exe: Permission denied
c:/home/firestarter/dev/sdk/mingw-tdm-4.6.1/bin/../lib/gcc/mingw32/4.6.1-dw2/../../../../mingw32/bin/ld.exe: final link failed: Permission denied
this always! occures after i tested the exe, and is now locked by something, and my guess is CodeBlocks or Windows, theres nothing else im running, no AntiVir etc
EDIT:
i tried 10x to login this forum, but it didnt tell me to enable Cookies.
Check if your program is still running as a zombie.
When a program is running you can not modify it.
ham: Read this - http://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28errors%29#Q:_My_build_fails_in_the_compile.2Flink.2Frun_step_with_a_Permission_denied_error.3F
its definetly code::blocks
my app is returning with 0, theres no process with my name anywhere, but there is still a handle
left with PID 4 --> System that gets killed after a while (like 2min. or so)
furthermore
i also get this error without running the app, just pressing rebuild many times !!! Its not my fault, its CB.
Quote from: jens on April 14, 2012, 10:32:10 PM
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo (http://apt.jenslody.de/).
Jens, I've temporarily installed a Linux for testing (Ubuntu 12.04) and followed the steps as described on your page. But how do I actually install codeblocks itself? You describe how to modify the apt sources list and install your keyring files but then the description stops. In the Ubuntu package manager I only see 10/05 version from ubuntu...?! ::) ???
apt-get update
apt-get install codeblocks
probably :)
Morten, search my posts in this sub forum, there's answers. sent from my phone.
EDIT
See here:
Re: The 11 February 2012 build (7790) DEBUGGER BRANCH version is out. (http://forums.next.codeblocks.org/index.php/topic,15947.msg108943.html#msg108943)
MortenMacFly,
If you have Synaptic (a GUI package manager) installed you can also look under the "Origin" (or very similar) tab, click on his PPA and it'll show just the packages from that.
This is from memory - it's been a while since I used a Debian-derivative.
Did a quick search, yup, origin tab with Synaptic:
http://askubuntu.com/questions/88640/how-can-i-determine-which-software-repositories-are-in-active-use
Quote from: headkase on May 06, 2012, 05:07:17 AM
If you have Synaptic (a GUI package manager) installed you can also look under the "Origin" (or very similar) tab, click on his PPA and it'll show just the packages from that.
Yeah, I know that well. However, in 12/04 things have changed and I don't see the options anymore. Instead you have a freaking "app store" like thing that doesn't show all packages and refuses to install 3rd party ones (not signed).
So on Ubuntu, I am back on the command line. Oh well - how I love Linux... but what the heck - Win8 won't be better...
...meanwhile I've compiled it myself. So no need for Jens' nightly anymore... sorry, Jens. :-)
However, for the devs: You cannot compile C::B from SVN using 10/05 anymore. The import libs are not being generated (only on Linux). Did anymone notice that? That's not nice!
Why would you want to compile c::b on linux using 10.05 in order to just install it?
Autotools is the preferred way, I think, so for me this is not a defect (if it is linux only of course) :)
Quote from: MortenMacFly on May 05, 2012, 09:30:04 AM
Jens, I've temporarily installed a Linux for testing (Ubuntu 12.04) and followed the steps as described on your page. But how do I actually install codeblocks itself? You describe how to modify the apt sources list and install your keyring files but then the description stops. In the Ubuntu package manager I only see 10/05 version from ubuntu...?! ::) ???
Here is how I have done it for a while under Kubuntu (could be bugs since this is from late 2010). Replace "KpackageKit" with whatever the package manager GUI is called now.
I use the repository supported by Jens Lody http://apt.jenslody.de/ . Using this method, upgrades will automatically be made available for download as the repository is updated. Follow the descriptions on that page, add the following repository in KpackageKit, software sources
deb http://apt.jenslody.de/ any main
deb-src http://apt.jenslody.de/ any main
The easiest way to add his public-key to apt's trustdb is to install the package jens-lodydebian-
keyring with your preferred package-manager or with:
$ sudo apt-get update
$ sudo apt-get install jens-lody-debian-keyring
To get the wxWidgets shared libraries used with Code::Blocks, add also to KpackageKit
deb http://apt.wxwidgets.org/ lenny-wx main
and
wget -q http://apt.wxwidgets.org/key.asc -O- | sudo apt-key add -
finally, to install Code::Blocks
$ sudo apt-get install wx-common (optional)
$ sudo apt-get install libwxgtk2.8-dev
$ sudo apt-get install codeblocks
Code::Blocks becomes available under Development in the KDE menu.
As noted, there could be inaccuracies in the above, but it illustrates the main approach.
Quote from: oBFusCATed on May 07, 2012, 08:36:40 PM
Why would you want to compile c::b on linux using 10.05 in order to just install it?
Autotools is the preferred way, I think, so for me this is not a defect (if it is linux only of course) :)
Because you can install 10/05 w/o hassle from the package repo and then the easiest way would be to compile C::B using C::B, of course. ;-)
No, it is not :)
Quote from: oBFusCATed on May 08, 2012, 08:46:02 AM
No, it is not :)
Well autotools is a lot of commands and cryptic errors for me, while C::B is simply the WS open and hit compile. Anyways - the point is, that IMHO it
used to work. I recall doing it like that in older Ubuntu. It seems 10/05 does not generate the import libs correctly under Ubuntu (Linux). I wonder if this is a general error or not. A reason could be the more recent compiler used in this version of Ubuntu. Did somebody try recently?
You're a windows user, linux users are used to autotools...
BTW: What import libraries? There is no such thing in linux, as far as I know.
Quote from: oBFusCATed on May 08, 2012, 09:36:35 AM
You're a windows user, linux users are used to autotools...
Yes, maybe. But we are also developing an IDE that allows for
not using autotools. Its like buying a car but then taking the bicycle to drive to your destination... ::) But hey - as long as I have a way not using autotools I am happy.
Quote from: oBFusCATed on May 08, 2012, 09:36:35 AM
BTW: What import libraries? There is no such thing in linux, as far as I know.
Well I meant the libraries to link against if you prefer. But I guess meanwhile I figured out the cause. 10/05 does not prepend the "lib" prefix tot he libs and therefore they are simply not found by the linker. Adding the lib prefix in the project file would fix it.
So... nevermind.
Quote from: MortenMacFly on May 07, 2012, 08:25:36 PM
Quote from: headkase on May 06, 2012, 05:07:17 AM
If you have Synaptic (a GUI package manager) installed you can also look under the "Origin" (or very similar) tab, click on his PPA and it'll show just the packages from that.
Yeah, I know that well. However, in 12/04 things have changed and I don't see the options anymore. Instead you have a freaking "app store" like thing that doesn't show all packages and refuses to install 3rd party ones (not signed).
So on Ubuntu, I am back on the command line. Oh well - how I love Linux... but what the heck - Win8 won't be better...
I believe what you are using there is the "Software Center." That is a Canonical "innovation" ;) On a terminal you should be able to do:
sudo apt-get install synapticAnd that should get you, the much better IMHO, package manager.
However, grain-of-salt, it's been a while since I've been on Ubuntu - Arch (https://www.archlinux.org/about/) for the win! :D
I was getting big delays too (more than 15 mins) and I correct it deleting the 'C:\Users\XXX\AppData\Roaming\CodeBlocks/share/codeblocks' directory
I hope you find it helps
Quote from: mushakk on May 17, 2012, 09:30:24 PM
I was getting big delays too (more than 15 mins) and I correct it deleting the 'C:\Users\XXX\AppData\Roaming\CodeBlocks/share/codeblocks' directory
It should already been fixed. Try a more recent nightly.