Compiling and runtime problems on Raspberry PI

[Miguel Gimenez]

On the Raspberry PI (with a Debian Wheezy derivative OS) I found two problems, one compiling and one on runtime:

Tested with rev 10218: FileManager doesn't compile, it complains about sdk.h not found. Checking the command line, there is a -I../../../../src/include (four ../ groups) and another with five groups. Changing the makefile removes the first include and compiles:

Code

113c113
< DEFAULT_INCLUDES = -I. -I$(srcdir)
---
> DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/src/include

I'm building from trunk/src/build with ../configure and make

-----

The runtime error occurs with Rev 10225 but not with 10218. While loading compilers there is a segmentation fault and GDB backtrace shows (from memory, as I've returned to 10218):

#0 CompileOptionsBase::GetVar()
#1 CompileOptionsBase::SetIncludeDirs()

I suppose the problem is related to Rev 10223, as SetIncludeDirs() was changed there, but I don't know where SetIncludeDirs() calls GetVar(), and debugging on Raspberry is a pain.

Thank you.

[MortenMacFly]

Did you completely clean before doing a rebuild? The API has changed, so the binary might be corrupt if you linked against old object files. At beast, do a fresh checkout into a new directory and also don't forget to remove any old instance and run the update scripts...

[Miguel Gimenez]

Didn't clean. I've done a fresh checkout and now Codeblocks 10229 runs cleanly.

Abot the update script. I don't use it. In the BUILD file the compiling instructions for Unix are:
  ./bootstrap
  ./configure
  make
  sudo make install

so no call to update is required.

I understand, at least in Windows, that calling update.bat is needed when compling from inside Codeblocks, but not when compiling from command line. Is this correct?




Regarding the compilation of FileManager issue, is still failing claiming for sdk.h:

Code

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../../../src/plugins/contrib/FileManager -I../../../../src/include -I/usr/lib/arm-linux-gnueabihf/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../src/include -I../../../../../src/sdk/wxscintilla/include -I../../../../../src/include/mozilla_chardet -I../../../../../src/include/mozilla_chardet/mfbt -I../../../../../src/include/mozilla_chardet/nsprpub/pr/include -I../../../../../src/include/mozilla_chardet/xpcom -I../../../../../src/include/mozilla_chardet/xpcom/base -I../../../../../src/include/mozilla_chardet/xpcom/glue -ansi -DTIXML_USE_STL -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -D__FAM__ -MT FileExplorerUpdater.lo -MD -MP -MF .deps/FileExplorerUpdater.Tpo -c ../../../../../src/plugins/contrib/FileManager/FileExplorerUpdater.cpp  -fPIC -DPIC -o .libs/FileExplorerUpdater.o
In file included from ../../../../../src/plugins/contrib/FileManager/FileExplorerUpdater.cpp:9:0:
../../../../../src/plugins/contrib/FileManager/se_globals.h:10:17: fatal error: ../../../../src/include/sdk.h: No such file or directory
compilation terminated.

Thank you

[stahta01]

To do it a second time you need to cleanup what you did the first time.
I guessed on the correct location for the "sudo make uninstall"
The other likely location is right before the install.

NOTE: Sometimes you do need to do a complete new SVN or source code checkout instead of the below commands.
Edit2: Often you just need to delete the PCH files that are named sdk.h.gch and the other one that ends with gch.

Tim S.

Code

  ./bootstrap
  ./configure
  sudo make uninstall
  make clean
  make
  sudo make install

[oBFusCATed]

Code

  ./bootstrap
  ./configure
  sudo make uninstall
  make clean
  make
  sudo make install

Just to make a note on these commands. sudo make uninstall must be executed, before doing svn update and before ./bootstrap. If you do it after these two then you're using the new build system and it might not do what you expect, due to changes in the build system. Most of the times it will work, but in the rare occasion when we change something in the name of files or their locations bad things will happen!