Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw26u_gcc_cb_wx2.6.3p2.7z
To fix the menu alignment bug introduced in wx 2.6.3 [windows only bug] we have patched wx ourselves, and that results in the following alternative dll : http://prdownload.berlios.de/codeblocks/wxmsw26u_gcc_cb_wx2.6.3p2AndCbPatch.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10.7z
For support of ansi builds, a link to the ansi windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw26_gcc_cb_wx2.6.3p2.7z
The 10 January 2007 build is out.
- Windows : http://prdownload.berlios.de/codeblocks/CB_20070110_rev3474_win32.7z
- Linux :
http://prdownload.berlios.de/codeblocks/CB_20070110_rev3474_Ubuntu6.06.deb (not yet)
http://prdownload.berlios.de/codeblocks/CB_20070110_rev3474_suse100+101.i586.rpm (not yet)
http://prdownload.berlios.de/codeblocks/CB_20070110_rev3474_fc4+5.i586.rpm (not yet)
Resolved Fixed:
- UseFlatObjects setting now also saved in the conf
- Scripting updates:
- GetScriptingManager().RegisterScriptMenu() signature changed from (scriptFile, menuPath) to (menuPath, scriptFileOrFunction, (bool)isFunction). This allows registering a script-function (instead of a full script) to a menu. Useful, for example, to create a single script with various functions and bind them all to menus.
- Added IO.GetCwd() and IO.SetCwd() to get/set the working directory.
- Added ProgressDialog script class. Use its single member function Update(value, message) to update it. Value must always lie in the 0-100 range.
- Added ShowDialog(xrcFile, dlgName, callbackFunc) function to load and display a dialog from XRC. The callbackFunc is a script function you define to handle all click-events. While in a ShowDialog() call, there are also the EndModal(retCode) and XRCID(controlName) functions available.
- Wiki docs soon to be updated - Fixed code parser tokenizer bug with concatenation of strings ("" "")
- Updated all windows project files : CB and contrib plugins
- Applied patch for gdb breakpoints (patch #1814). Hopefully it will work in most cases
Regressions/Confirmed/Annoying/Common bugs:
- toolbar-images-not-changing-state (is a wx problem/Win XP problem)
- menu items with icon not correctly aligned (since wx263) (is fixed with our special wx263/wx28 dll)
due to the scripting updates, one of the new files (sc_dialog.cpp) will not compile on linux
@Yiannis : could you ... ;-)
Quote from: killerbot on January 10, 2007, 07:10:02 PM
Regressions/Confirmed/Annoying/Common bugs:
- toolbar-images-not-changing-state (is a wx problem/Win XP problem)
I think I have found and fixed this issue in thread
http://forums.next.codeblocks.org/index.php?topic=4912.msg38326#msg38326
Can someone else confirm the wxWidgets 2.6 patch works for them.
Tim S
Quote from: stahta01 on January 10, 2007, 07:48:03 PM
Quote from: killerbot on January 10, 2007, 07:10:02 PM
Regressions/Confirmed/Annoying/Common bugs:
- toolbar-images-not-changing-state (is a wx problem/Win XP problem)
I think I have found and fixed this issue in thread
http://forums.next.codeblocks.org/index.php?topic=4912.msg38326#msg38326
Can someone else confirm the wxWidgets 2.6 patch works for them.
Tim S
wow so you fixed all regressions/Confirmed/Annoying/Common bugs! :lol:
Quote from: lubos on January 10, 2007, 08:28:05 PM
wow so you fixed all regressions/Confirmed/Annoying/Common bugs! :lol:
This one I claim as a fix, but the last one I just reported on someone else's solution.
Tim S
2 bugs:
1 - like other people have - when C::B is closed, and i double click (in windows os) .cpp source code, C::B opens and blocks acces to folder with this source for about 20seconds - time which it takes to load source. It's the same when i double click in Total Commander or Exporer windows. When 1 instance of C::B is already running, double clicking on .cpp source file works properly.
2- It rarely can open header file, after right clicking at #include part in editor. I think it works, when include file is in actual folder: #include "1.h"
but doesn't when it's in default folder:
#include <iostream>
#include <iomanip>
#include <math.h>
Quote from: Darck on January 10, 2007, 08:59:08 PM
2 bugs:
1 - like other people have - when C::B is closed, and i double click (in windows os) .cpp source code, C::B opens and blocks acces to folder with this source for about 20seconds - time which it takes to load source. It's the same when i double click in Total Commander or Exporer windows. When 1 instance of C::B is already running, double clicking on .cpp source file works properly.
2- It rarely can open header file, after right clicking at #include part in editor. I think it works, when include file is in actual folder: #include "1.h"
but doesn't when it's in default folder:
#include <iostream>
#include <iomanip>
#include <math.h>
1- for me it unblock when i click minimize button in codeblocks
2- hmm i can open it.
i get not found message...
Quote from: killerbot on January 10, 2007, 07:11:52 PM
due to the scripting updates, one of the new files (sc_dialog.cpp) will not compile on linux
@Yiannis : could you ... ;-)
no problems befor 2-3 hours i compile this revision on linux system ;)
I installed vs2005 without the graphic IDE. So the debugger wasn't installed with it.
So I installed WinDbg but it is in a whole new directory... I can't link the cdb.exe program in the compiler and debugger programs tab.
Quote from: Darck on January 10, 2007, 09:20:28 PM
i get not found message...
don't worry, you are not only one :D
Quote from: lubos on January 10, 2007, 09:51:25 PM
Quote from: Darck on January 10, 2007, 09:20:28 PM
i get not found message...
don't worry, you are not only one :D
I don't get what is meant by this??? What was not found? When does this message appear?
With regards, Morten.
Quote from: Darck1 - like other people have - when C::B is closed, and i double click (in windows os) .cpp source code, C::B opens and blocks acces to folder with this source for about 20seconds - time which it takes to load source. It's the same when i double click in Total Commander or Exporer windows. When 1 instance of C::B is already running, double clicking on .cpp source file works properly.
Yup, this one is very strange. A few weeks ago it had no problems opening any file from windows explorer, but since I reinstalled XP it's been occurring.
It's a problem with DDE that just makes no sense. Everything I've tried has failed. I even thought it was a problem with the implementation in wx so I took the wx sample provided by the wizard, added DDE copy&pasting the code used in Code::Blocks, and it works fine there.
BTW, if you open a .c/.h/.hpp/.cpp file from windows explorer when Code::Blocks is closed and then close Code::Blocks (when it has loaded)... does it crash?
Quote from: MortenMacFlyI don't get what is meant by this??? What was not found? When does this message appear?
The header file was not found. They say it appears, in some cases, when you right click on the header name (followed by a #include) in the editor and tell it to open it.
closing C::B after loading works fine. Closing C::B during this 20-30s, when it's loading .cpp file works fine too, but i get message "file not found" (like it's searching this file for 30s). Minimizing doesn't help, like someone said before.
Quote from: Ceniza on January 10, 2007, 10:07:25 PM
Quote from: MortenMacFlyI don't get what is meant by this??? What was not found? When does this message appear?
The header file was not found. They say it appears, in some cases, when you right click on the header name (followed by a #include) in the editor and tell it to open it.
ah so he means opening headers... i mean i get error 'script run error' at cb start. seems everyone have others problems..for me it doesn't save default workspace also... :?
menu project > set programs arguments
> notes
doesn't work, when i have one .c file loaded
you need a project, not just a 1 file, create a project (guess an exe ??) and copy the contents into the main.c
it shouldn't be necessary. At least parameters
Now I get a script running error when starting C::B !!! :shock:
(CB) newbie, with pre-existing mingw installation, trying to build from SVN source.
found nightly install instrucs, tried to follow, with patches
Fetched SVN source
Opened CodeBlocks.cbp, attempted build.
Got complaint from cc1plus.exe, didn't like -Winvalid-pch - found item in options tab somewhere removed.
Tried again, reached tinyxml, where 4 source items were compiled (in earlier attempt), then
and now, get final result of:
Linking static library: sdk\tinyxml\libtxml.a
ar.exe: sdk\tinyxml\libtxml.a: No such file or directory
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
have searched, and can't find libtxml.a, did find four .o's which I guess were supposed to be in it (were built in earlier build run.)
What's wrong? (I saw comments about some fairly recent changes regarding paths and variables - related?)
Thanks.
add'l info after looking more:
tinywxuni.cpp is not shown among attempted compile items for tinyxml although appears in project
From right-click menu, attempt to build, fails to find "wx/setup.h", which is included from "platform.h".
Search of wxwidgets tree finds several wx/.../setup.h files, but none at wx directory tree level...???
don't know what's right, but tried copying wx/msw/setup.h to wx/setup.h, played with global wx var paths, finally got tinywxuni.cpp to compile, but still get same final result above.
...Just found tinywxuni.<cpp,h> are not checked as target files to build, so guess that's not the problem...
Quote from: cbexaminr on January 14, 2007, 04:37:37 AM
(CB) newbie, with pre-existing mingw installation, trying to build from SVN source.
From right-click menu, attempt to build, fails to find "wx/setup.h", which is included from "platform.h".
Search of wxwidgets tree finds several wx/.../setup.h files, but none at wx directory tree level...???
don't know what's right, but tried copying wx/msw/setup.h to wx/setup.h, played with global wx var paths, finally got tinywxuni.cpp to compile, but still get same final result above.
...Just found tinywxuni.<cpp,h> are not checked as target files to build, so guess that's not the problem...
What version of wxWidgets are you using?
Did you compile wxWidgets yourself?
Tim S
Oops... two different pages, just noticed two different links for wxwidgets...
using 2.6.2, compiled by self
(as directed to download and compile at this link:
http://forums.next.codeblocks.org/index.php?topic=1701.0)
but, when I was looking for the page, also found this:
http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows
which tells me 2.6.3 is what is officially supported...
Somebody may want to do something with that first page - its the one I found first...
(I'll fetch the one from the other page and try that - but I would have expected to see some compilation errors, not silent failure?)
Is this likely the problem? Nope...
***Just repeated with wxwidgets-2.6.3-1, with same results as far as I can recall...
Please verify that it compiled right. If it worked right you should have a DLL created in the folder lib\gcc_dll called wxmsw26u_gcc_custom.dll.
Do you see it?
Tim S
for errors that mention jpeg or boolean try this patch
[ 1606032 ] [2.6] jpeg boolean mingw API 3.8 fix backport
http://sourceforge.net/tracker/index.php?func=detail&aid=1606032&group_id=9863&atid=309863
for errors that mention ddraw.h try this work around
DirectX 8.0 headers. Uncompress this over the MinGW directory. Add c:\mingw\bin to your PATH. Compile by typing mingw32-make. (for minGW 3.4.5 ONLY)
http://www.mame.net/zips/dx80_mgw.zip OR download from SF http://alleg.sourceforge.net/files/dx80_mgw.zip
Yes, its there.
9,449,470 wxmsw26u_gcc_custom.dll
Quote from: cbexaminr on January 14, 2007, 04:37:37 AM
Fetched SVN source
You are fetching the source from svn.berlios.de?
Tim S
These bugs and suggestions are not specifically related to this build, but more my remaining gripes with C::B despite the excellent progress it has made over the past year or so.
-This is probably already a known bug, but if in "Current File's Symbols" mode for the class-browser, the symbols don't refresh at all when a new file is opened.
-An option to automatically expand all namespaces in the symbol browser would be nice
-Why on earth does the left-hand menu in the Settings windows use huge (and imo pointless) graphical icons that one must scroll through to get to all of them. Wouldn't simple text be better, so all menu items would be visible at once?
Quote from: Electron on January 14, 2007, 04:12:42 PM
-Why on earth does the left-hand menu in the Settings windows use huge (and imo pointless) graphical icons that one must scroll through to get to all of them. Wouldn't simple text be better, so all menu items would be visible at once?
Try doing this
Settings -> Environment -> View -> "Setting Icons Size" to "No icons, just text"
Tim S
Ah thank you, that fixes one of my issues :)
Quote from: stahta01 on January 14, 2007, 03:22:14 PM
Quote from: cbexaminr on January 14, 2007, 04:37:37 AM
Fetched SVN source
You are fetching the source from svn.berlios.de?
Tim S
used:
svn checkout svn://svn.berlios.de/codeblocks/trunk
per the instructions at:
http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows
Quote from: cbexaminr on January 14, 2007, 04:37:37 AM
Search of wxwidgets tree finds several wx/.../setup.h files, but none at wx directory tree level...???
don't know what's right, but tried copying wx/msw/setup.h to wx/setup.h, played with global wx var paths, finally got tinywxuni.cpp to compile, but still get same final result above.
...Just found tinywxuni.<cpp,h> are not checked as target files to build, so guess that's not the problem...
The setup.h that is supposed to be used is in this path lib\gcc_dll\mswu\wx please remove the one you place at include\wx. Note, sometimes it is required to copy setup0.h to setup.h in folder include\wx\msw if the make of wxWidgets fails to create the file include\wx\msw\setup.h. The make should the copy that setup.h to
lib\gcc_dll\mswu\wx\setup.h. (at least this is how I believe it works from using wxWidgets)
Tim S
cbexaminr:
Please verify that your path does NOT contain any thing that has cc1plus.exe in it. The minGW should be OK, but mine is NOT in my path because I run multiple minGW installs. The most likely cause will be cygwin being in the path.
Tim S
When I changed to the 2.6.3-1 version, I did not have to copy the setup.h, so that didn't apply to the second (main) attempt.
I'm not having the trouble building (2.6.3) wxwidgets...
I am still have the trouble building CodeBlocks, reaching the tinyxml target, as previously noted...
Any other ideas?
[edit]
sorry, I overlooked the request to check for cc1plus elsewhere, will do so...
checked, no it is not in my path....
I guess you're trying to narrow, but the problem I seem to be having appears somehow related to how codeblocks invokes ar.exe, or of a link (ld?) to build libtxml.a... whatever does it, I'm not finding a libtxml.a created anywhere in the build tree...
Quote from: cbexaminr on January 14, 2007, 06:21:17 PM
When I changed to the 2.6.3-1 version, I did not have to copy the setup.h, so that didn't apply to the second (main) attempt.
I'm not having the trouble building (2.6.3) wxwidgets...
I am still have the trouble building CodeBlocks, reaching the tinyxml target, as previously noted...
Any other ideas?
[edit]
sorry, I overlooked the request to check for cc1plus elsewhere, will do so...
checked, no it is not in my path....
I guess you're trying to narrow, but the problem I seem to be having appears somehow related to how codeblocks invokes ar.exe, or of a link (ld?) to build libtxml.a... whatever does it, I'm not finding a libtxml.a created anywhere in the build tree...
My libtxml.a is created perfectly in the folder cbpath\src\sdk\tinyxml. Have you verified the Global variables by using "Settings" -> Global Varaibles
cb should point to cbpath\src
wx should point to wxpath for the correct installation.
Also, please turn on "Compile logging" by doing "Settings" -> "Compiler and Debugger" Tab "Other" Turn "Compile logging" to "Full Command Line".
Tim S
1) My global variables only contain the "wx", not any cb. I tried adding it and making the base refer to cbpath\src, but I still get the same failure.
2)The output after enabling the full command-line logging:
ar.exe -r -s sdk\tinyxml\libtxml.a .objs\2.6\sdk\tinyxml\tinyxml.o .objs\2.6\sdk\tinyxml\tinyxmlerror.o .objs\2.6\sdk\tinyxml\tinyxmlparser.o .objs\2.6\sdk\tinyxml\tinystr.o
ar.exe: sdk\tinyxml\libtxml.a: No such file or directory
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
3)When I execute the command part of above directly from the command prompt from which I invoked codeblocks, I get the same error (see 5 and 6)
4)ar --version:
GNU ar 2.13.90 20030111
5)Looking at the --help and the man page with my cygwin ar (which is a different version from the mingw), ****the format of the command does not appear to follow that outlined in the help/man page...
6)Playing around (lack knowledge of ar) from reading help, ****the command formed as:
ar.exe -rsc sdk\tinyxml\libtxml.a .objs\2.6\sdk\tinyxml\tinyxml.o .objs\2.6\sdk\tinyxml\tinyxmlerror.o .objs\2.6\sdk\tinyxml\tinyxmlparser.o .objs\2.6\sdk\tinyxml\tinystr.o
does create the archive, and going back to codeblocks, it goes on past tinyxml...
7)only to encounter the same "cc1plus.exe : unrecognized option -Winvalid-pch" for squirrel target, which I think I know how to deal with... but why am I getting it? What version of gcc/cc1plus was it introduced in (I have several versions around, and tried at least one other with same results before)? [edit] (I keep not saving the project, and thus that switch comes back...)
8)After again removing -Winvalid-pch, compile squirrel modules, then have same issue creating squirrel library...
9)Is format of ar command technically correct? (Apparently not for my version.) What version of mingw/ar are you running?
Under the codeblocks src folder search for files using *.gch and delete them these are precompiled headers one of them may be corrupted. I just had this happen today when I switched from one compiler to another ( mingw gcc 3.4.2 to 3.4.5)
Tim S
Quote from: cbexaminr on January 15, 2007, 12:55:24 AM
1) My global variables only contain the "wx", not any cb. I tried adding it and making the base refer to cbpath\src, but I still get the same failure.
cb is needed for compiling the contrib packages.
Quote
2)The output after enabling the full command-line logging:
ar.exe -r -s sdk\tinyxml\libtxml.a .objs\2.6\sdk\tinyxml\tinyxml.o .objs\2.6\sdk\tinyxml\tinyxmlerror.o .objs\2.6\sdk\tinyxml\tinyxmlparser.o .objs\2.6\sdk\tinyxml\tinystr.o
ar.exe: sdk\tinyxml\libtxml.a: No such file or directory
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
This can mean that it could NOT find ar.exe, please check your compiler path.
Quote
3)When I execute the command part of above directly from the command prompt from which I invoked codeblocks, I get the same error (see 5 and 6)
4)ar --version:
GNU ar 2.13.90 20030111
I get GNU ar 2.15.91 20040904 for my GCC 3.4.2 installation
I get GNU ar 2.16.91 20060119 for my GCC 3.4.5 installation
What do you get with GCC --version on the command line?
Quote
5)Looking at the --help and the man page with my cygwin ar (which is a different version from the mingw), ****the format of the command does not appear to follow that outlined in the help/man page...
6)Playing around (lack knowledge of ar) from reading help, ****the command formed as:
ar.exe -rsc sdk\tinyxml\libtxml.a .objs\2.6\sdk\tinyxml\tinyxml.o .objs\2.6\sdk\tinyxml\tinyxmlerror.o .objs\2.6\sdk\tinyxml\tinyxmlparser.o .objs\2.6\sdk\tinyxml\tinystr.o
does create the archive, and going back to codeblocks, it goes on past tinyxml...
7)only to encounter the same "cc1plus.exe : unrecognized option -Winvalid-pch" for squirrel target, which I think I know how to deal with... but why am I getting it? What version of gcc/cc1plus was it introduced in (I have several versions around, and tried at least one other with same results before)? [edit] (I keep not saving the project, and thus that switch comes back...)
8)After again removing -Winvalid-pch, compile squirrel modules, then have same issue creating squirrel library...
9)Is format of ar command technically correct? (Apparently not for my version.) What version of mingw/ar are you running?
OK, if I get gcc 3.4.5 with ar 2.15.91, I get to at least scintilla before encountering problems - the "-Winvalid-pch" is apparently handled, and both the tinyxml and squirrel libraries apparently build.
But then i seem to be back to an earlier problem, where platform.h (wxwidgets 2.6.3) attempts to include wx/setup.h, and there is no setup.h at that level!!! (A problem I had with earlier wxwidgets, then thought I didn't with the wxwidgets 2.6.3, but now apparently still do have.)
read rest if interested for rambling journey of what I've found so far...
--------------------------------
ar.exe was being found OK, because I got the same error from the command line as I saw in the CodeBlocks output.
gcc --version for the one I've been using reports:
gcc (GCC) 3.2.3 (mingw special 20030504-1)
which appears to be older than yours... I'll see what the other ones are - I've forgotten...
another gcc --version reports:
gcc (GCC) 3.4.5 (mingw special)
but the ar --version for both of these installations reports:
GNU ar 2.13.90 20030111
so, it appears my problem may be with the version of ar, as yours is apparently much newer... I will pursue this...
But
1)Can someone do something about the two pages (one wiki, one forum) that have at least differences in the links for wxwidgets?
Also
2)My cygwin version of ar is closer to yours, but the cygwin man page does not show support for the command as its apparently being executed by codeblocks, nor does the --help output seem to support that for the older mingw versions I have... But I guess its working for you, I will try to do something with mingw ar to see if I can make that problem go away...
3)Where were the instructions for setting cb variable (I didn't get to plug-in contributor instructions if thats where its mentioned)? I've only seen mention of wx, which original project open prompted for... (Although the instructions about what to feed it were unclear to me, had to play around a bit...)
...later...
found 3.4.2 gcc version, with ar 2.15.91 20040904 version, and still have same issues...
Which of the two versions you mentioned are you using? Are you sure the 3.4.2 with ar 2.15.91 version doesn't fail for you also?
....
Both of my 3.4 versions work great, but it is NOT easy too get more than one copy of minGW to work on a single computer. minGW likes to look in the folder c:\minGW for most things and if that folder exists then it will use it when you don't want it to.
I would update the version of minGW using the new update tool (just release today) MinGW-5.1.3.exe.
I would use the default folder c:\minGW to do the install in.
Note: It is best to NOT use spaces in the patch to minGW. Mine is all under C:\apps\....
Note: To install more than one minGW you must delete the minGW reg entry. I use the reg file below.
REGEDIT4
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\MinGW]
Quote from: stahta01 on January 15, 2007, 05:45:49 AM
I would update the version of minGW using the new update tool (just release today) MinGW-5.1.3.exe.
MinGW-5.1.3.exe Released/available where?
(Don't see at:
http://www.mingw.org/download.shtml
nor at:
http://www.codeblocks.org/downloads.shtml)
[edit]
OK, found it at:
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82721&release_id=158801
But as I view it, it shows zero downloads, which would mean you haven't even tried it yet? :oops:
ok, I just downloaded it, refreshed that page, and download count still shows zero - so I guess stats aren't totally live...
Have you tried MinGW-5.1.3.exe yet?
BTW, thanks for all the responses/help!
Quote from: stahta01 on January 14, 2007, 05:33:32 PM
The setup.h that is supposed to be used is in this path lib\gcc_dll\mswu\wx please remove the one you place at include\wx. Note, sometimes it is required to copy setup0.h to setup.h in folder include\wx\msw if the make of wxWidgets fails to create the file include\wx\msw\setup.h. The make should the copy that setup.h to
lib\gcc_dll\mswu\wx\setup.h. (at least this is how I believe it works from using wxWidgets)
Tim S
(...\lib\gcc_dll\mswu\wx does contain a setup.h)
Does all this mean that the "include" field of the global wx variable should be set to something like "<wxwidgpath>\lib\gcc_dll\mswu"?
OK, played more before posting. Command line from recent attempt is:
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -D__WX__ -DWINVER=0x0400 -DSCI_LEXER -DLINK_LEXERS -DWXMAKINGDLL_SCI -IC:\dlh\dev\wxwidgets\wxWidgets-2.6.3\include
;C:\dlh\dev\wxwidgets\wxWidgets-2.6.3\lib\gcc_dll\mswu -Ilib\gcc_dll\mswu -IC:\dlh\dev\wxwidgets\wxWidgets-2.6.3\contrib\include -Isdk\wxscintilla\include -Isdk\propgrid\include -Isdk\wxscintilla\include -Isdk\wxscintilla\src\scintilla\include -Isdk\wxscintilla\src\scintilla\src -c sdk\wxscintilla\src\PlatWX.cpp -o .objs\2.6\sdk\wxscintilla\src\PlatWX.o
sdk\wxscintilla\src\PlatWX.cpp:9:19: wx/wx.h: No such file or directory
1)How is the bold/no-italics part supposed to find anything? It would mean that would have to be under the codeblocks source tree... correct? Is the wx variable not being appropriately applied to that command line generation, at least for the part in bold/no-italics?
2)I thought "-I" could take more than one path, and tried to put both in the "include" field of the environment variable, and the results are shown above in bold/italics, but preprocessor still failed to find wx/wx.h (and it is there under <wxwidgpath>\include\wx)...
3)I've also tried it with just the single path in the "include" field of the wx global variable, and still get the same compilation results.
And all of this is after installing with mingw-5.1.3.exe... still using the 10-jan-2007 nightly of codeblocks...
to clarify:
<wxwidgpath>\include\wx does _not_ contain a setup.h
<wxwidgpath>\lib\gcc_dll\mswu\wx _does_ contain a setup.h
Code::Blocks compiles if minGW is set up right and wxWidgets was compiled right.
So, Code::Blocks is NOT the issue, but its configuration can be.
I think you need to open up a command prompt and fix the issue with you having too many copies of the commands needed to compile C::B
GCC --version
AR --version
g++ --version
All error out on my setup, it is NOT the only way but it is the safest in my opinion.
You have to fix your PATH so it does NOT have any thing in it related to other GCC installations.
Tim S
Quote from: cbexaminr on January 15, 2007, 10:30:58 AM
ok, I just downloaded it, refreshed that page, and download count still shows zero - so I guess stats aren't totally live...
Have you tried MinGW-5.1.3.exe yet?
BTW, thanks for all the responses/help!
Yes, I like MinGW-5.1.3.exe it is the first one that worked correctly in over a month.
It is possible the installer you used is a large part of your problem.
Tim S
I don't doubt that you are building it. But have you done so with the 10-jan-2007 nightly build??? Or done it again with your CVS-built version, which apparently isn't too different from 10-jan-2007 nightly yet? ( Following the instructions identified below as "most current observed"?)
1) Those last reported attempts were with an installation created by mingw-5.1.3.exe.
2) Unless 5.1.3 made changes earlier installs didn't, gcc, ar, and g++ are not in my path until I follow the instructions for compiling wxwidgets, which tell me to set path as c:\mingw\bin;c:\mingw\mingw32\bin, at which point I do only have the one version in my path.
3) The instructions at:
http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows
go from compiling wxwidgets to opening the codeblocks project, so I move to my "nightly" installation and execute codeblocks.exe (all in same command prompt used to build wxwidgets), where I originally browsed to the source tree containing the project to open it, and but now just re-open it via recent projects menu items.
4) So, A)my mingw installation should be correct unless B)I'm _not_ supposed to have it in the path when codeblocks.exe is invoked...
5) So are there instructions other than the previous ones I've referenced that correctly tell how everything should be set up? I believe I've correctly followed those instructions (although I had to fill in some holes where they weren't quite explicit enough, like some examples of how/which-of the cw global var dlg fields should be filled in, and with what (all absolute paths, some relative, or ?), and you've identified a cb global var not mentioned in the instructions [which I apparently haven't gotten far enough to need yet]).
instruction URLs repeated:
(apparently INcorrect one - http://forums.next.codeblocks.org/index.php?topic=1701.0)
(most current observed - http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows)
you can always try this :
http://wiki.codeblocks.org/index.php?title=Nightly_Cookbook
Quote from: cbexaminr on January 15, 2007, 09:47:24 PM
I2) Unless 5.1.3 made changes earlier installs didn't, gcc, ar, and g++ are not in my path until I follow the instructions for compiling wxwidgets, which tell me to set path as c:\mingw\bin;c:\mingw\mingw32\bin, at which point I do only have the one version in my path.
What directory did you install minGW into?
Unless it was c:\minGW, You must make sure that there is NOT an folder c:\minGW.
Now to test your installation of minGW is done so it will work right with C::B
open an command prompt using Start -> Run "cmd"
at the prompt cd to your minGW bin folder, by doing below if default installation folder used.
CD c:\minGW\bin
Type the following and record versions
mingw32-gcc.exe --version
mingw32-g++.exe --version
windres.exe --version
ar.exe --version
mingw32-make.exe --version
My results are the following
C:\apps\MinGW\bin>mingw32-gcc.exe --version
mingw32-gcc.exe (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
C:\apps\MinGW\bin>mingw32-g++.exe --version
mingw32-g++.exe (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
C:\apps\MinGW\bin>windres.exe --version
GNU windres 2.16.91 20060119
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
C:\apps\MinGW\bin>ar.exe --version
GNU ar 2.16.91 20060119
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
C:\apps\MinGW\bin>mingw32-make.exe --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
C:\apps\MinGW\bin>
Now CD to the root folder by doing
CD c:\
Type the following and record versions
mingw32-gcc.exe --version
mingw32-g++.exe --version
windres.exe --version
ar.exe --version
mingw32-make.exe --version
I get the following which is OK, you can also get the exact same results as what you did for the above test.
C:\>
C:\>mingw32-gcc.exe --version
Access is denied.
C:\>mingw32-g++.exe --version
Access is denied.
C:\>windres.exe --version
Access is denied.
C:\>ar.exe --version
Access is denied.
C:\>mingw32-make.exe --version
Access is denied.
C:\>
What was your results for both tests?
Tim S
Well, my results from installing mingw-5-1.3.exe differ from yours, as below. (The directory listing showing location [c:\mingw\] is at end of block instead of beginning.) The directory did not exist before I performed the installation. (I do have one idea about why they might differ, which I will pursue after I post this.)
mingw32-gcc (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
mingw32-g++ (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
GNU windres 2.15.91 20040904
Copyright 2004 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
GNU ar 2.15.91 20040904
Copyright 2004 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
'mingw32-gcc' is not recognized as an internal or external command,
operable program or batch file.
'mingw32-g++' is not recognized as an internal or external command,
operable program or batch file.
'windres' is not recognized as an internal or external command,
operable program or batch file.
'ar' is not recognized as an internal or external command,
operable program or batch file.
'mingw32-make' is not recognized as an internal or external command,
operable program or batch file.
Volume in drive C has no label.
Volume Serial Number is 0B59-0F3A
Directory of c:\mingw
01/15/2007 04:52 AM <DIR> .
01/15/2007 04:52 AM <DIR> ..
01/15/2007 04:52 AM <DIR> bin
12/18/2000 05:47 PM 17,992 COPYING
01/29/2001 09:30 AM 26,430 COPYING.LIB
01/15/2007 04:51 AM <DIR> doc
01/15/2007 04:52 AM <DIR> include
01/15/2007 04:52 AM <DIR> info
01/15/2007 04:52 AM 418 installed.ini
01/15/2007 04:52 AM <DIR> lib
01/15/2007 04:51 AM <DIR> libexec
01/15/2007 04:51 AM <DIR> man
01/15/2007 04:35 AM 138,705 MinGW-5.1.3.exe
01/15/2007 04:52 AM 46 MinGW.url
01/15/2007 04:51 AM <DIR> mingw32
01/15/2007 04:52 AM <DIR> share
01/15/2007 04:52 AM 58,426 uninst.exe
6 File(s) 242,017 bytes
11 Dir(s) 2,627,039,232 bytes free
Quote from: cbexaminr on January 16, 2007, 12:32:37 AM
Well, my results from installing mingw-5-1.3.exe differ from yours, as below. (The directory listing showing location [c:\mingw\] is at end of block instead of beginning.) The directory did not exist before I performed the installation. (I do have one idea about why they might differ, which I will pursue after I post this.)
OK, your minGW looks to be installed correctly to the default folder of c:\mingw.
Note: I have multiple minGW installs so I don't use the default folder of c:\mingw.
Now open a command prompt and verify that cc1plus is correct?
CD C:\MinGW\libexec\gcc\mingw32\3.4.2
cc1plus --version
Here's what I got for version 3.4.2 install below.
C:\>cd C:\apps\MinGW_GCC_3.4.2_API_3_8\libexec\gcc\mingw32\3.4.2
C:\apps\MinGW_GCC_3.4.2_API_3_8\libexec\gcc\mingw32\3.4.2>cc1plus --version
GNU C++ version 3.4.2 (mingw-special) (mingw32)
compiled by GNU C version 3.4.2 (mingw-special).
GGC heuristics: --param ggc-min-expand=95 --param ggc-min-heapsize=122814
C:\apps\MinGW_GCC_3.4.2_API_3_8\libexec\gcc\mingw32\3.4.2>
Now open a command prompt and verify that cc1plus does NOT exists in your path
CD C:\
cc1plus --version
C:\>cc1plus --version
'cc1plus' is not recognized as an internal or external command,
operable program or batch file.
mingw-5.1.3.exe is still broken. I believe it crashes when whatever mirror it chooses does not have all of the packages under some circumstance. At any rate, it crashed 3 times on me.... But I believe I've finally matched your versions (by selecting candidate rather than current.)
I also added the check of cc1plus... see second box for all version info.
And I've tried to rebuild again including wxwidgets. ([edit] but I just found that wxwidgets didn't rebuild properly with 3.4.5, some complaint involving a typedef for boolean.) The candidate version (3.4.5) seems to handle the "-Winvalid-pch" option in the project file. But, I'm still stuck when it reaches Scintilla, attempting to include a wx/setup.h that it can't find. ([edit] I also just found that I had 'lib' specified in the "lib" field for the global variable cw. Deleting that seemed to make a big difference in compiling Scintilla... but now backing up to 3.4.2 to see if I can get wxwidgets built again...)
I just don't think the paths in the command look correct, with an absolute path for c:\...\wxWidgets-2.6.3\include, but a relative path of lib\gcc_dll\mswu, which I don't think the compiler can possibly find (at least with the preprocessor include search path rules I'm familiar with)...???
There is a setup.h in c:\...\wxWidgets-2.6.3\lib\gcc_dll\mswu\wx, but I'm sure the compiler's not going to find it with that relative path!!!
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -D__WX__ -DWINVER=0x0400 -DSCI_LEXER -DLINK_LEXERS -DWXMAKINGDLL_SCI -IC:\dlh\dev\wxwidgets\wxWidgets-2.6.3\include -Ilib\gcc_dll\mswu -IC:\dlh\dev\wxwidgets\wxWidgets-2.6.3\contrib\include -Isdk\wxscintilla\include -Isdk\propgrid\include -Isdk\wxscintilla\include -Isdk\wxscintilla\src\scintilla\include -Isdk\wxscintilla\src\scintilla\src -c sdk\wxscintilla\src\PlatWX.cpp -o .objs\2.6\sdk\wxscintilla\src\PlatWX.o
In file included from C:/dlh/dev/wxwidgets/wxWidgets-2.6.3/include/wx/defs.h:21,
from C:/dlh/dev/wxwidgets/wxWidgets-2.6.3/include/wx/wx.h:15,
from sdk\wxscintilla\src\PlatWX.cpp:9:
C:/dlh/dev/wxwidgets/wxWidgets-2.6.3/include/wx/platform.h:190:22: wx/setup.h: No such file or directory
mingw32-gcc (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
mingw32-g++ (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
GNU windres 2.16.91 20060119
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
GNU ar 2.16.91 20060119
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
GNU C++ version 3.4.5 (mingw special) (mingw32)
compiled by GNU C version 3.4.5 (mingw special).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
'cc1plus' is not recognized as an internal or external command,
operable program or batch file.
Volume in drive C has no label.
Volume Serial Number is 0B59-0F3A
Directory of c:\mingw
01/15/2007 07:11 PM <DIR> .
01/15/2007 07:11 PM <DIR> ..
01/15/2007 07:11 PM <DIR> bin
01/15/2007 06:42 PM 7,114,497 binutils-2.16.91-20060119-1.tar.gz
12/18/2000 05:47 PM 17,992 COPYING
01/29/2001 09:32 AM 26,430 COPYING.LIB
01/15/2007 07:10 PM <DIR> doc
01/15/2007 06:46 PM 3,464,344 gcc-core-3.4.5-20060117-1.tar.gz
01/15/2007 06:47 PM 4,710,429 gcc-g++-3.4.5-20060117-1.tar.gz
01/15/2007 07:11 PM <DIR> include
01/15/2007 07:11 PM <DIR> info
01/15/2007 07:11 PM 288 installed.ini
01/15/2007 07:11 PM <DIR> lib
01/15/2007 07:11 PM <DIR> libexec
01/15/2007 07:11 PM <DIR> man
01/15/2007 04:35 AM 138,705 MinGW-5.1.3.exe
01/15/2007 07:11 PM 46 MinGW.url
01/15/2007 07:11 PM <DIR> mingw32
01/15/2007 07:11 PM 58,426 uninst.exe
01/15/2007 06:34 PM 1,623,353 w32api-3.8.tar.gz
10 File(s) 17,154,510 bytes
10 Dir(s) 2,524,815,360 bytes free
Quote from: stahta01 on January 14, 2007, 11:53:31 AM
Please verify that it compiled right. If it worked right you should have a DLL created in the folder lib\gcc_dll called wxmsw26u_gcc_custom.dll.
Do you see it?
Tim S
for errors that mention jpeg or boolean try this patch
[ 1606032 ] [2.6] jpeg boolean mingw API 3.8 fix backport
http://sourceforge.net/tracker/index.php?func=detail&aid=1606032&group_id=9863&atid=309863
for errors that mention ddraw.h try this work around
DirectX 8.0 headers. Uncompress this over the MinGW directory. Add c:\mingw\bin to your PATH. Compile by typing mingw32-make. (for minGW 3.4.5 ONLY)
http://www.mame.net/zips/dx80_mgw.zip OR download from SF http://alleg.sourceforge.net/files/dx80_mgw.zip
For boolean apply above patch or revert to using API 3.7.
http://downloads.sourceforge.net/mingw/w32api-3.7.tar.gz?modtime=1145039963&big_mirror=1
You are correct that "-Ilib\gcc_dll\mswu" does NOT look correct to me.
Tim S
researching possible causes now.
here's my build command
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -D__WX__ -DWINVER=0x0400 -DSCI_LEXER -DLINK_LEXERS -DWXMAKINGDLL_SCI -IC:\wx\inno\wxWidgets-2.6_BRANCH\include -IC:\wx\inno\wxWidgets-2.6_BRANCH\lib\gcc_dll\mswu -IC:\wx\inno\wxWidgets-2.6_BRANCH\contrib\include -Isdk\wxscintilla\include -Isdk\propgrid\include -Isdk\wxscintilla\include -Isdk\wxscintilla\src\scintilla\include -Isdk\wxscintilla\src\scintilla\src -c sdk\wxscintilla\src\PlatWX.cpp -o .objs\2.6\sdk\wxscintilla\src\PlatWX.o
Please verify that you did NOT change the settings
The second one listed is not working for you; these are only the first three setting.
To view them do this.
"Project" -> "Build options" Tab "directories" Tab "Compiler"
Tim S
$(#WX.include)
$(#WX.lib)\gcc_dll$(WX_CFG)\msw$(WX_SUFFIX)
$(#WX)\contrib\include
I am waiting for Ubuntu package :) I hoped, it would be in next release, but it hadn't been yet.
Quote from: mareq on January 16, 2007, 08:51:25 AM
I am waiting for Ubuntu package :) I hoped, it would be in next release, but it hadn't been yet.
They have been working on some Linux 64 bit issues two days ago, not heard any thing in past 24 hours so I assume the problem was more complex than they thought.
Tim S
First - kb - I may try that if/when I finally give up on [edit] this project approach...
Second - Tim - [thanks again for your help]
I ramble(d) too much, so guess you missed this note, or read reply before I added the edit... I _had_ put somethiing in "lib" field of global variable "cw"... After I emptied lib field, I was able to compile Scintilla (but not link it because of wxwidgets failure, which I overlooked when I redid).
Quote from: cbexaminr on January 16, 2007, 02:13:16 AM
([edit] I also just found that I had 'lib' specified in the "lib" field for the global variable cw. Deleting that seemed to make a big difference in compiling Scintilla... but now backing up to 3.4.2 to see if I can get wxwidgets built again...)
I then backed up to 3.4.2 to build wxwidgets (having forgotten your notes about the patches), as its absence was causing scintilla link failures.
Now back to 3.4.5 for codeblocks, and wondering where "encoding" is supposed to be defined...
getting error in autorevision.h, at line #13 in version I have...
line contains:
const unsigned int svn_revision = encoding="utf-8"?>;
getting error:
"error: 'encoding' was not declared in this scope"
logged command line plus initial error msg:
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DEXPORT_EVENTS -IC:\dlh\dev\wxwidgets\wxWidgets-2.6.3\include -IC:\dlh\dev\wxwidgets\wxWidgets-2.6.3\lib\gcc_dll\mswu -IC:\dlh\dev\wxwidgets\wxWidgets-2.6.3\contrib\include -Isdk\wxscintilla\include -Isdk\propgrid\include -Isdk -Isdk\scripting\include -Isdk\scripting\sqplus -Isdk\wxFlatNotebook\include -c sdk\configmanager-revision.cpp -o .objs\2.6\sdk\configmanager-revision.o
In file included from sdk\configmanager-revision.cpp:13:
sdk\autorevision.h:13: error: `encoding' was not declared in this scope
Quote from: cbexaminr on January 16, 2007, 09:28:09 AM
getting error in autorevision.h, at line #13 in version I have...
line contains:
const unsigned int svn_revision = encoding="utf-8"?>;
getting error:
"error: 'encoding' was not declared in this scope"
logged command line plus initial error msg:
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DEXPORT_LIB -DEXPORT_EVENTS -IC:\dlh\dev\wxwidgets\wxWidgets-2.6.3\include -IC:\dlh\dev\wxwidgets\wxWidgets-2.6.3\lib\gcc_dll\mswu -IC:\dlh\dev\wxwidgets\wxWidgets-2.6.3\contrib\include -Isdk\wxscintilla\include -Isdk\propgrid\include -Isdk -Isdk\scripting\include -Isdk\scripting\sqplus -Isdk\wxFlatNotebook\include -c sdk\configmanager-revision.cpp -o .objs\2.6\sdk\configmanager-revision.o
In file included from sdk\configmanager-revision.cpp:13:
sdk\autorevision.h:13: error: `encoding' was not declared in this scope
Note: code::blocks works great with 3.4.2, most developers of C::B are using 3.4.5 or higher.
( This is mainly because some of them are using Linux.)
So, you need not use 3.4.5 with C::B, but use at least a 3.4 or higher. minGW does have an 3.3 version called previous. Note, autorevision.h is an auto created header.
Do you have SVN installed?
( svn is called by the program that creates autorevision.h)
Is the path to it in the PATH variable?
Have you re-built the C::B main project?
Since you got it to work better?
Tim S
Quote from: stahta01 on January 16, 2007, 10:08:23 AM
Note, autorevision.h is an auto created header.
Do you have SVN installed?
( svn is called by the program that creates autorevision.h)
Is the path to it in the PATH variable?
Have you re-built the C::B main project?
Since you got it to work better?
Tim S
OK, that helps - I used SVN from cygwin prompt to fetch source. I don't have any SVN in my general paths.
Will change (somehow) and try again...
OK, finally got it built. But, then tried to execute it in place (src\devel), and got an error box with contents:
"Mismatch between the program and library build versions detected.
The library used 2.6 (no debug,Unicode,compiler with C++ ABI 102, wx containers, compatible with 2.4),
and your program used 2.6 (no debug,Unicode,compiler with C++ ABI 1002,wx containers, compatible with 2.4)."
(The different in the two items seems to be 102 vs 1002, which took me some time so see.)
Is this because I used one version compiler to build wxwidgets, and a different version to build codeblocks?
That seems a little extreme...? If the different version compilers are the cause, What is the difference that makes this a problem?
I have no idea, but I would suggest using the 3.4 compiler to compile wxWidgets, I think you used an 3.3 compiler based on some of the info you gave me earlier.
The files wx/build.h and wx/version.h are used to build that message but I can NOT find where __GXX_ABI_VERSION is set. I think that is where the 102 or 1002 is from.
The following command returns a list of values one of which is __GXX_ABI_VERSION
g++ -c nul.c -E -dM
3.4.2 returns 1002 for __GXX_ABI_VERSION
3.4.5 returns 1002 for __GXX_ABI_VERSION
Tim S
From google I found http://blog.gmane.org/gmane.comp.gnu.mingw.user/month=20030601
#define __GXX_ABI_VERSION 102
#define __VERSION__ "3.2 (mingw special 20020817-1)"
QuoteIs this because I used one version compiler to build wxwidgets, and a different version to build codeblocks?
That seems a little extreme...? If the different version compilers are the cause, What is the difference that makes this a problem?
Yes, that is exactly it. The ABI has changed between gcc 3.4.2 and 3.4.5 so you need to compile again (either your project or the library) with the same compiler.
Quote from: mandrav on January 17, 2007, 08:55:19 AM
QuoteIs this because I used one version compiler to build wxwidgets, and a different version to build codeblocks?
That seems a little extreme...? If the different version compilers are the cause, What is the difference that makes this a problem?
Yes, that is exactly it. The ABI has changed between gcc 3.4.2 and 3.4.5 so you need to compile again (either your project or the library) with the same compiler.
Some of the version numbers he gave me at first seemed to imply that he was using 3.3.x GCC
I have never had a problem mixing 3.4.2 and 3.4.5; I have been using 3.4.5 for wxWidgets and 3.4.2 for code::blocks for several weeks with no problem.
Tim S
Quote from: stahta01 on January 17, 2007, 09:41:04 AM
Quote from: mandrav on January 17, 2007, 08:55:19 AM
QuoteIs this because I used one version compiler to build wxwidgets, and a different version to build codeblocks?
That seems a little extreme...? If the different version compilers are the cause, What is the difference that makes this a problem?
Yes, that is exactly it. The ABI has changed between gcc 3.4.2 and 3.4.5 so you need to compile again (either your project or the library) with the same compiler.
Some of the version numbers he gave me at first seemed to imply that he was using 3.3.x GCC
I have never had a problem mixing 3.4.2 and 3.4.5; I have been using 3.4.5 for wxWidgets and 3.4.2 for code::blocks for several weeks with no problem.
Tim S
Yes, I might be wrong about the actual versions (I haven't read the whole topic). The point is that he used two different (ABI-incompatible) compilers...
Could someone try to verify this bug.
Ubuntu Edgy, wxGTK 2.6.3p2, rev 3497
With Code completion enabled:
1. Start Code::Blocks (from terminal)
2. Close Code::Blocks.
3. I get "Aborted (core dumped)" message.
GDB output:
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run
Starting program: /usr/local/bin/codeblocks
[Thread debugging using libthread_db enabled]
[New Thread -1230534992 (LWP 11857)]
[New Thread -1246491744 (LWP 11984)]
[New Thread -1254884448 (LWP 11985)]
[New Thread -1263277152 (LWP 11986)]
[New Thread -1271669856 (LWP 11987)]
[New Thread -1281201248 (LWP 11988)]
[New Thread -1291682912 (LWP 11989)]
[Thread -1281201248 (zombie) exited]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1230534992 (LWP 11857)]
0xb7d5c6e1 in TiXmlElement::ClearThis (this=0x88ee7d0) at tinyxml.cpp:536
536 delete node;
(gdb) bt
#0 0xb7d5c6e1 in TiXmlElement::ClearThis (this=0x88ee7d0) at tinyxml.cpp:536
#1 0xb7d5d430 in ~TiXmlElement (this=0x88ee7d0) at tinyxml.cpp:525
#2 0xb7d5b451 in TiXmlNode::Clear (this=0x8772040) at tinyxml.cpp:162
#3 0xb7d5c6c2 in TiXmlElement::ClearThis (this=0x8772040) at tinyxml.cpp:531
#4 0xb7d5d430 in ~TiXmlElement (this=0x8772040) at tinyxml.cpp:525
#5 0xb7d5b451 in TiXmlNode::Clear (this=0x8a56780) at tinyxml.cpp:162
#6 0xb7d5c6c2 in TiXmlElement::ClearThis (this=0x8a56780) at tinyxml.cpp:531
#7 0xb7d5d430 in ~TiXmlElement (this=0x8a56780) at tinyxml.cpp:525
#8 0xb7d5b451 in TiXmlNode::Clear (this=0x81f97e8) at tinyxml.cpp:162
#9 0xb7d5c6c2 in TiXmlElement::ClearThis (this=0x81f97e8) at tinyxml.cpp:531
#10 0xb7d5d430 in ~TiXmlElement (this=0x81f97e8) at tinyxml.cpp:525
#11 0xb7d5b451 in TiXmlNode::Clear (this=0x81f9760) at tinyxml.cpp:162
#12 0xb7d5c6c2 in TiXmlElement::ClearThis (this=0x81f9760) at tinyxml.cpp:531
#13 0xb7d5d430 in ~TiXmlElement (this=0x81f9760) at tinyxml.cpp:525
#14 0xb7d5b451 in TiXmlNode::Clear (this=0x81f9658) at tinyxml.cpp:162
#15 0xb7d5c6c2 in TiXmlElement::ClearThis (this=0x81f9658) at tinyxml.cpp:531
#16 0xb7d5d430 in ~TiXmlElement (this=0x81f9658) at tinyxml.cpp:525
#17 0xb7d5b451 in TiXmlNode::Clear (this=0x81e4858) at tinyxml.cpp:162
#18 0xb7d5c6c2 in TiXmlElement::ClearThis (this=0x81e4858) at tinyxml.cpp:531
#19 0xb7d5d430 in ~TiXmlElement (this=0x81e4858) at tinyxml.cpp:525
#20 0xb7d5d2cd in ~TiXmlNode (this=0x81e4788) at tinyxml.cpp:141
#21 0xb7d62df4 in ~TiXmlDocument (this=0x81e4788) at tinyxml.h:1375
#22 0xb7bc4624 in CfgMgrBldr::Close (this=0x81e58d8) at configmanager.cpp:342
#23 0xb7bc480c in ~CfgMgrBldr (this=0x81e58d8) at configmanager.cpp:322
#24 0xb7c35804 in ~Manager (this=0xb7f2d340) at manager.h:152
#25 0xb7c35840 in __tcf_0 () at manager.cpp:91
#26 0xb724e299 in exit () from /lib/tls/i686/cmov/libc.so.6
#27 0xb72378d4 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#28 0x08066921 in _start ()
I also get the following:
pure virtual method called
terminate called without an active exception
It seems to be random but it happens when Code completion plugin is enabled.
Yes, I 'm looking into it.
FWIW...
YEAH!
While the path was not entirely smooth (even from my last interchange here) to my current point, I've finally gotten a version built (for better or worse even with wxwidgets 2.8.0), that will at least load to the main display window (past splash screen, and past change associations dialog), where I can ask it to do something.
I haven't tried to actually do anything more with it, but there couldn't possibly be any more problems, right? :)
Thanks for the help.
Hey everyone. I would like to know what you need to install the SuSE version of Code::Blocks.
Ok, I just have to setup SuSE on my machine again (formatted a while ago and didn't have the time nor the energy to set it up :wink: ) but to know how to get the nightlies to work on it will be great!
Thanks