Code::Blocks Forums

User forums => Help => Topic started by: johne53 on September 19, 2007, 08:10:25 am

Title: Settings don't get saved (svn 4454)
Post by: johne53 on September 19, 2007, 08:10:25 am
A few days ago I installed svn 4454 (via the rpm package for OpenSuse). Since then, I'm finding that changes to my IDE aren't being reliably saved. For example, if the selected build target is Debug and I change it to Release, next time I start C::B it will still be Debug. Similarly if I use Settings->Compiler and Debugger and I add a new search directory, the new setting has disappeared next time I re-start C::B. Can anyone else confirm this before I report it as a bug?

Also, is there a way to manually save these kinds of changes?
Title: Re: Settings don't get saved (svn 4454)
Post by: thomas on September 19, 2007, 09:13:55 am
Can anyone else confirm this before I report it as a bug?
This is not the bug, but only a symptom of the bug. If settings are not saved, this means that a crash occurs after you tell the application to quit, but before ConfigManager is deleted (settings are saved in its destructor). To narrow down the source of the crash, please try disabling all contrib plugins first, and if that does not help, disable the "core" plugins one by one (start with CodeCompletion). Also, if you have a RPT file, it may be helpful to see that one.

Quote
Also, is there a way to manually save these kinds of changes?
None at the present time (and not likely in the future, although it would probably be easy to implement).
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 19, 2007, 09:18:00 am
If settings are not saved, this means that a crash occurs after you tell the application to quit, but before ConfigManager is deleted (settings are saved in its destructor). To narrow down the source of the crash, please try disabling all contrib plugins first, and if that does not help, disable the "core" plugins one by one (start with CodeCompletion). Also, if you have a RPT file, it may be helpful to see that one.

Yes - that's pretty much what I suspected. I haven't installed any plugins personally but I'll happily try disabling the standard ones if you can tell me where to do it. Also, what is an RPT file and where would I find it??
Title: Re: Settings don't get saved (svn 4454)
Post by: Biplab on September 19, 2007, 09:38:02 am
For example, if the selected build target is Debug and I change it to Release, next time I start C::B it will still be Debug.

This one is confirmed. This happens as the default target loaded from layout file is not used to update the Target Combo and the Menu items.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 19, 2007, 10:06:19 am
In fact I've just realised that if I change an IDE setting, I don't see the dialog box any more telling me that my layout has changed and asking if I want to save the new layout. So it's not even getting to that stage.

Is there a way of going back to my old version temporarily? I don't like having bugs that cause things not to get saved.
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on September 19, 2007, 10:39:57 am
Is there a way of going back to my old version temporarily? I don't like having bugs that cause things not to get saved.

If you compile codeblocks from svn you can checkout older versions by explicitly tell the svn-revision:

Code
svn checkout svn://svn.berlios.de/codeblocks/trunk /path/to/your/codeblocks/source/ -r revision_you_want --non-interactive 

Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 19, 2007, 12:28:17 pm
Thanks Jens. Unfortunately I've never managed to build C::B from source. If I try to compile the Codeblocks-unix project I get an error at line 9 ofPlatWX.cpp (wx/wx.h can't be found). I've tried finding it with find but I don't seem to have it. On the other hand, if I try to compile the Codeblocks project I get the error cc1plus: error: unrecognized command line option "-mthreads" I've never managed to work out what's wrong....  :(
Title: Re: Settings don't get saved (svn 4454)
Post by: Biplab on September 19, 2007, 01:40:55 pm
If I try to compile the Codeblocks-unix project I get an error at line 9 ofPlatWX.cpp (wx/wx.h can't be found).

It means you don't have wxGTK-devel package installed.

On the other hand, if I try to compile the Codeblocks project I get the error cc1plus: error: unrecognized command line option "-mthreads"

I guess you tried with the project file meant for Windows. -mthreads is applicable for Windows only. It won't work on Linux. So don't try to use this project file. It will not work out-of-box.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 19, 2007, 02:32:37 pm
It means you don't have wxGTK-devel package installed.

Sorry - did you mean wxWidgets-devel? I couldn't find much on Google about wxGTK_devel. Can you point me towards a site where I can download it (I'm running OpenSuse 10.2, so Yast or RPM would probably be favoured).

[Edit...] Oops, sorry. I found it (I typed it wrong into Google)

Do you know what version it's up to? The latest I can find is 2.6.3.3 but I thought it was at around 2.8.x.x
Title: Re: Settings don't get saved (svn 4454)
Post by: thomas on September 19, 2007, 02:53:09 pm
I'll happily try disabling the standard ones if you can tell me where to do it.
If you launch Code::Blocks with --safe-mode (type that in the "Run..." box or in the shell), it starts without *any* plugins at all. Other than that, you can disable plugins one by one from the "Manage Plugins" dialog (found in the "Plugins" menu).
Also, there is the really hard way of simply deleting the respective shared library from the plugins folder. As you can always restore them by hitting the "build" button, there's not much to lose really.

Quote
Also, what is an RPT file and where would I find it??
That is a file containing a stack backtrace, which can be used to pinpoint a crash in many situations. It is created when the application crashes and can normally be found in the same directory as the application or in your home directory, and called codeblocks.rpt.
Title: Re: Settings don't get saved (svn 4454)
Post by: Biplab on September 19, 2007, 03:08:35 pm
[Edit...] Oops, sorry. I found it (I typed it wrong into Google)
Do you know what version it's up to? The latest I can find is 2.6.3.3 but I thought it was at around 2.8.x.x

You should use at least wxGTK-devel-2.8.4 if you want to use wxGTK-2.8.x. Otherwise you can install wxGTK-2.6.3 package.

Or just compile it on your own. I assume, your PC has autotools, gcc installed.
1) Download wxGTK-2.8.4 source from wxWidgets site.
2) Extract it to a folder.
3) Open shell and type the following command to configure wxGTK (this is what I do).
Code
./configure --disable-debug --enable-shared --enable-unicode --enable-monolithic --with-gtk=2
4) Now do make and make install. Your PC is ready to compile C::B.

Quote
Also, what is an RPT file and where would I find it??

On Linux, you'll find it under /tmp folder. Look for the folders starting with codeblocks_dbgrpt-* (where * is several numbers). Inside that folder you'll find an codeblocks.xml file. That will contain the crash report.

Edit 1:

You can download wxGTK-2.8.4-devel from the following link.
Quote
http://download.opensuse.org/repositories/home:/TheTuxKeeper/openSUSE_10.2/i586/
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 19, 2007, 04:48:40 pm
Thanks. Forgive my ignorance - but is wxGTK-devel the same as wxWidgets-devel ?

(the library shown in your link was wxWidgets-devel).
Title: Re: Settings don't get saved (svn 4454)
Post by: stahta01 on September 19, 2007, 05:38:33 pm
Thanks. Forgive my ignorance - but is wxGTK-devel the same as wxWidgets-devel ?

(the library shown in your link was wxWidgets-devel).

wxWidgets has more than one type; wxGTK is the type needed by Code::Blocks under Linux.
Note, wxWidgets-devel is needed to compile Code::Blocks.

The file wxWidgets-2.8.4-11.1.i586.rpm is most likely needed to run Code::Blocks.

Tim S 
Title: Re: Settings don't get saved (svn 4454)
Post by: Biplab on September 19, 2007, 06:25:30 pm
Thanks. Forgive my ignorance - but is wxGTK-devel the same as wxWidgets-devel ?

(the library shown in your link was wxWidgets-devel).

Sorry for creating that confusion.

Download the wxWidgets-devel package to compile C::B. :)
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 19, 2007, 06:47:08 pm
Okay, I installed wxWidgets2.8-devel. Now when I compile I get an error at line 42 of /usr/include/wx-2.8/wx/defs.h

error: #error "No Target! You should use wx-config program for compilation flags!"

