Author Topic: The 17 January 2007 build is out.  (Read 20440 times)

Offline mareq

  • Multiple posting newcomer
  • *
  • Posts: 25
Re: The 17 January 2007 build is out.
« Reply #15 on: January 18, 2007, 08:05:10 am »
Please make also Ubuntu version. Thank you.

I just upload the 6.06 deb. As soon as Killerbot gets around to it, he'll publish it for downloading. I'm working on the 6.10 build now and will upload it to Savefile.com as soon as I can.



Thank you

Offline mareq

  • Multiple posting newcomer
  • *
  • Posts: 25
Re: The 17 January 2007 build is out.
« Reply #16 on: January 18, 2007, 08:07:13 am »
Ubuntu 6.10 (Edgy) build here.

Is there a difference between Ubuntu 6.06 and Ubuntu Edgy 6.10 build?
My OS is Ubuntu Edgy 6.10 but I use the Ubuntu 6.06 Code::Blocks version. Should I replace it with 6.10?

Offline cstudent

  • Almost regular
  • **
  • Posts: 159
    • Cstudent's Help Desk
Re: The 17 January 2007 build is out.
« Reply #17 on: January 18, 2007, 12:31:54 pm »
Ubuntu 6.10 (Edgy) build here.

Is there a difference between Ubuntu 6.06 and Ubuntu Edgy 6.10 build?
My OS is Ubuntu Edgy 6.10 but I use the Ubuntu 6.06 Code::Blocks version. Should I replace it with 6.10?

The main difference is I build them using the GCC libraries that are installed by default in 6.06 or 6.10. In Dapper the version is 4.0.3 and in Edgy it's 4.1.2. The debs are built in such a way that the 6.06 deb will install on Edgy, but not the other way around. The Dapper deb is also built using wxWidgets 2.6.1, which is the version available in the Dapper repositories. Edgy is built using wxWidgets 2.6.3, the version in Edgy's repos.


Offline mareq

  • Multiple posting newcomer
  • *
  • Posts: 25
Re: The 17 January 2007 build is out.
« Reply #18 on: January 18, 2007, 01:58:04 pm »
Ubuntu 6.10 (Edgy) build here.

This server is pretty slow, is it possible to upload this version also on berlios (in the annoucement of new versions, there could be two ubuntu links) :)?

Offline straka.milan

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: The 17 January 2007 build is out.
« Reply #19 on: January 18, 2007, 04:56:40 pm »
tried it also with a project with no spaces in the path (so that's not the cause), same issue :

Quote
Building to ensure sources are up-to-date
Build succeeded
Selecting target: Debug
Adding source dir: /home/killerbot/Documents/CbProjects/DeleteMe2/
Adding source dir: /home/killerbot/Documents/CbProjects/DeleteMe2/
Adding file: ./DeleteMe2
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.5
Program exited normally.
Debugger finished with status 0

Same for me, not "spaces in path" issue. I used Ubuntu 6.06 night build from 8. 1. 2007, on Debian testing, GDB 6.4.90. According to debugger log the breakpoint is reached, program interrupted, then there is "info program" command and immediately after that "cont" program. So the program successfully continues and finishes.

When I set two consecutive breakpoints, it really stopped on the second one and worked fine from that on :shock:
Q='Q=%s;printf "$Q" "\x27$Q\x27"';printf "$Q" "'$Q'"

Offline cstudent

  • Almost regular
  • **
  • Posts: 159
    • Cstudent's Help Desk
Re: The 17 January 2007 build is out.
« Reply #20 on: January 18, 2007, 05:20:18 pm »
This server is pretty slow, is it possible to upload this version also on berlios (in the annoucement of new versions, there could be two ubuntu links) :)?

That would be up to Killerbot and/or Mandrav. Maybe a better solution is to use the more "generic" deb that runs on both Dapper and Edgy and just change the name to CB_date_rev_Ubuntu6.XX.deb.

The main reason I build the two separate versions the way I do is because it gives the closes equivalent to a "built from source" install on each Ubuntu OS. But I don't think there is any significant advantage to using the Edgy specific deb over the Dapper deb.


Offline Jordar

  • Single posting newcomer
  • *
  • Posts: 8
Re: The 17 January 2007 build is out.
« Reply #21 on: January 19, 2007, 07:18:25 am »
<Problem with Compiler using absolute source filenames>

Hi,  I have been using the dos compiler DJGPP with Codeblocks for well over a year now.  However the latest build will not work for me due to the fact that the compiler is now being forced to use absolute filenames.  I am hazy on the specifics but I know that when windows calls the Dos-16 executable GCC.exe that it only allows a certain number of characters on the command line.  This latest build forces the call with well over the maximum number of characters. 

Here is an examples of a previous (relative) path call:

cmd /c gcc.exe -march=pentium2 -D_DJGPP  -IC:\djgpp\include  -c TIMERS.cpp -o DJ_Rel\TIMERS.o

This calls succeeds.

But with the new (absolute) calls it looks like this:
cmd /c gcc.exe -march=pentium2 -D_DJGPP  -IC:\djgpp\include  -c C:projects\foo\TIMERS.cpp -o DJ_Rel\TIMERS.o

The output says "could not execute specified file"

