Upgrading a Windows (binary) installation

[johne53]

My copy of C::B dates back to about last April and it's time for an upgrade. I'm running the Windows version, installed from a straight setup.exe file. If I install the latest version (8.02, I believe) can I just overwrite my existing copy (i.e. install into the same folder) or is it best to uninstall the old copy first? The main thing is that I don't want to lose things I've set up, such as personal settings and search directories etc.

[dmoore]

you should be able to clear out the codeblocks application folder without hurting your settings. you can even install multiple copies of C::B in different folders. They will share the same settings (or use unique settings if you start codeblocks using the --profile=myprofile switch).

on windows, personal settings usually get stored in "Documents and Settings/user/Application Data/codeblocks"

just be aware that some plugins might save settings file that the newer version of the plugins might have broken compatibility with (I can't confirm that's true, it's just possible). if you get weird behavior after you upgrade, you might need to clean out some of the old plugin settings files (just rename them rather than delete them). (I can recall the keybinder plugin having this problem in the past, maybe not anymore)

btw, 8.02 was released Feb '08. If you are using a copy from April what are you using? A nightly, if so I would suspect you would want to upgrade to a more recent nightly build rather than lose features. There's been some nice improvements since the last release and the code is pretty stable.

[johne53]

I just checked again and it's older than I thought - April 07, not April 08!!

Are the nightlies only available in source code? I can build from source if absolutely necessary but I'm trying to cut down on the clutter and install binaries, where available.

[Jenna]

Are the nightlies only available in source code?

No.

The actual nightlies can be found in the topics of the nightlies thread http://forums.codeblocks.org/index.php/board,20.0.html.

The windows nightlies (or the download-links) are announced in the first post, nightlies for other OSes (mainly some linux-distros) can be found in the replies.

[johne53]

Oh no! Why did I upgrade??

I just upgraded to the latest nightly but I seem to have two immediate problems.

Problem #1: My project contains one file with the extension ".s".  I've no idea what this file does but it seems to be 8086 assembler. A typical section looks like this:-

Code

	pushl %ebp
	movl %esp, %ebp

	#; save %edi
	pushl %edi
	
	#; the real function

	#; if nframes == 0, go to end
	movl 12(%ebp), %ecx #; nframes
	cmp	$0, %ecx
	je	.AG_END

	#; create the gain buffer in %xmm1
	movss	16(%ebp), %xmm1
	shufps	$0x00, %xmm1, %xmm1
	
	#; Check for alignment

	movl 8(%ebp), %edi #; buf 
	movl %edi, %edx #; buf => %edx
	andl $12, %edx #; mask bits 1 & 2, result = 0, 4, 8 or 12
	jz	.AG_SSE #; if buffer IS aligned

This file never caused a problem before but it's now throwing up dozens of errors looking like this:-

F:/ardour2/libs/ardour/sse_functions.s:27: Warning: .type pseudo-op used outside of .def/.endef ignored.
F:/ardour2/libs/ardour/sse_functions.s:27: Error: junk at end of line, first unrecognized character is `x'

Can anyone help here??

Problem #2: Pressing F8 no longer launches my debugger (gdb). The Debugger window says Building to ensure sources are up-to-date but after the sources have been checked, the debugger doesn't get launched.

The first problem is particularly baffling because my compiler hasn't actually changed so I don't understand why it should be unhappy with that source file simply because the IDE changed.... 

[dmoore]

isn't #2 related to #1? (you can't debug because you can't successfully build?)

on #1, are you sure you are running the same compiler? presumably the .s files are assembler files, and gcc should understand them without any help from C::B. have you tried to compile from that file from the command line? You might want to switch on full compiler logging (in settings -> compiler and debugger) to see what is getting called by C::B.

[MortenMacFly]

Can anyone help here??

If you have never compiled them before disable the compilation in the project settings of the target(s) in question.

[johne53]

I went back to the previous version and noticed that the particular module was listed with a "grayed out" appearance and previously, it was obvioulsy never getting compiled. Fortunately, that didn't matter because it was only relevant (i.e. only ever required by the linker) on the ARCH_86 platform. For the time being I've taken your advice and removed it from all targets.

Having said that, the debugger still won't run, even for a very simple app. The red button lights up (as though it is running) but it never launches the app or reaches any break points. However, I'm seeing these two lines in the debugger output window which I don't normally see:-

> catch throw
Catchpoint 1 (throw)

Is that an indication that something's wrong?

[Jenna]

I went back to the previous version and noticed that the particular module was listed with a "grayed out" appearance and previously, it was obvioulsy never getting compiled. Fortunately, that didn't matter because it was only relevant (i.e. only ever required by the linker) on the ARCH_86 platform. For the time being I've taken your advice and removed it from all targets.

Having said that, the debugger still won't run, even for a very simple app. The red button lights up (as though it is running) but it never launches the app or reaches any break points. However, I'm seeing these two lines in the debugger output window which I don't normally see:-

> catch throw
Catchpoint 1 (throw)

Is that an indication that something's wrong?

Try it with "Settings -> Compiler and debugger... -> Debugger settings -> Catch C++ exceptions" turned off.
On my system (debian 64-bit) C::B crashes if I have it checked, but my app does not make use of exceptions.

I did not try to find out the cause for the crash, because there are some other things I work on at the moment.

[johne53]

Thanks Jens. That seems to have done the trick. My (very small) test app was much too simple to be throwing exceptions so I don't know what the problem might be.