Is this simply a matter of a missing preprocessor directive or do I need to run some external program to configure something..?
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on September 19, 2007, 10:21:14 pm
How did you compile (or try to compile) the sources ?
If I use C::B to compile C::B  it does not work,  but if I do it from command-line there's no problem.

Just type (in root of the C::B source-tree):
Code
./bootstrap
./configure --enable-contrib
make
make install

I only tried it until make, because I have latest nightlies installed as deb-Packages, build from svn, but it works like a charm.
I used a fresh download from svn4483 in a clean directory.

Edit:
sorry it works, even from inside codeblocks. I forgot to change my standard compilers, before I started C::B. It does not work with gc-4.3 from debian-experimental, I use a shell script to switch to 4.2, I ran it before commandline compiling, but not before starting codeblocks.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 20, 2007, 07:56:19 am
In my case, the default compiler was already set correctly from previous C::B sessions so I decided to try your suggestion of 'make'.

At the line ./configure --enable-contrib I get the following error:-

Quote
configure: error:
                wxWidgets must be installed on your system.

                Please check that wx-config is in path, the directory
                where wxWidgets libraries are installed (returned by
                'wx-config --libs' or 'wx-config --static --libs' command)
                is in LD_LIBRARY_PATH or equivalent variable and
                wxWindows version is 2.6.0 or above.

I'm pretty confident that wxWidgets is installed so this must be either be lack of wxWindows or something to do with LD_LIBRARY_PATH

Q1) Do I need wxWindows on a Linux (OpenSuse) system?
Q2) Where would I find (and change) the LD_LIBRARY_PATH variable?

Q3) Why is everything so tortuously difficult under Linux???
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on September 20, 2007, 09:47:51 am
try the wx-config command from console, you need it to set the flags and library-paths for wxWidgets.
Quote
Do I need wxWindows on a Linux (OpenSuse) system?
wxWindows is the former name of wxWidgets.
I don't know in which packet you find wx-config on (Open-)Suse.

Quote
Why is everything so tortuously difficult under Linux???
For me it's much more difficult under Windows, but I use linux (with pauses, without any computer) since the early 1990's
Title: Re: Settings don't get saved (svn 4454)
Post by: Biplab on September 20, 2007, 10:47:10 am
At the line ./configure --enable-contrib I get the following error:-

It seems that the wxWidgets-devel package doesn't create any symbolic links during installation. You have two ways to fix this.
1) Create a symbolic link with the following commands.
Code
cd /usr/bin
su
ln -s /usr/lib/wx/config/gtk2-unicode-release-2.8 wx-config

2) Or
Issue the following command to configure C::B.
Code
./configure --enable-contrib --with-wx-config=/usr/lib/wx/config/gtk2-unicode-release-2.8
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 20, 2007, 11:01:40 am
Thanks guys. It turned out that under wxWidgets 2.8.x.x the file wx-config seems to have been renamed to wx-config-2.8.  I renamed it back to wx-config and everything seems to be progressing.

Just out of interest, what is a typical time taken for a full build? This one's been going for 40-50 minutes and (assuming it's processing the files alphabetically) it looks like I'm in for a long haul. I'm just about up to compilerTcc.cpp (which I'm sure has been done at least twice before).

[Edit...] Forget that - it just finished. One more question though.... how did it know whether to build a Debug version or a Release version?
Title: Re: Settings don't get saved (svn 4454)
Post by: Biplab on September 20, 2007, 11:15:27 am
[Edit...] Forget that - it just finished. One more question though.... how did it know whether to build a Debug version or a Release version?

By default a Release version with Debug symbols is compiled. Which means if you strip the binary and dynamic libraries, you'll get the Release version.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 20, 2007, 11:16:26 am
Groan....  :( I just sat through a 50 minute build. Then I did my 'make install' (as root).

Now when I try to start codeblocks I get an error:-

Quote
codeblocks: symbol lookup error: codeblocks: undefined symbol: cbEVT_QUERY_VIEW_LAYOUT

[Edit...] Sorry - got embroiled in various other stuff. A re-boot seems to have cured the above error and it seems at least to have (partially) solved my original problem. If I change (say) some global compiler settings, they're now being remembered - but if I change a project's build target, that still isn't being remembered.

Can anyone take a look at this problem:- http://forums.codeblocks.org/index.php/topic,6739.0.html (http://forums.codeblocks.org/index.php/topic,6739.0.html)

I've had permanent problems with check boxes ever since 22nd August and I'm still having them now, even after building from source. I can't believe that no-one else has found this. It's 100% repeatable for me....
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 22, 2007, 12:00:41 pm
If I change (say) some global compiler settings, they're now being remembered

I seem to have spoken too soon here. Basically, saving changes to the IDE is now very erratic. Sometimes it works, sometimes it doesn't. Can anyone confirm whether this is a known bug? I suspect it must be - because it was present in the last OpenSuse rpm package that I installed and it's still there, even though I've now downloaded and built the source code.

If it isn't a known problem I'll try some of the earlier suggestions - such as turning off plug-ins and seeing if I can provide a backtrace.
Title: Re: Settings don't get saved (svn 4454)
Post by: Albenejean on September 24, 2007, 08:29:29 pm
Sorry but I didn't have time to read the entire post.

In a nightly, I had pointed this:
Quote
Bug Found.

1_ Go to Settings->Compiler and Debugger
2_ Clear the directories in "Search directories"
3_ Go to "Toolchain Executables" and make an Autodetect.
4_ Click OK.
The directories are not set in Search Directories.

Now, make 1, 2 and 3, but click on CANCEL instead of OK.
The directories are set...

Funny, isn't it....

[EDIT]: Oooopppppsss, I have forgotten:
Tested on Windows XP, with SVN 4413

I don't know if this can help you...
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 25, 2007, 11:03:54 am
Well at least I'm not the only user experiencing unpredictable behaviour at the moment.

Any developers care to comment? Is there a reason why C::B has suddenly become so erratic in so many different areas?

I've posted several reports recently about config changes not being saved reliably / debugging having become very unreliable / checkboxes that don't update properly etc. But there doesn't seem to be any interest at all from the developers.
Title: Re: Settings don't get saved (svn 4454)
Post by: thomas on September 25, 2007, 11:15:54 am
Well at least I'm not the only user experiencing unpredictable behaviour at the moment.

Any developers care to comment? Is there a reason why C::B has suddenly become so erratic in so many different areas?

I've posted several reports recently about config changes not being saved reliably / debugging having become very unreliable / checkboxes that don't update properly etc. But there doesn't seem to be any interest at all from the developers.
What can I say... I'm developing under Windows and see no such thing here. The Mandraman uses Code::Blocks under Linux all day and does not seem to see any such thing either.
Is not so much about having no interest, is just we don't see it happen.
Title: Re: Settings don't get saved (svn 4454)
Post by: Biplab on September 25, 2007, 12:37:20 pm
Well at least I'm not the only user experiencing unpredictable behaviour at the moment.

Any developers care to comment? Is there a reason why C::B has suddenly become so erratic in so many different areas?

I've posted several reports recently about config changes not being saved reliably / debugging having become very unreliable / checkboxes that don't update properly etc. But there doesn't seem to be any interest at all from the developers.

Well I do use C::B on Linux and on Windows. I have not noticed such unexpected behaviour. I noticed one such stupid behaviour couple of days back, but it went away after I made a clean compile and install.

If you can give us Steps to reproduce such weird behaviour, may be some of us will be able to fix it. :)

In a nightly, I had pointed this:

I confirm this. :)
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 25, 2007, 01:19:43 pm
Biplap - thanks for persevering with this. Are you saying that in the Compiler & Debugger Settings dialog, the OK and CANCEL buttons are simply working the opposite way around? That doesn't really tie in with my experiences. OK does seem to work - but only occasionally.

Here are some links to the other problems I've been having. The first one is 100% repeatable. The second one is very erratic.

1) http://forums.codeblocks.org/index.php/topic,6739.msg51722.html#msg51722 (http://forums.codeblocks.org/index.php/topic,6739.msg51722.html#msg51722)