Can we please make the relative/absolute path names a project option?  Otherwise I am going to have to start keeping all of my source in the root directory :(   Does anyone know of a workaround?

thanks for your time,
Jordar


Offline joubertdj

  • Multiple posting newcomer
  • *
  • Posts: 120
Re: The 17 January 2007 build is out.
« Reply #22 on: January 19, 2007, 07:44:57 am »
Which version of DJGPP are you using and OS?

[EDIT] Dos-16 Executable hey :) (James) The newer versions of GCC from http://www.delorie.com/djgpp/
[EDIT] is not 16-Bit based
« Last Edit: January 19, 2007, 07:46:52 am by joubertdj »

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5193
Re: The 17 January 2007 build is out.
« Reply #23 on: January 19, 2007, 08:59:49 am »
could you check if with the above suggestion you can make it work again.

In case we need the option, I would not put it on the project level. Since it is a workaround for GDB, I think it's better to put in on the compiler level (advanced option), because when you are using compilers which create code that will not be hand over to GDB than this workaround is just overhead.

Let me think a little bit more about it, maybe I'll add the option at compiler level anyway ...

Offline jsibarani

  • Multiple posting newcomer
  • *
  • Posts: 31
Re: The 17 January 2007 build is out.
« Reply #24 on: January 19, 2007, 09:11:40 am »
Codeblocks under Slackware 11 with wxGTK 2.8.0 compiled OK.
When i want to create a new wxWidgets project via the wizard, CB always give me an Error Dialog.
The same thing happened when i create new c/c++ source file.



However there was compile error when compiling wxSmith
The error was:
-------------------------------------------------------------------------------------------------------------------------------------------
 g++ -DHAVE_CONFIG_H -I. -I../../../../../../src/plugins/contrib/wxSmith/defwidgets -I../../../../../src/sdk -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1 -D__WXGTK__ -pthread -I../../../../../../src/sdk -I../../../../../../src/sdk/wxscintilla/include -I../../../../../../src/sdk/propgrid/include -O2 -ffast-math -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT wxslistbook.lo -MD -MP -MF .deps/wxslistbook.Tpo -c ../../../../../../src/plugins/contrib/wxSmith/defwidgets/wxslistbook.cpp  -fPIC -DPIC -o .libs/wxslistbook.o
../../../../../../src/plugins/contrib/wxSmith/defwidgets/wxslistbook.cpp: In member function `virtual void wxsListbook::PreviewMouseEvent(wxMouseEvent&)':
/usr/include/wx-2.8/wx/listbook.h:94: error: `virtual int wxListbook::HitTest(const wxPoint&, long int*) const' is protected
../../../../../../src/plugins/contrib/wxSmith/defwidgets/wxslistbook.cpp:207: error: within this context
make[6]: *** [wxslistbook.lo] Error 1
-----------------------------------------------------------------------------------------------------------------------------


Thanks

Offline David Perfors

  • Developer
  • Lives here!
  • *****
  • Posts: 560
Re: The 17 January 2007 build is out.
« Reply #25 on: January 19, 2007, 10:23:53 am »
Please try to compile with wx 2.6.x C::B doesn't support 2.8 for now...

(btw. I had the same error on windows..)
OS: winXP
Compiler: mingw
IDE: Code::Blocks SVN WX: 2.8.4 Wish list: faster code completion, easier debugging, refactoring

Offline jsibarani

  • Multiple posting newcomer
  • *
  • Posts: 31
Re: The 17 January 2007 build is out.
« Reply #26 on: January 19, 2007, 12:16:39 pm »
OK Thanks.


The problem doesn't exist in CB build January 18 2007 for Windows.

Offline David Perfors

  • Developer
  • Lives here!
  • *****
  • Posts: 560
Re: The 17 January 2007 build is out.
« Reply #27 on: January 19, 2007, 01:46:25 pm »
The problem is related to wx2.8 and the nightlies are build with wx2.6 ;)
OS: winXP
Compiler: mingw
IDE: Code::Blocks SVN WX: 2.8.4 Wish list: faster code completion, easier debugging, refactoring

Offline Jordar

  • Single posting newcomer
  • *
  • Posts: 8
Re: The 17 January 2007 build is out.
« Reply #28 on: January 19, 2007, 05:08:12 pm »
Hi,  Thanks for the responses. 

It is true that the DJGPP gcc is a 32 bit compiler/executable.  However the file must start in MS-DOS 16, so the executable contains a 16-bit "stub" which then calls the 32 bit mode and runs the rest of the executable in 32 bit protected mode.  For this reason I do not believe that there is a work around since windows sees this stub and automatically runs the gcc.exe in 16 bit mode, causing a limitation on the amount of command arguments.  This is my understanding of it at least. 

For the record I am using DJGPP gcc version 4.1.0

I think your idea of making it a compiler option would be very beneficial to DJGPP users.

Thanks for you help,
Jordar

p.s. I forgot to mention I am running XP Pro
« Last Edit: January 19, 2007, 05:12:12 pm by Jordar »

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5193
Re: The 17 January 2007 build is out.
« Reply #29 on: January 20, 2007, 05:41:44 pm »
the option has been implemented :default value is false (that means use relative paths), the GCC supported MinGW in CB sets this to true (use absolute paths)