Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on January 10, 2007, 07:10:02 pm

Title: The 10 January 2007 build is out.
Post by: killerbot on January 10, 2007, 07:10:02 pm
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:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 10 January 2007 build is out.
Post by: 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 ... ;-)
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 10, 2007, 07:48:03 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.codeblocks.org/index.php?topic=4912.msg38326#msg38326

Can someone else confirm the wxWidgets 2.6 patch works for them.

Tim S
Title: Re: The 10 January 2007 build is out.
Post by: lubos on January 10, 2007, 08:28:05 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.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:
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 10, 2007, 08:40:34 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
Title: Re: The 10 January 2007 build is out.
Post by: 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>
Title: Re: The 10 January 2007 build is out.
Post by: lubos on January 10, 2007, 09:12:21 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.
Title: Re: The 10 January 2007 build is out.
Post by: Darck on January 10, 2007, 09:20:28 pm
i get not found message...
Title: Re: The 10 January 2007 build is out.
Post by: PsYhLo on January 10, 2007, 09:32:21 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 ;)
Title: Re: The 10 January 2007 build is out.
Post by: asdf on January 10, 2007, 09:38:51 pm
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.
Title: Re: The 10 January 2007 build is out.
Post by: lubos on January 10, 2007, 09:51:25 pm
i get not found message...
don't worry, you are not only one :D
Title: Re: The 10 January 2007 build is out.
Post by: MortenMacFly on January 10, 2007, 10:03:47 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.
Title: Re: The 10 January 2007 build is out.
Post by: Ceniza on January 10, 2007, 10:07:25 pm
Quote from: Darck
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.

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: MortenMacFly
I 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.
Title: Re: The 10 January 2007 build is out.
Post by: Darck on January 11, 2007, 12:34:03 pm
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.
Title: Re: The 10 January 2007 build is out.
Post by: lubos on January 11, 2007, 01:46:20 pm
Quote from: MortenMacFly
I 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... :?
Title: Re: The 10 January 2007 build is out.
Post by: Darck on January 12, 2007, 08:07:40 pm
menu project > set programs arguments
                    > notes
doesn't work, when i have one .c file loaded
Title: Re: The 10 January 2007 build is out.
Post by: killerbot on January 12, 2007, 08:28:55 pm
you need a project, not just a 1 file, create a project (guess an exe ??) and copy the contents into the main.c
Title: Re: The 10 January 2007 build is out.
Post by: Darck on January 12, 2007, 08:36:40 pm
it shouldn't be necessary. At least parameters
Title: Re: The 10 January 2007 build is out.
Post by: Acki on January 13, 2007, 02:07:03 am
Now I get a script running error when starting C::B !!!  :shock:
Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 14, 2007, 04:37:37 am
(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...
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 14, 2007, 06:38:57 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
Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 14, 2007, 10:07:31 am
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.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...
Title: Re: The 10 January 2007 build is out.
Post by: 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

Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 14, 2007, 03:09:07 pm
Yes, its there.

9,449,470 wxmsw26u_gcc_custom.dll
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 14, 2007, 03:22:14 pm
Fetched SVN source

You are fetching the source from svn.berlios.de?
Tim S
Title: Re: The 10 January 2007 build is out.
Post by: Electron on January 14, 2007, 04:12:42 pm
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?

Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 14, 2007, 04:29:11 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
Title: Re: The 10 January 2007 build is out.
Post by: Electron on January 14, 2007, 04:40:31 pm
Ah thank you, that fixes one of my issues :)
Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 14, 2007, 04:53:32 pm
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
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 14, 2007, 05:33:32 pm
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
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 14, 2007, 05:37:08 pm
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
Title: Re: The 10 January 2007 build is out.
Post by: 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...
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 14, 2007, 09:03:31 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
Title: Re: The 10 January 2007 build is out.
Post by: 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.

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?
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 15, 2007, 01:57:44 am
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
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 15, 2007, 02:04:20 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?
Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 15, 2007, 04:50:19 am
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?

....
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 15, 2007, 05:45:49 am
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.

Code
REGEDIT4

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\MinGW]
Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 15, 2007, 10:30:58 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!
Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 15, 2007, 11:34:33 am

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
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 15, 2007, 12:45:12 pm
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
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 15, 2007, 12:49:14 pm
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
Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 15, 2007, 09:47:24 pm
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.codeblocks.org/index.php?topic=1701.0)
(most current observed - http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows)

Title: Re: The 10 January 2007 build is out.
Post by: killerbot on January 15, 2007, 09:53:19 pm
you can always try this :

http://wiki.codeblocks.org/index.php?title=Nightly_Cookbook
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 15, 2007, 10:54:09 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
Code
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.

Code
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


Title: Re: The 10 January 2007 build is out.
Post by: 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.)

Code
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
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 16, 2007, 12:59:40 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.

Code
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

Code
C:\>cc1plus --version
'cc1plus' is not recognized as an internal or external command,
operable program or batch file.

Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 16, 2007, 02:13:16 am
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!!!

Code
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

Code
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
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 16, 2007, 03:14: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
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 16, 2007, 03:26:44 am
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
Code
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
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 16, 2007, 03:35:36 am
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
Code
$(#WX.include)
$(#WX.lib)\gcc_dll$(WX_CFG)\msw$(WX_SUFFIX)
$(#WX)\contrib\include
Title: Re: The 10 January 2007 build is out.
Post by: 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.
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 16, 2007, 09:11:29 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
Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 16, 2007, 09:28:09 am
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).
([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


Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 16, 2007, 10:08:23 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
Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 16, 2007, 11:31:10 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...
Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 17, 2007, 04:30:52 am
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?
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 17, 2007, 05:35:41 am
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
Code
#define __GXX_ABI_VERSION 102
#define __VERSION__ "3.2 (mingw special 20020817-1)"
Title: Re: The 10 January 2007 build is out.
Post by: mandrav on January 17, 2007, 08:55:19 am
Quote
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?

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.
Title: Re: The 10 January 2007 build is out.
Post by: stahta01 on January 17, 2007, 09:41:04 am
Quote
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?

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
Title: Re: The 10 January 2007 build is out.
Post by: mandrav on January 17, 2007, 11:29:36 am
Quote
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?

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...
Title: Re: The 10 January 2007 build is out.
Post by: artoj on January 17, 2007, 11:32:22 am
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:

Code
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:

Code
pure virtual method called
terminate called without an active exception

It seems to be random but it happens when Code completion plugin is enabled.

Title: Re: The 10 January 2007 build is out.
Post by: mandrav on January 17, 2007, 12:32:58 pm
Yes, I 'm looking into it.
Title: Re: The 10 January 2007 build is out.
Post by: cbexaminr on January 19, 2007, 10:09:01 am
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.
Title: Re: The 10 January 2007 build is out.
Post by: Last-Attacker on January 20, 2007, 11:45:43 am
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