2) http://forums.codeblocks.org/index.php/topic,6967.0.html (http://forums.codeblocks.org/index.php/topic,6967.0.html)

I noticed one such stupid behaviour couple of days back, but it went away after I made a clean compile and install.

Before I do anything drastic - do you mean a clean compile & install of Code::Blocks - or of the project that was giving you problems?
Title: Re: Settings don't get saved (svn 4454)
Post by: Biplab on September 25, 2007, 01:27:08 pm
Are you saying that in the Compiler & Debugger Settings dialog, the OK and CANCEL buttons are simply working the opposite way around? That doesn't really tie in with my experiences. OK does seem to work - but only occasionally.

No I didn't mean that. The current problem is if you click on the Auto-detect button, the settings get saved irrespective of whether you click OK or Cancel button.

But clicking OK button works perfectly for me.

I noticed one such stupid behaviour couple of days back, but it went away after I made a clean compile and install.

Before I do anything drastic - do you mean a clean compile & install of Code::Blocks - or of the project that was giving you problems?

I suggest you to clean compile & installation of Code::Blocks. :)


BTW, I just read your posts. You have mentioned that you use KDE desktop. But I use GNOME one. So can you just give GNOME desktop a try to see if the problem persists or not.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 25, 2007, 01:36:57 pm
, I just read your posts. You have mentioned that you use KDE desktop. But I use GNOME one. So can you just give GNOME desktop a try to see if the problem persists or not.

Yes, I believe this is quite simple to do with OpenSuse. I don't quite know how but I'll find out and try it later. Thanks.
Title: Re: Settings don't get saved (svn 4454)
Post by: JGM on September 25, 2007, 02:59:11 pm
Well I do use C::B on Linux and on Windows. I have not noticed such unexpected behaviour.

I use codeblocks also on both platforms, and never had this kind of problems.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 25, 2007, 03:30:38 pm
Unfortunately it wasn't as easy to swap between KDE and Gnome as I thought so I'll have to leave that for now. However, here's what I have done....

1) Load up the Code::Blocks - Unix project from within Code::Blocks itself.
2) Select the build target "All".
3) Select Build->Clean and remove all object files.
4) Close Code::Blocks
5) Open a terminal window and switch to my C::B root folder.
6) Try to rebuild C::B using 'make'.

To my amazement it tells me there's nothing to be done!!
Title: Re: Settings don't get saved (svn 4454)
Post by: mandrav on September 25, 2007, 03:41:58 pm
Unfortunately it wasn't as easy to swap between KDE and Gnome as I thought so I'll have to leave that for now. However, here's what I have done....

1) Load up the Code::Blocks - Unix project from within Code::Blocks itself.
2) Select the build target "All".
3) Select Build->Clean and remove all object files.
4) Close Code::Blocks
5) Open a terminal window and switch to my C::B root folder.
6) Try to rebuild C::B using 'make'.

To my amazement it tells me there's nothing to be done!!

Doing things blindly will get you nowhere. What does the Code::Blocks project file has to do with 'make'?  :shock:
You will either use Code::Blocks to build Code::Blocks (with the supplied project file) or you will use autotools and friends (configure, make, make install). Make your pick.

Also make sure you read the wiki for instructions on building because something tells me you missed performing one very important step.
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on September 25, 2007, 03:57:30 pm
BTW, I just read your posts. You have mentioned that you use KDE desktop. But I use GNOME one. So can you just give GNOME desktop a try to see if the problem persists or not.

Unfortunately it wasn't as easy to swap between KDE and Gnome as I thought so I'll have to leave that for now. However, here's what I have done....

I just changed between KDE, Gnome and icewm , started codeblocks, compiled a project and started it.

No problems.

Also no such problems here on WinXP/SP2 and W2k .
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 25, 2007, 04:36:36 pm
make sure you read the wiki for instructions on building because something tells me you missed performing one very important step.

Just to clarify - up until a week ago I'd never built Code::Blocks from source at all. I'd ran all my previous installations from rpm packages. However, each time I did an update, C::B just became more & more unreliable.  Eventually, I was advised to try installing from source.

I've only compiled from source once but the finished executable still has all the same problems. I can't see anything obvious in the wiki that I've missed out - although some of its instructions are slightly different from the ones that I followed. For example, it gives the instruction make -f Makefile.unix to perform the build. That wouldn't work for me (I got an error about Makefile.unix being an invalid folder). So I just typed make (and eventually, make install). Also, I installed wxWidgets and wxGTK-devel from rpm packages, as opposed to the tar files recommended in the wiki. Other than those differences though, I seem to have done everything.

What is the important step you think I missed?
Title: Re: Settings don't get saved (svn 4454)
Post by: Biplab on September 25, 2007, 05:06:13 pm
What is the important step you think I missed?

For most of the popular Linux distributions, the following few instructions are sufficient if you check out source from SVN.
Quote
./bootstrap
./configure
make
su
make install

If you download the source tarball, you may omit the first instruction.

Personally I use Windows XP SP2 on 2 PCs and with Fedora Core 7 on one more PC. All of them has C::B installed. Apart from that I've several Linux VMs installed (Ubuntu 7.04, Ubuntu 7.10 Alpha, Fedora 7 & 8 Beta, OpenSUSE-10.3 Beta, PC-BSD-1.3, Debian Etch, PC-Linux 2007, etc) and all of them has C::B installed for testing. Why I'm writing this. Because I didn't face such problem in any of these platforms.

Several other users have also confirmed that C::B works fine with them. Still you keep on saying the following.

However, each time I did an update, C::B just became more & more unreliable.  Eventually, I was advised to try installing from source.

IMHO, you made a mess of your C::B installation. And you are blaming C::B again and again.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 25, 2007, 05:27:16 pm
I can only repeat that, up until a week ago, I'd only ever installed from rpm packages. I, personally, haven't done anything to my installation (apart from using it) until a week ago when I installed and re-built it from source code. Also, I've never performed an update because of having problems. I updated because I needed a new feature - but in every case, the problems were immediately apparent, directly after updating. So what can I have done to cause this??

For most of the popular Linux distributions, the following few instructions are sufficient if you check out source from SVN.
Quote
./bootstrap
./configure
make
su
make install

That's exactly what I did. Just for the record, I've now done a make clean and followed those same instructions again. The new executable has today's date & time but is still giving me the same erratic performance.

Immediately after re-building, I re-booted, opened a project, placed a breakpoint at a line where it should reach and pressed F8. The program launched without stopping at the breakpoint. I exited the program and hit F8 again. The same thing happened. Without doing anything I exited the program and hit F8 for a third time. This time I got the same errors that I reported in my thread about debugging problems:-

Quote
Setting breakpoints
Debugger name and version: GNU gdb 6.5
No symbol table is loaded.  Use the "file" command.

My guess is that either C::B has got out of step with something it depends on - or maybe some kind of config file or startup file has become corrupted. Is there a way to completely uninstall C::B including all it's config files (and preferably wxWidgets) so I can re-install them both fresh?
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 25, 2007, 08:25:44 pm
Since my last post I've uninstalled (using Yast) wxWidgets, wxWidgets-devel, wxGTK and wxGTK-devel (strangely, although I've been told that wxWidgets and wxGTK are the same thing, Yast doesn't consider them to be the same).

I then re-installed all 4 using the rpm packages that I originally downloaded (versions 2.8 ).

Next I went to my C::B root folder and typed make clean - then deleted the C::B executable and checked that my desktop icon was now non-functional, just to be absolutely sure the old version had gone...!

Then I typed the following:-
./bootstrap
./configure --enable-contrib
make
sudo make install


I even found an old default.conf file and used that, in case my most recent file was corrupted.

I've now got a brand new executable (dated a few minutes ago) - but it's still got the same problems....  :(

The only thing I can think of is to follow the wiki, step-by-step. However, the wiki refers to libraries such as wxWidgets 2.6.3 which I've been told is now out-of-date. Also, I already know that at least one of its instructions (make -f Makefile.unix) wouldn't work for me when I tried it, last time.
Title: Re: Settings don't get saved (svn 4454)
Post by: Biplab on September 25, 2007, 08:43:44 pm
Let me make a wild guess. Is it due to AppArmor (OpenSUSE comes with it)?? It works as a security layer providing security against malicious programs (I hope I'm correct). May be you've set the security level to the strictest one.

Check this possibility. Though I had OpenSUSE installed in my PC and I never faced such problems. But you know sometimes your Anti-Virus creates such nuisance on Windows. ;)
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 26, 2007, 07:40:36 am
Good suggestion. Under Windows I used to have spurious problems with things working erratically when I used to use Zone Alarm - and I eventually had to replace it. However, AppArmor is disabled for OpenSuse in my current setup.

I can't help feeling that this is an "out-of-step" problem. Does C::B have any other dependencies - or require a minimum level of certain other libraries - apart from wxGTK? So far I've just been concentrating on wxGTK but presumably there are other dependencies too? The annoying thing is that it all worked fine when I first installed C::B. These problems started to appear gradually, as & when I updated it - which again makes me think that I should have been updattng something else to keep in step.

Also I've noticed there's an option to install "wxGTK debug info" which I've never installed. Should I have installed that?
Title: Re: Settings don't get saved (svn 4454)
Post by: mandrav on September 26, 2007, 08:49:11 am
@johne53: why don't you try running C::B from within gdb and post a backtrace here when it crashes?
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 26, 2007, 10:15:20 am
Hi Mandrav - it's not crashing as such. It's just not working the way it used to. For example, when I press F8 to debug a project, it no longer stops if I set break points. Or to be more specific - sometime it runs the program without stopping at the break points; other times it runs the program normally (and stops at the break points); other times it doesn't even run the program. The important thing is that I'm not changing anything while this is going on. One minute it will work - the next it won't (but mostly, it won't).

It's the same with saving my Compiler & Debugger settings. If I change a setting, the change (usually) doesn't get saved. But occasionally it does. There's no logic to it at all.

To be honest, C::B isn't really useable in its current state. The frustrating thing is that I don't know how it got into this state and nothing - not even re-installing - seems to fix it....  :(
Title: Re: Settings don't get saved (svn 4454)
Post by: mandrav on September 26, 2007, 12:05:24 pm
Quote
Hi Mandrav - it's not crashing as such. It's just not working the way it used to. For example, when I press F8 to debug a project, it no longer stops if I set break points. Or to be more specific - sometime it runs the program without stopping at the break points; other times it runs the program normally (and stops at the break points); other times it doesn't even run the program. The important thing is that I'm not changing anything while this is going on. One minute it will work - the next it won't (but mostly, it won't).

So why don't you post the debugger's log here?
And while you 're at it, enable the debugger's debug log in debugger settings and post that too.

The only relevant thing I have noticed is that, when loading a project, if the active target is the debug target (and depending what I was previously doing with C::B), some times it might not pick this up and try to debug the release target (which of course will behave like you describe). In that case I switched to the release target and then back to the debug one and it worked fine from then on.
I admit I haven't been able to reproduce this in a constant manner and so it's a bit difficult to track. But this will be fixed eventually.
Still, if this is really the problem you have, then just momentarily switch to another target and then back to debug and the problem will go away.

Quote
It's the same with saving my Compiler & Debugger settings. If I change a setting, the change (usually) doesn't get saved. But occasionally it does. There's no logic to it at all.

As said before, the only reason your settings are not saved is if C::B crashes on exit. You can only verify this by running C::B from a console or, even better, from inside gdb so you can post the backtrace I asked.

Quote
To be honest, C::B isn't really useable in its current state.

Please refrain from using such bold statements.
I can see that this might have been your experience but, as you probably saw from the replies in this topic, this is not what any of us experiences. So either help us to help you by providing the info we ask for, or patiently wait until C::B works for you as you expect it to.
Really, nothing more to say.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 26, 2007, 01:17:04 pm
Maybe I should have said that in it's current state, it isn't useable by me. I wasn't speaking generally, or for anyone else.

Something interesting happened after I toggled to Release and then back to Debug. I'd started C::B from a terminal and got this output

Quote
johne53@AMD2000:~> codeblocks
-------------- Build: Debug in Ardour ---------------
Target is up to date.
Nothing to be done.

which I assume is normal. However, at the same time, the "Layout changed" dialog appeared, telling me that the Code::Blocks default layout had changed and asking if I wanted to save it. At first I hit 'No'. I then saw that it had launched a new terminal window, instead of the app's GUI. I selected Debug->Stop debugger and tried again. The "Layout changed" dialog appeared again but this time I selected 'Cancel'. This time, I saw a new dialog saying "Error - unable to stop the debug process". When I hit "OK", my app loaded normally (in the debugger) and my break point got reached. I then stopped the debugger and closed C::B. In the terminal window I then saw a message "segmentation fault". This seems to be the same with any project but unfortunately, I'm not getting the codeblocks.rpt file that you mentioned. I've searched my main partition and my home partition but it's not there.

I've also found (although I'm not yet sure how consistent this will be) that the problem of my IDE settings not getting saved seems to happen only with one particular workspace loaded. Again, I see "segmentation fault" in the terminal window but I'm not getting that codeblocks.rpt file. Is there something I need to do to enable it?
Title: Re: Settings don't get saved (svn 4454)
Post by: mandrav on September 26, 2007, 01:42:00 pm
codeblocks.rpt is generated only in windows.

Run "gdb codeblocks".
Inside gdb, type "run".
Do what you want in C::B.
If it crashes on exit, go back to the terminal with gdb running.
Type "bt".
Copy and paste the backtrace here.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 26, 2007, 02:51:11 pm
Sorry Mandrav, I don't even get to the stage of being able to produce a backtrace as something seems to be causing gdb to crash. Here's what I see in the terminal window if I type what you said and then try to debug my simple 'Hello World' app.

Code
johne53@AMD2000:~> gdb codeblocks
GNU gdb 6.5
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 "i586-suse-linux"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /usr/local/bin/codeblocks
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1234463024 (LWP 4579)]
[New Thread -1239315568 (LWP 4590)]
[New Thread -1247708272 (LWP 4591)]
[New Thread -1256100976 (LWP 4592)]
[New Thread -1264493680 (LWP 4593)]
[New Thread -1273934960 (LWP 4594)]
[New Thread -1285194864 (LWP 4595)]
[New Thread -1294054512 (LWP 4606)]
[Thread -1294054512 (zombie) exited]
[New Thread -1294054512 (LWP 4616)]
[Thread -1294054512 (zombie) exited]
[New Thread -1305478256 (LWP 4617)]

(codeblocks:4579): Gtk-CRITICAL **: gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
-------------- Build: Debug in HelloWorld ---------------
[Thread -1305478256 (zombie) exited]
Target is up to date.
Nothing to be done.

Segmentation fault

and then the terminal window throws me back to my normal command prompt (with Code::Blocks still running). Could this be because I'm running C::B within gdb and then using it to debug a second program simultaneously?
Title: Re: Settings don't get saved (svn 4454)
Post by: stahta01 on September 26, 2007, 05:03:29 pm
I can't help feeling that this is an "out-of-step" problem. Does C::B have any other dependencies - or require a minimum level of certain other libraries - apart from wxGTK? So far I've just been concentrating on wxGTK but presumably there are other dependencies too? The annoying thing is that it all worked fine when I first installed C::B. These problems started to appear gradually, as & when I updated it - which again makes me think that I should have been updattng something else to keep in step.

wxGTK depends on GTK (Gimp Tool Kit) which is also called GTK+

You might want to post what GTK+ version you use, in case it is an GTK+ issue, but it sounds to me to NOT be an GUI issue so I would not expect it to be GTK+, but wxGTK.

Tim S
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 26, 2007, 05:38:02 pm
Thanks Tim and everyone who's helping with this. I realise that it's not an everyday problem and I do want to get to the bottom of it as I was very impressed with Code::Blocks before these weird things started happening.

I have both GTK and GTK2 installed. GTK is version 1.2.10-926. GTK2 is version 2.10.6-13. I also have GTK2-devel installed (which is also 2.10.6-13) but not GTK-devel. I don't have any of the other GTK options, such as GTK1-compat-devel or any of the 'doc' libraries.

If there's a list somewhere where I could see what dependencies are needed, it would be quite simple for me to report my current versions.
Title: Re: Settings don't get saved (svn 4454)
Post by: stahta01 on September 26, 2007, 06:14:45 pm
Thanks Tim and everyone who's helping with this. I realise that it's not an everyday problem and I do want to get to the bottom of it as I was very impressed with Code::Blocks before these weird things started happening.

I have both GTK and GTK2 installed. GTK is version 1.2.10-926. GTK2 is version 2.10.6-13. I also have GTK2-devel installed (which is also 2.10.6-13) but not GTK-devel. I don't have any of the other GTK options, such as GTK1-compat-devel or any of the 'doc' libraries.

If there's a list somewhere where I could see what dependencies are needed, it would be quite simple for me to report my current versions.

Code::Blocks and wxGTK only cares about the GTK version 2 or above. So, GTK2 in your case.

Tim S
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 27, 2007, 06:12:51 pm
Mandrav - I've got to the stage where I can produce a backtrace from the "failure to save settings" problem. Here's my gdb output prior to the crash:-

Quote
johne53@AMD2000:/usr/local/bin> gdb codeblocks
GNU gdb 6.5
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 "i586-suse-linux"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /usr/local/bin/codeblocks
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1234319664 (LWP 5010)]
[New Thread -1239172208 (LWP 5021)]
[New Thread -1247564912 (LWP 5022)]
[New Thread -1255957616 (LWP 5023)]
[New Thread -1264350320 (LWP 5024)]
[New Thread -1273791600 (LWP 5025)]
[New Thread -1286108272 (LWP 5026)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1234319664 (LWP 5010)]
0xb691417c in _int_malloc () from /lib/libc.so.6

The segmentation fault happens if I try to exit C::B after changing some settings in Settings->Compiler and debugger. Note the line Failed to read a valid object file image from memory. I can't help feeling that's significant. It happens every time I launch C::B within gdb.

and here's the backtrace:-

Quote
(gdb) bt
#0  0xb695b17c in _int_malloc () from /lib/libc.so.6
#1  0xb695d0c5 in malloc () from /lib/libc.so.6
#2  0xb6b05477 in operator new () from /usr/lib/libstdc++.so.6
#3  0xb41ca463 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb85a4b0, __p=0x332439d8)
    at /usr/include/c++/4.1.2/ext/new_allocator.h:88
#4  0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb859658, __p=0x332439c0)
    at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#5  0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb859190, __p=0x332439a8)
    at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#6  0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb858c98, __p=0x33243990)
    at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#7  0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb8583e0, __p=0x33243978)
    at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#8  0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb857108, __p=0x33243960)
    at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#9  0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb855f50, __p=0x33243948)
---Type <return> to continue, or q <return> to quit---
    at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#10 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb853088, __p=0x33243930)
    at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#11 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb8501f0, __p=0x33243918)
    at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#12 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb84af10, __p=0x33243900)
    at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#13 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb83de90, __p=0x332438e8)
    at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#14 0xb41ca4a4 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_copy (this=0xbf6f7340, __x=0xb831380, __p=0xbf6f7344)
    at /usr/include/c++/4.1.2/bits/stl_tree.h:1232
#15 0xb41ebeab in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::operator= (this=0xbf6f7340, __x=@0xb2a28710)
    at /usr/include/c++/4.1.2/bits/stl_tree.h:800
#16 0xb4208362 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
    at /usr/include/c++/4.1.2/bits/stl_set.h:220
#17 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
    at parser/token.cpp:570
---Type <return> to continue, or q <return> to quit---
#18 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
    at parser/token.cpp:618
#19 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
    at parser/token.cpp:570
#20 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
    at parser/token.cpp:618
#21 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
    at parser/token.cpp:570
#22 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
    at parser/token.cpp:618
#23 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
    at parser/token.cpp:570
#24 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
    at parser/token.cpp:618
#25 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
    at parser/token.cpp:570
#26 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
    at parser/token.cpp:618
#27 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1)
    at parser/token.cpp:570
#28 0xb4208382 in TokensTree::RemoveToken (this=0x88d78d0, oldToken=0xb2a2868c)
    at parser/token.cpp:618
#29 0xb4208acf in TokensTree::RemoveToken (this=0x88d78d0, idx=1
)

The rest of the bactrace seems to repeat those TokensTree::RemoveToken lines. I can let you have them all if you like - but I got up to over 1,300 of them before finally giving up!

Hope that helps.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 27, 2007, 08:40:26 pm
Mandrav - if there isn't anything obvious in the above backtrace, don't waste too much time on it. Since posting the above info I've come to the conclusion that there's some kind of capacity problem here (at least as far as the 'failure to save' problem is concerned).

I have a particular workspace containing 20 projects, each with a Debug and Release target. 19 of the projects build Shared Object files and the last one is a GUI application. With all 20 projects present in the workspace I get the saving crash (i.e. segmentation fault) every time C::B closes (assuming I've changed a setting). If I remove some of the projects, the problem goes away. It doesn't seem to matter which projects I remove. There are 3 particular projects which I can remove and the problem reliably goes away. If I only remove 1 of them (or any combination of 2) the problem doesn't go away. But if I put those 3 projects into a smaller workspace, they don't cause any problems. Conversely, if I put them back into the original workspace, I can remove other projects and the problem still goes away.

I'm very busy over the next few days but if I get a chance next week, I'll see if I can either:-

a) find out if there's anything common to (or unusual about) those 3 projects - or
b) find out if I can home in on something more repeatable.

Thanks for your help, so far. I'm still keen to find out if that message (Failed to read a valid object file image from memory) is a bad indication. Assuming it's not normal, is there any way to find out which image couldn't be read?
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 29, 2007, 04:55:41 pm
Woohoo...! I've tracked down at least one of the situations that's been causing this strange crashing problem. I think there might be other situations too - but maybe it's best to deal with one problem at a time. Consider this C::B project (my actual project is much bigger but I can still reproduce the problem, even from this cut-down version).

To see the crash, the following steps are necessary:-

1) Add this project to a workspace (unfortunately, it doesn't crash with every workspace - but it does with the majority of them)
2) Launch a terminal window and type gdb codeblocks - followed by run
3) After C::B starts, open the workspace to which you added the project below
4) Change one or more of the global settings (for example, one of the Compiler & Debugger settings)
5) Exit Code::Blocks. At this point you get a segmentation fault and your new change(s) are lost.

Quote
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
   <FileVersion major="1" minor="6" />
   <Project>
      <Option title="Ardour" />
      <Option pch_mode="2" />
      <Option compiler="gcc" />
      <Build>
         <Target title="Debug">
            <Option output="$(#output)/ardour2/ardour-2.0.5" prefix_auto="1" extension_auto="1" />
            <Option object_output="obj/Debug/" />
            <Option type="0" />
            <Option compiler="gcc" />
            <Option host_application="ardour-2" />
            <Compiler>
               <Add option="-DDEBUG" />
            </Compiler>
            <Linker>
               <Add directory="$(#output)/ardour2/" />
               <Add directory="$(#base)/ardour2/libs/pbd/" />
            </Linker>
         </Target>
         <Target title="Release">
            <Option output="bin/Release/ardour-2.0.5" prefix_auto="1" extension_auto="1" />
            <Option object_output="obj/Release/" />
            <Option type="1" />
            <Option compiler="gcc" />
            <Compiler>
               <Add option="-O3" />
            </Compiler>
            <Linker>
               <Add directory="$(#output)/ardour2/" />
               <Add directory="$(#base)/ardour2/libs/pbd/" />
            </Linker>
         </Target>
      </Build>
      <Compiler>
         <Add option="-Wall" />
      </Compiler>
      <Linker>
         <Add library="jack" />
      </Linker>
      <Unit filename="waveview.cc" />
      <Unit filename="waveview.h" />
      <Unit filename="waveview_p.h" />
      <Extensions>
         <code_completion />
         <debugger />
      </Extensions>
   </Project>
</CodeBlocks_project_file>

Pay particular attention to the red lines. If they'd been written like this:-

<Option output="$(#output)/ardour2/ardour-2.0.5" prefix_auto="0" extension_auto="0" />
<Option output="bin/Release/ardour-2.0.5" prefix_auto="0" extension_auto="0" />

(in other words, auto prefix and extension disabled, instead of enabled) the crash doesn't occur. Similarly, if the output target filename doesn't include fullstops, the crash doesn't occur either. I hope this will go some way towards identifying the problem.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on September 30, 2007, 12:26:21 pm
Another thing that seems to be causing problems for Code::Blocks is the use of quotation marks within a #define. For example, many of my projects require that the compiler (g++) is sent a compile option taking a form similar to this:-

-DLOCALEDIR=\"/usr/local/share/locale\"

After asking on this forum I was told to implement this within C::B as a preprocessor directive (#define build option) of the form:-

LOCALEDIR=\\"/usr/local/share/locale\\"

Within the relevant project (.cbp file) this translates to an XML string entry of the form:-

<Add option='-DLOCALEDIR=\\&quot;/usr/local/share/locale\\&quot;' />

which is listed among the relevant target's Compiler options. As far as I can tell, C::B seems to tolerate a small number of these - but once I include a dozen or more I start seeing the same segmentation faults each time I try to shut down C::B.

I guess it could be the case (in fact, I hope it is the case) that I've been wrongly advised and I should be using some other syntax. However, the syntax shown above does cause the correct option to get sent to the compiler, so it seems to have some validity. In any case, I can't see why a particular text string - even if it was illegal - should cause the host program to crash.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 04, 2007, 06:38:55 am
Has anyone managed to reproduce these problems?

Or can someone comment on why these particular settings (with seemingly correct syntax) should be causing C::B to segfault?
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 14, 2007, 03:34:01 pm
I didn't managed to fix these problems so I decided to try out Linux and C::B on a completely different PC. I've chosen a different distro (64Studio, which is a Debian based Linux) and installed it on my laptop. Using SubVersion I checked out SVN 4454 of CodreBlocks (the one where I originally discovered the problems) and soon I'll be trying to build it.

I have a vague memory of needing to install a library/package called contrib but I can't quite remember where I got it from. Can anyone remind me if it comes as part of a standard SVN checkout or is there somewhere else that I need to get it from?
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 15, 2007, 08:12:02 pm
Looking back through my notes, it seems that wxGTK was the other lib that I needed to install. In fact, wxGTK, wxGTK-dev and  wxGTK-dbg are already installed on my system (version 2.6.3.2.1.5). I'm trying to use the following command set to build C::B (after first opening a terminal window and navigating to my C::B root folder)...

Quote from: Biplab
./bootstrap
./configure
make
su
make install

Immediately after the ./bootstrap command I get this error:-

Quote
You should add the contents of '/usr/share/aclocal/libtool.m4' to 'aclocal.m4'
./bootstrap: line64: aclocal: command not found

Does anyone know what this means? aclocal.m4 and libtool.m4 seem to be reasonably identical on both machines, AFAICT
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on October 15, 2007, 08:28:03 pm
the bootstrap-script starts with this lines:
Code
# Check for proper versions of autotools
# We require:
#  - autoconf 2.50+
#  - automake 1.7+, 1.9+ for make dist
#  - libtool 1.4+
you can type
Code
aclocal --version
autoconf --version
automake --version
libtool --version

and see which versions are installed, or which program is missing.

codeblocks is developped against wxWidgets 2.8.4, but I don't know where you can find it for for Suse.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 15, 2007, 08:55:09 pm
Thanks Jens, I'll try those things tomorrow. Incidentally, my laptop is running a distro called 64Studio (it's my desktop machine that runs Suse). 64Studio is supposedly a customised version of Debian Etch, if that helps.
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on October 15, 2007, 09:01:54 pm
wxWidgets 2.8.4 for debian etch can be downloaded here:
Code
http://apt.tt-solutions.com/debian/ etch main
key-import to apt's trusted keys:
Code
wget -q http://www.tt-solutions.com/vz/key.asc -O-  | sudo apt-key add -
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 16, 2007, 07:41:03 am
Thanks Jens. It turned out that only libtool was installed, not the others. Synaptic told me that the latest version of automake was 1.10. I couldn't figure out if that was earlier or later than 1.9, so I loaded 1.9. I now have the following installed:-

autoconf = version 2.61
aclocal = version 1.9.6
automake = version 1.9.6
libtool = version 1.5.22-4

and it seems to be building.... let's hope it solves my problems...!


[Edit...] No, it doesn't seem to be going very well. The make starts to falter when it needs wxWidgets (presumably because I've only installed v2.6). I didn't really understand your instruction ( wget -q http://www.tt-solutions.com/vz/key.asc -O-  | sudo apt-key add - ) but I assumed that by typing that line, it would set up that URL to be the download path for wxWidgets. I typed it in (and got the response 'OK') but Synaptic still tells me that 2.6.3 is the latest version.

I then logged in as root and tried typing 'apt-get install wxWidgets' which produces "Couldn't find package wxWidgets". 'apt-get install wxGTK' produces "Couldn't find package wxGTK". Any idea what I'm doing wrong?
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on October 16, 2007, 01:36:23 pm
You have to add the line
Code
http://apt.tt-solutions.com/debian/ etch main
to /etc/apt/sources.list (as root)
and with
Code
wget -q http://www.tt-solutions.com/vz/key.asc -O-  | sudo apt-key add -
(also as user root) Vadim Zeitlin's public-key is added to apt trusted key database.
Vadim Zeitlin signed the wxWidgets packages on tt-solutions.com (he's one of the wxWidgets developers).
Without that key you get an (overridable) error message.
"apt" is the backend for synaptic and aptitude.

You can fetch compiled nightlies for debian (etch / stable, lenny / testing, sid /unstable) from my repo.
Have a look at the latest nightlies threads.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 16, 2007, 03:55:51 pm
Sorry I haven't tried the nightlies because I specifically want to try the same s/ware version on both PC's.

I typed both of your lines into the relevant places but it seems to have screwed me up completely. If I now launch Synaptic (or try to use apt-get) I see an error looking something like this:-

Quote
'http://apt.tt-solutions.com/debian/' is not known on line 5 in source list /etc/apt/sources.list
The list of sources could not be read

Is the syntax right (e.g. should there be a space before 'etch'?)


[Edit...] Also - I've assumed that '-O-' is a letter 'O' and not a number zero.
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on October 16, 2007, 04:25:06 pm
the letter O is right, and I forgot a deb at the beginning of the line for sources.list.
Try:
Code
deb http://apt.tt-solutions.com/debian/ etch main

I'm very sorry  :?
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 16, 2007, 04:53:07 pm
Thanks for the correction. That seems to have got me a bit further - though not really a lot further. I now get this error when launching synaptic....

Quote
W: Couldn't stat source package list http://apt.tt-solutions.com etch/main Packages (/var/lib/apt/lists/apt.tt-solutions.com_debian_dists_etch_main_binary-i386_Packages) - stat (2 No such file or directory)
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on October 16, 2007, 05:52:57 pm
Did you start synaptic with root-privileges ?
If I delete "/var/lib/apt/lists/apt.tt-solutions.com_debian_dists_etch_*" manually, and after that start it as normal user, I get this message.
If you start it as root, try
Code
apt-get update
from a console (as root of course).
If that doesn't work you can post your "/etc/apt/sources.list", and I look for an error.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 16, 2007, 06:40:59 pm
Thanks.... apt-get update did the trick and I've now installed wxWidgets 2.8. Unfortunately (groan...  :( ) I still can't get C::B to build. The ./bootstrap and ./configure stages seem to go okay - but then when I run make I get this error which I think is at the linking stage):-

Quote
g++ -O2 -ffast-math -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -o .libs/codeblocks app.o appglobals.o compilersettingsdlg.o crashhandler.o dlgabout.o dlgaboutplugin.o environmentsettingsdlg.o infopane.o ipc.o main.o prefix.o printdlg.o scriptconsole.o scriptingsettingsdlg.o splashscreen.o startherepage.o -pthread  -lm -L/media/SHAREDDATA/CodeBlocks/src/src/wxAUI /media/SHAREDDATA/CodeBlocks/src/src/wxAUI/.libs/libwxaui.a /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so /usr/lib/libpangocairo-1.0.so -lXext -lXinerama -lXi -lXrandr -lXcursor -lXfixes /usr/lib/libpango-1.0.so /usr/lib/libcairo.so /usr/lib/libfreetype.so -lz -lfontconfig -lpng12 -lXrender -lX11 /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libglib-2.0.so -lrt -L/media/SHAREDDATA/CodeBlocks/src/sdk /media/SHAREDDATA/CodeBlocks/src/sdk/.libs/libcodeblocks.so -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -lpthread -ldl -Wl,--rpath -Wl,/usr/local/lib
app.o: In function `CodeBlocksApp::GetAppPath() const':
/media/SHAREDDATA/CodeBlocks/src/src/app.cpp:839: undefined reference to `wxString::wxString(char const*, wxMBConv&, unsigned int)'
app.o: In function `wxFont':
/usr/include/wx-2.6/wx/gtk/font.h:37: undefined reference to `wxFont::Init()'
/usr/include/wx-2.6/wx/gtk/font.h:37: undefined reference to `wxFont::Init()'
app.o: In function `CodeBlocksApp::OnInit()':
/media/SHAREDDATA/CodeBlocks/src/src/app.cpp:457: undefined reference to `wxZipFSHandler::wxZipFSHandler()'
app.o: In function `FileLogger::Append(wxString const&, Logger::level)':
../../src/include/logger.h:64: undefined reference to `wxString::mb_str(wxMBConv&) const'
../../src/include/logger.h:64: undefined reference to `wxString::mb_str(wxMBConv&) const'

#...and in fact, I just get hundreds of similar 'undefined reference' errors. Note that make still seems to be looking for wx2.6 which is very confusing.

[Edit...] Oops... forgot to do a 'make clean' before starting the new make. After cleaning out the old make, the new one seems to be going a lot better (!)
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on October 16, 2007, 08:09:29 pm
which version of wxWidgets is used by wx-config as standard ?
Code
wx-config --version
should answer "2.8.4" .
If not you can change the default  version wx-config uses by typing
Code
update-alternatives --config wx-config
The answer is something like
Code
Es gibt 6 Alternativen, die »wx-config« bereitstellen.

  Auswahl      Alternative
-----------------------------------------------
          1    /usr/lib/wx/config/base-unicode-debug-2.8
          2    /usr/lib/wx/config/gtk2-unicode-debug-2.8
          3    /usr/lib/wx/config/base-unicode-release-2.8
*+        4    /usr/lib/wx/config/gtk2-unicode-release-2.8
          5    /usr/lib/wx/config/base-unicode-release-2.6
          6    /usr/lib/wx/config/gtk2-unicode-release-2.6

Drücken Sie die Eingabetaste, um die Vorgabe[*] beizubehalten,
oder geben Sie die Auswahlnummer ein: 

Sorry it's german, and I don't have any english locales on my laptop.
You can than select the default version for wx-config.
On my laptop it's "/usr/lib/wx/config/gtk2-unicode-release-2.8" .

On debian systems, after running the bootstrap-script you can type "dpkg-buildpackage" from the commandline (you must be in the directory with the "debian" subdirectory), or if you are not root try "fakeroot dpkg-buildpackage".
If "dpkg-buildpackage" says something about missing dependencies you have to install the missing packages. If "libstdc++6-4.0-dev" is missing, but you have "libstdc++6-4.1-dev" installed, that doesn't matter.
Install the other packages and run
Code
dpkg-buildpackages -d
.
This overrides dependency-checking. So make sure all packages you need are installed. Instead of the "-d"-option, you can patch the "debian/control"-file:
in line 5 change "libstdc++6-4.0-dev" to "libstdc++6-4.1-dev".
Or you can use the source-package from my repository (but it's svn 4537 in the moment).
If all works correctly you should have your own build codeblocks ".deb"-packages in the directory one step higher than your working directory.
You can install them with
Code
dpkg -i path_to_package_file/package_file.deb
.
For example, when you compiled svn4537 and are still in the working-directory of codeblocks type
Code
dpkg -i codeblocks_1.0svn4537_i386.deb ../codeblocks-contrib_1.0svn4537_i386.deb ../libcodeblocks0_1.0svn4537_i386.deb ../libwxsmithlib0_1.0svn4537_i386.deb
The -dev and -dbg packages are normally not needed, if you don't want to develop youre own plugins, or debug codeblocks itself.

So, this is pretty much stuff, but I hope it helps.
Now i bring my son in the bed and than look for an answer. :D
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 16, 2007, 08:19:45 pm
Sorry, it looks like our posts coincided. The problem was just that I'd forgotten to clean out the old (incomplete) build. Having done that, C:B has finally built & installed correctly. I'll be testing it again tomorrow. Wish me luck...  :D
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on October 16, 2007, 08:57:02 pm
Sorry, it looks like our posts coincided. The problem was just that I'd forgotten to clean out the old (incomplete) build. Having done that, C:B has finally built & installed correctly. I'll be testing it again tomorrow. Wish me luck...  :D

I saw just after clicking the "Post"-button.

Nevertheless I hope it works for you.  :D

I think you should try the "debian-way" and use "dpkg-buildpackage" or if you have source-code that is not yet "debianized" you can use "checkinstall" (apt-get install checkinstall).
If you do so you can deinstall packages much easier, if something went wrong.
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 18, 2007, 11:02:54 am
After 2 days I've finally managed to build C::B and load the project that was giving me the segfaults. Unfortunately, it's still giving me segfaults - even though I'm now running a fresh build on a new PC with a different Linux distro.   :( However, I've discovered something very interesting....

When I first built C::B it initialised a file for me called default.conf. If I use that original configuration file, I don't get the segfaults. However, if I start adding global search directories, the segfaults happen pretty much every time I shut down C::B.

This is what the gcc section of my config file looked like before I added any search directories:-
Code
			<gcc>
<NAME>
<str>
<![CDATA[GNU GCC Compiler]]>
</str>
</NAME>
<INCLUDE_DIRS>
<str>
<![CDATA[/usr/include;]]>
</str>
</INCLUDE_DIRS>
<RES_INCLUDE_DIRS>
<str>
<![CDATA[/usr/include;]]>
</str>
</RES_INCLUDE_DIRS>
<LIBRARY_DIRS>
<str>
<![CDATA[/usr/lib;]]>
</str>
</LIBRARY_DIRS>
<MASTER_PATH>
<str>
<![CDATA[/usr]]>
</str>
</MASTER_PATH>
</gcc>


The above is how the file looked when it was originally configured by C::B. Here's how the same section looks, after I've added some compiler and linker search directories:-
Code
			<gcc>
<NAME>
<str>
<![CDATA[GNU GCC Compiler]]>
</str>
</NAME>
<INCLUDE_DIRS>
<str>
<![CDATA[/usr/include/;/opt/gnome/include/glib-2.0/;/opt/gnome/lib/glib-2.0/include/;$(#base)/ardour2/libs/glibmm2/;$(#base)/ardour2/libs/gtkmm2/atk/;$(#base)/ardour2/libs/gtkmm2/gtk/;$(#base)/ardour2/libs/gtkmm2/gdk/;$(#base)/ardour2/libs/gtkmm2/pango/;$(#base)/ardour2/libs/libgnomecanvasmm/;$(#base)/ardour2/libs/sigc++2/;$(#base)/ardour2/libs/pbd/;$(#base)/ardour2/libs/ardour/;$(#base)/ardour2/libs/;$(#base)/ardour2/;$(#base)/ardour2/libs/midi++2/;$(#base)/ardour2/libs/surfaces/control_protocol/;$(#base)/ardour2/libs/gtkmm2ext/;$(#base)/ardour2/gtk2_ardour/;$(#base)/CodeBlocks/src/include/wxscintilla/include/;/usr/include/wx-2.8/;/usr/include/atk-1.0/;/usr/include/gtk-2.0/;/usr/include/glib-2.0/;/usr/include/pango-1.0/;/usr/include/libgnomecanvas-2.0/;/usr/lib/glib-2.0/include/;/usr/lib/gtk-2.0/include/;/usr/lib/wx/include/gtk2-unicode-release-2.8/;]]>
</str>
</INCLUDE_DIRS>
<RES_INCLUDE_DIRS>
<str>
<![CDATA[/usr/include;]]>
</str>
</RES_INCLUDE_DIRS>
<LIBRARY_DIRS>
<str>
<![CDATA[$(#output)/ardour2/;/usr/lib;/usr/lib/cups/backend;/opt/gnome/lib;$(#base)/ardour2/libs/;]]>
</str>
</LIBRARY_DIRS>
<MASTER_PATH>
<str>
<![CDATA[/usr]]>
</str>
</MASTER_PATH>
</gcc>

With this second configuration I get segfaults almost every time I exit C::B (and any changes that I've made to the global settings get lost). Can anyone see anything obviously wrong in the updated config file?
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 21, 2007, 10:57:31 am
Well I’ve provided quite a lot of information on this problem now, so can I assume from the lack of response that my postings don’t seem to show anything obviously wrong?

Reluctantly I’ve had to conclude that C::B isn’t yet suited to complicated projects like the type I’m working with. In this particular case I could probably break the project down into smaller sub-projects and I’m fairly confident that this would eventually make the problem go away. However I can envisage situations in the future where it simply won’t be possible to break up projects like this.

Before I give up on C::B is there any developer who’d like to receive a copy of this project to see if they can reproduce (and hopefully fix) the problem? I’ve reproduced it myself with 2 separate builds of C::B installed on different PC’s with different distributions of Linux. Therefore hopefully, it will be easy to replicate on somebody else’s system. If I were to include all the source modules it would come to around 600MB (uncompressed) so I’d probably need to supply it on CD ROM.

Thanks to everyone for trying to help.
Title: Re: Settings don't get saved (svn 4454)
Post by: thomas on October 21, 2007, 01:47:27 pm
Two questions and a suggestion:

Q1: You are talking about default.conf and adding search paths. Do I understand you are editing that config file manually?

Q2: Have you tried disabling the code completion plugin? Code completion uses the search path information to <don't actually know what it does>. Thus, if changing search paths causes a crash, then CC is one easy thing that can be ruled out by disabling the plugin.

Suggestion: If you want someone to look at the project, it would probably be easiest to make a tarball of the whole source tree and provide a download URL. If it's sources and gzipped, those 600 MB should be no more than maybe 200-250 MB packed, that's 3-4 minutes of download time, no big issue (remember that this forum can be read by a million people, though... so only do this if your sources are really meant to be open).
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 21, 2007, 02:20:23 pm
Q1: You are talking about default.conf and adding search paths. Do I understand you are editing that config file manually?
No - I extracted the above text just so people can see what kinds of thing are causing this problem but in fact, I'm adding my search paths from within C::B. I just wanted to know if there's anything wrong about the way I'm typing the path names. For example, can I (as I have done) use global variables there? And does it matter whether or not the path names end in a forward slash? That sort of thing.


Q2: Have you tried disabling the code completion plugin?
AFAIK it's not enabled (unless it's enabled by default). I haven't personally installed or enabled any plug-ins.


Suggestion: If you want someone to look at the project, it would probably be easiest to make a tarball of the whole source tree and provide a download URL. If it's sources and gzipped, those 600 MB should be no more than maybe 200-250 MB packed, that's 3-4 minutes of download time, no big issue
Thanks for the suggestion, Thomas - but the bottleneck would be my upload speed. My broadband connection only offers around 256Kb upload speed so to place the code on a suitable URL would take me around 6 hours (and that's assuming that nothing goes wrong...!)

Would the workspace and projects be of any use without my source files? That would make it a lot simpler.
Title: Re: Settings don't get saved (svn 4454)
Post by: Jenna on October 21, 2007, 02:53:16 pm
Q2: Have you tried disabling the code completion plugin?
AFAIK it's not enabled (unless it's enabled by default). I haven't personally installed or enabled any plug-ins.

Yes, it's enabled by default.
You can disable it under "Plugins -> Manage Plugins" .

You have "/opt" in your include-dirs. Where did you download the packages from ? Normally "/opt" should not be used under debian afaik. Try to use only packages that belong to your debian-distribution (e.g. libglib2.0-dev).
You also have very much include-paths pointing to ardours-subdirs. Is it a development-version of ardour2 or just the source-code?
Are you sure that no header-files with the same name exist in more than one of the include-dirs?
Title: Re: Settings don't get saved (svn 4454)
Post by: johne53 on October 21, 2007, 06:08:45 pm
Jens - don't worry too much about the presence of /opt - it's simply a leftover from the fact that I was originally running under OpenSuse. In any case....


Thomas
- you've had a real flash of inspired genius with that suggestion about the Code Completion plug-in. Disabling it makes the problem go away on both machines. Re-enabling it makes the problem come back on both machines. I think you might have found the cause!

In fact, here's something interesting I discovered whilst messing about with all this.... it so happens that the first of my compiler (global) search directories is /usr/include/  Suppose I have the CC plugin enabled and I change that entry to usr/include/ (in other words, I delete that initial forward slash). Save this. Shut down C::B and re-start it. Now go to Manage Plugins and attempt to disable the CC plugin. On my machines (currently running SVN 4475) this will cause the Manage Plugins window to consistently crash, producing the error Xlib: unexpected async reply (sequence 0xd426)!

Looks like there might be something flaky in that part of the code.
Title: Re: Settings don't get saved (svn 4454)
Post by: TDragon on October 21, 2007, 08:21:01 pm
Looks like there might be something flaky in that part of the code.
You have no idea. I'm actually quite surprised that it took 5 pages for someone to mention the CC plugin; it has a long history of causing hard-to-pin-down crashes.
Title: Re: Settings don't get saved (svn 4454)
Post by: thomas on October 22, 2007, 09:56:45 am
Thomas - you've had a real flash of inspired genius with that suggestion about the Code Completion plug-in. Disabling it makes the problem go away on both machines.
Actually I'm well-known and hated for the fact of blaming code completion as the first thing whenever someuse says the word "crash". Unluckily, I'm correct with that guess 99% of the time, too. :(

I'm actually quite surprised that it took 5 pages for someone to mention the CC plugin; it has a long history of causing hard-to-pin-down crashes.
To narrow down the source of the crash, please try disabling all contrib plugins first, and if that does not help, disable the "core" plugins one by one (start with CodeCompletion).
Not quite 5 pages. :)

If I read that message correctly ("unexpected async reply"), it seems like the plugin calls GUI functions concurrently from several threads, which X doesn't like?