Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back

[Feneck91]

After 3 days to be able to compile Code::Blocks from scratch under ubuntu, I let here my experience...
STEP by STEP for neebies like me (under linux) !

-----------------------------------------
| Installing and upgrading Cobe::Blocks |
-----------------------------------------

------------------------
 Linux (done on Ubuntu)
------------------------

STEP 1: INSTALLING
-------------------
1> Run Ubuntu Sofwate Center
2> In seach, type "codeblocks" and select "Code::Blocks IDE" item and clic "Install" button.
3> Clic "More Info" button and select "add-ons":
3.1> The GNU Debugger (gdb)
3.2> Contrib plugins for Code::Blocks IDE (codeblocks-contrib)
3.3> DO NOT SELECT: "wxWidgets Cross-platform C++ GUI Toolkit (GTK+ development) (libwxgtk2.8-dev)"
3.3> DO NOT SELECT: "wxWidgets Cross-platform C++ GUI Toolkit (common support files) (wx-common)"
4> Apply changes

Code::Blocks is now installed.

STEP 2: UPDATING
-----------------
To compile Code::Blocks we need
- GCC compiler (Is installed by default into Ubuntu install, else you need to install it).
- Code::Blocks itself
- wxWidgets library (I have choose to compile it by myself because if new wxWidgets version is published this help will be always correct, and you can choose to compile Code::Blocks with wxWidgets version upper than 2.8.x (2.8.12 when I writting these lines), 2.9 or 3.0 (not published yet) if you want).
- SVN tp get Code::Blocks sources from SVN repository.
- Lot of libraries to compile Code::Blocks plugins

1> Install SVN tool, I have choosen RabbitVCS (but you can choose any other), visit the following link and download your deb file to install it:
    - RabbitCVS official web site: http://rabbitvcs.org/
    - Download RabbitCVS deb file: http://wiki.rabbitvcs.org/wiki/download
  For ubuntu, type commands on terminal:
    - sudo add-apt-repository ppa:rabbitvcs/ppa
    - sudo apt-get update
    - sudo apt-get install rabbitvcs-core rabbitvcs-nautilus rabbitvcs-thunar rabbitvcs-gedit rabbitvcs-cli
2> Reboot to be able to use context menu of RabbitVCS.
3> Create Folder "CodeBlocksIDE", right clic into this folder and select "RabbitVCS SVN > Checkout..."
4> Type into URL field "svn://svn.berlios.de/codeblocks/trunk", destination update automatically with "your folder"/codeblocks folder, clic "OK" button.
    - All source code of Code::Blocks is checked out
5> Download BOOST library. Download wxWidgets (2.8.12) when I'm writting these lines.
    - Link: http://www.boost.org/
6> Install libgtk, type on termnal: "sudo apt-get install libgtk2.0-dev"
7> Download and compile wxWidgets
7.1> Download wxWidgets. Download wxWidgets (2.8.12) when I'm writting these lines.
        - Link: http://www.wxwidgets.org/downloads/
        - Choose: wxAll - all wxWidgets ports (other formats: bz2, zip)
7.2> Run commands:
        cd wxWidgets-2.8.12
        mkdir build_gtk2_shared_monolithic_unicode
        cd build_gtk2_shared_monolithic_unicode
        ../configure --prefix=/usr --enable-xrc --enable-monolithic --enable-unicode --enable-official_build --enable-optimise
        make
        sudo make install
        sudo ldconfig
     You can also make a batch file to make automatically 7.x steps:
        #--------------------------------------------------------------------------------------------------
        #!/bin/bash
        mkdir wxwidgets
        cd wxwidgets
        wget http://prdownloads.sourceforge.net/wxwindows/wxWidgets-2.8.12.tar.bz2
        tar xjf wxWidgets-2.8.12.tar.bz2
        cd wxWidgets-2.8.12
        mkdir build_gtk2_shared_monolithic_unicode
        cd build_gtk2_shared_monolithic_unicode
        ../configure --prefix=/usr --enable-xrc --enable-monolithic --enable-unicode --enable-official_build --enable-optimise
        make
        sudo make install
        sudo ldconfig
        wx-config --list
        cd ../..
        #--------------------------------------------------------------------------------------------------
8> Build Code::Blocks
8.1> Build Code::Blocks core
        - Run Code::Blocks and load project: "your folder"/codeblocks/src/CodeBlocks-unix.cbp
        - Menu: Build>Build Workspace
        - Menu: File>Close Workspace
8.2>  Build Code::Blocks plugins
8.2.1> Download libraries: plugins need libraries to be able to compile
     You can also make a batch file to make automatically 8.2.1.x steps:
        #--------------------------------------------------------------------------------------------------
        #!/bin/bash
        #
        #---------------------
        # Needed by libfam-dev
        sudo apt-get install libfam0
        #---------------------
        # File Manager Plugin needs FAM
        sudo apt-get install libfam-dev
        #---------------------
        # NassiShneiderman Plugin needs BOOST
        sudo apt-get install libboost-thread-dev
        #---------------------
        # wxSpellChecker Plugin needs hunspell
        sudo apt-get install libhunspell-dev
        #--------------------------------------------------------------------------------------------------

8.2.1.a) File Manager Plugin needs FAM so we need to install it. In directorymonitor.cpp:
            This line doesn't compile: #include <fam.h> //USES EITHER GAMIN OR FAM (IDENTICAL FILE MONITORING APIS)
          To install it, type command on terminal:
              sudo apt-get install libfam0                <---- Needed by libfam-dev          
              sudo apt-get install libfam-dev
8.2.1.b) NassiShneiderman Plugin needs BOOST so we need to install it. In CParser.cpp:
            These lines doesn't compile: #include <boost/spirit/include/classic.hpp>
                                         #include <boost/spirit/include/classic_core.hpp>
                                         #include <boost/spirit/include/classic_symbols.hpp>
                                         #include <boost/spirit/include/classic_confix.hpp>
          To install it, type command on terminal:
              sudo apt-get install libboost-thread-dev
8.2.1.c) wxSpellChecker Plugin needs hunspell so we need to install it. In hunspellInterface.cpp:
            These lines doesn't compile: #include "hunspell/hunspell.hxx"
          To install it, type command on terminal:
              sudo apt-get install libhunspell-dev
8.2.2> Compiles plugins
        - Run Code::Blocks (if not already done) and load project: "your folder"/codeblocks/src/ContribPlugins-unix.workspace
        - Menu: Build>Build Workspace
        - Menu: File>Close Workspace
9> Run "your folder"/codeblocks/src/update
10> It is done, to run code::blocks from this build, run "your folder"/codeblocks/src/output/run.sh

You can copy the output everywhere and run Code::Blocks with this run.

When running SpellChecker is not correctly configure, seems to missing some language files
Any idea ?
libFileManager cannot be loaded too.

[MortenMacFly]

When running SpellChecker is not correctly configure, seems to missing some language files
Any idea ?

The language files are not provided, as they are too large. You can (however) download / use the once of OpenOffice/LibreOffice etc.. Look inside the folder:
[C::B_SVN]\src\plugins\contrib\SpellChecker\dictionaries\
...for a "readme.txt" and read yourself through it. This will provide you with more information.

[Jenna]

I suggest any newbies not to follow the above instructions, unless you really know what you do.

Use the official wxWidgets development packages provided by ubuntu.

Using your own wxWidgets packages only makes sense, if you want to contribute porting C::B to them.
wx 2.8.xx should work out of the box,  wx >= 2.9 does not work with C::B at the moment !!

Not only newbies will probably run in trouble, if they install their own packages into the systems folders. Using folders below the users home-directory works quite fine.
You can break your entire system, if you mix selfcompiled binaries (wx2.8.12 in this example) with officially provided packages of the (more or less) same sources.
Package maintainer often patch the official sources to fit the systems need or policies, overwriting the official binaries with your own can be dangerous.

The uninstall mecahnism of software created with automake (make uninstall) can lead to unexpected behaviour.
If you really want to install into system-folders, you should create packages, that can be removed cleanly.
Either create real packages (debian/ubuntu, rpm or whatever your distro provides) or use checkinstall to create packages on the fly.

If you do it as the OP suggested, you will most likely not get support in this forum, if the problems are related to the self-build stuff.

By the way, boost is also part of debian/ubuntu and all other major distros and the possible problems you can get if you do not use these packages are the same as with wxWidgets.

Be warned !

[Feneck91]

Ok jens, no problem with it. If I remove point 7 (building own 2.8.x wxWidgets) and modify points :

3.3> SELECT: "wxWidgets Cross-platform C++ GUI Toolkit (GTK+ development) (libwxgtk2.8-dev)"
3.4> SELECT: "wxWidgets Cross-platform C++ GUI Toolkit (common support files) (wx-common)"

Is this like good for you ?

I didn't write all to bother you. Just:

• I'm linux newbie and I have taken 3 days to compile my own Code::Blocks on linux from SVN like I do in Windows platform.
• Looking the Code::Blocks wiki, a lot of plugins doesn't compile.
• I'll need wxWidgets for my project (2.9.2) and would know how to build it.
• For boost,I just create a new ubuntu installation, and without sudo apt-get install libboost-thread-dev NassiShneiderman cannot compile. Perhaps another command line to install Boost ?
• And I would like to have the last Code::Blocks version without using Nightly Build.

And it's funny, plugins are not all the same from linux and windows, some are not exists into windows platform.
libFileManager cannot be loaded.... I don't know why, certainly a missing library.
Sorry for this post, you looks angry, but it was done to help user as I could, if you want you can delete it.

Best regards.

[Jenna]

Here is my "short" version of what should be enough to build and install C::B from sources in debian/ubuntu.
It should work similar for the most major-distros, but the package names and the package-manager commands are slightly different.

On debian (and ubuntu and other derivates of debian) you need at least the following packages:

gcc, g++, make, automake, libtool, libwxgtk2.8-dev, wx-common, zip, libbz2-dev, zlib1g-dev and libstdc++6-4.x-dev (the exact version depends on your compiler, x can be 3, 4, 5 or 6 at the moment).
Install them by using

Code

sudo apt-get install gcc g++ make automake libtool libwxgtk2.8-dev wx-common zip libbz2-dev zlib1g-dev libstdc++6-4.6-dev

For some plugins you need additional development packages:
libgtk2.0-dev for codenippets and mousesap,
libgamin-dev for filemanager,
libboost1.40-dev or libboost-dev >= 1.40 (depending on your distribution) for the nassi-shneiderman plugin,
libhunspell-dev for the spellchecker-plugin.

To fetch the svn-sources you also have to install subversion:
Create a folder where you want the C::B sources, change directory (cd) to it and call:

Code

svn co svn://svn.berlios.de/codeblocks/trunk .

then run
./bootstrap
./configure --prefix=[/where/codeblocks/should/be/installed/to] --with-contrib-plugins=all
make
make install

Instead of all for contrib-plugins, you can chose only some of them, or exclude some of them, see ./configure --help for details.

Normally there is no need to do anything with ldconfig, because the (re)linking should be done correctly by the installation process.

Now you can run C::B with /where/codeblocks/should/be/installed/to/bin/codeblocks.

There should be no need to compile any packages on your own (except of C::B of course).

But if you want to avoid this also, just install C::B from my repo.
You do not need the most of the packages above in this case of course.

[Folco]

I fully agree with Jens. I do not recommend the procedure of the first post. I usually install or upgrade with this method and all works fine. All the packages I use are official (wxWidgets, Subversion), and are part of Ubuntu repositories.

I recommand to add "gdb" in the apt-get line provided by Jens.

(except that I have to add "/usr/local/lib" in /etc/ls.so.conf, then running ldconfig)

[BentFX]

I just spent several hours fighting with a new codeblocks build.


Build commands...

Code

./configure --with-contrib-plugins=all
make
sudo make install

Build finishes without error. I'm unable to tell if there were any meaningful warnings.

Running codeblocks fails with...

Code

codeblocks: symbol lookup error: codeblocks: undefined symbol: _ZTI17wxScrollingDialog

I can run from the script at codeblocks-10.05/src/src/codeblocks or codeblocks-10.05/src/src/.libs/lt-codeblocks, with these errors in the startup log.

Code

<snip>
Scanning for plugins in /usr/local/lib/codeblocks/plugins
/usr/local/lib/codeblocks/plugins/libwxsmithcontribitems.so: not loaded (missing symbols?)
/usr/local/lib/codeblocks/plugins/libwxSmithAui.so: not loaded (missing symbols?)
/usr/local/lib/codeblocks/plugins/libwxsmith.so: not loaded (missing symbols?)
Loaded 35 plugins
</snip>

After much googling and struggling I realized it was not finding libraries which did exist in /usr/local/lib...

Had to run

Code

sudo ldconfig

It sorted all issues, and I'm up and running 10.05.

It should be part of the build instructions, or better be run by "make install."

All it does is tell the system to reexamine and cache the current list of installed libraries. It is not a destructive command, and it doesn't "relink" anything.

EDIT:
System info...
Ubuntu 10.04 amd64
wxWidgets 2.8.10(distro) & 2.9.2(built) linked to 2.8.10(after build errors )

[oBFusCATed]

Had to run

Code

sudo ldconfig

It sorted all issues, and I'm up and running 10.05.

It should be part of the build instructions, or better be run by "make install."

All it does is tell the system to reexamine and cache the current list of installed libraries. It is not a destructive command, and it doesn't "relink" anything.

And why would you need to do it?
On an ages old Centos 5.6 I do not have to run it.

p.s. Have you tried to use the Jens nightlies repo? If you don't have to patch C::B with your patches, this is far more easier.
p.p.s. Keep in mind that what you're doing is wrong. On modern distros "make install" must be called only by the package manager/generator!

[BentFX]

And why would you need to do it?

Quite simply, because it solved the problem with the libraries not being found.

On an ages old Centos 5.6 I do not have to run it.

That's all well and good. Two questions come to mind. If you do run it, does it break anything? Does the system even use ldconfig to catalog the installed libraries?

p.s. Have you tried to use the Jens nightlies repo? If you don't have to patch C::B with your patches, this is far more easier.

Doesn't matter now, does it? Did I say I was angry about the difficulties. I like to build from source. And generally don't enjoy nightlys. Like I said I'm up and running, and it was only after running ldconfig.

p.p.s. Keep in mind that what you're doing is wrong. On modern distros "make install" must be called only by the package manager/generator!

I don't understand??? "make install" is part of the published build instructions??? I guess it makes sense if you hold your head just right... On my box I am the "package manager", so I run "make install" when I build a program from source.

[oBFusCATed]

I like to build from source. And generally don't enjoy nightlys. Like I said I'm up and running, and it was only after running ldconfig.

Then why are you building from SVN sources ?
Or using a binary distro? If you like to build source packages install a source based distro like Gentoo

I don't understand??? "make install" is part of the published build instructions??? I guess it makes sense if you hold your head just right... On my box I am the "package manager", so I run "make install" when I build a program from source.

Because:
1. "make uninstall" is quite unreliable
2. Have you seen that we ship both debian and redhat build system files?
3. It is easier to maintain in the long run.
4. The main package manager will manage the dependencies for C::B correctly.

[BentFX]

Then why are you building from SVN sources ?
Or using a binary distro? If you like to build source packages install a source based distro like Gentoo

I didn't build from the SVN. I built from the released source at http://www.codeblocks.org/downloads/25

Nowhere on that page does it suggest that I shouldn't build from the source. Possibly if this is something the Codeblocks community discourages, maybe the sources should not be available, or at least a prospective downloader could possibly fill out a questionnaire.

I have no intention of installing a new distro simply because someone on a forum told me I'm incapable of keeping track of a few programs built from source..

Because:
1. "make uninstall" is quite unreliable
2. Have you seen that we ship both debian and redhat build system files?
3. It is easier to maintain in the long run.
4. The main package manager will manage the dependencies for C::B correctly.

1. Understood. That's why it goes into /usr/local.
2. Yes, I chose debian.
3. Possibly.
4. This is the same as 3.

Fact remains!!! If the system isn't finding libraries that are installed "RUN LDCONFIG!!!" How else would you solve the issue brainiac? ANSWER THAT!!! If running ldconfig solves the issue, what would "your" solution be?

I've been running c::b since 2006 and this is the first issue since then that I've really had problems with. It was running "ldd" to get info for the post that led me to the answer. I ran ldconfig and it solved the issue.

I never should have posted, please forgive me. No don't! Really I'd prefer you don't.

As a final bit I'll ask again... How do you help the system find libraries it should already find? What's your workaround?

EDIT:
G-d that pisses me off. You seem to hate the "system tool" ldconfig. And due to that dislike of a tool that will sort out the system not finding libraries, you turn this into a attack saying I'm an idiot for building the released source. I haven't posted here since back around 2006 and will delete my account today, as long as that option exists.

And the question remains... What is your fix when the system doesn't find libraries that obviously exist?

[oBFusCATed]

I asked for the explanation why ldconfig is needed, so we can have a reason to add it to the "make install" process.
I don't know why it is needed. If I remember correctly (from my slackware days) ldconfig is needed, when you change the /etc/ld.so.conf file.
Make install doesn't change that file. If it does you should fill a bug report!
If you've changed the file yourself you should make sure to call the ldconfig. Case closed.

p.s. Have you tried "apt-get install codeblocks"? As far as I know c::b 10.05 is available in Ubuntu.
p.p.s. G-d that pisses me off, you seem to hate the system tools apt-get and dpkg, then why you use ubuntu/debian... Joking af course  :twisted:
p.p.p.s. I personally prefer installing software with the package manager, thus is why I've migrated my work setup from make install to building rpm-s + installing them with rpm

[BentFX]

When I said ldconfig didn't relink anything I meant in a compile/link sense. ldconfig does manage symbolic links to shared libraries and caches those filenames in ld.so.cache. ld.so.conf is configuration of where ld.so looks for libraries. Yes when ld.so.conf is changed you must run ldconfig. In addition when new dynamic libraries are added to the system you must also run it.

From the ldconfig man page:

ldconfig, being a user process, must be run manually and has no means of dynamically determining and relinking shared libraries for use by ld.so when a new shared library is installed.

This non-dynamic behavior is listed as a bug. Apparently they also would like to see it as an automatic feature.

From http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

When you install a new version of a library, you install it in one of a few special directories and then run the program ldconfig(8 ). ldconfig examines the existing files and creates the sonames as symbolic links to the real names, as well as setting up the cache file /etc/ld.so.cache (described in a moment).

...

Searching all of these directories at program start-up would be grossly inefficient, so a caching arrangement is actually used. The program ldconfig(8 ) by default reads in the file /etc/ld.so.conf, sets up the appropriate symbolic links in the dynamic link directories (so they'll follow the standard conventions), and then writes a cache to /etc/ld.so.cache that's then used by other programs. This greatly speeds up access to libraries. The implication is that ldconfig must be run whenever a DLL is added, when a DLL is removed, or when the set of DLL directories changes; running ldconfig is often one of the steps performed by package managers when installing a library.

EDIT:
p.s. Nope 8.02 is current in Synaptic.
p.p.s. If it is available I do use apt. I wanted to update my c::b to get wxGLCanvas support in wxsmith. I wanted my new c::b linked against the newest wx. Unfortunately that isn't currently possible. I did build wx 2.9.2 and have it properly installed alongside the earlier releases in /usr. wx-config sees it and works with it correctly. But c::b doesn't want to play with it yet.
p.p.p.s. Yes! Ultimately I should reconfigure my toolchain to build apt packages. But this isn't going to be accomplished today.

EDIT AGAIN:
Please understand I don't pile on my system with programs built from source. If I did the need to run ldconfig would have come as a given, and I never would have been drawn to the forum. I kinda kick myself for not realizing it sooner. When ldd says a newly installed program can't find its libraries, and the libraries exist, running ldconfig is the only logical first troubleshooting step.

[Jenna]

It should be part of the build instructions, ...]

Possily you should read more carefully:

http://wiki.codeblocks.org/index.php?title=Compiling_Code::Blocks_in_Linux_%28applies_to_all_distros%29#Resolving_issues

[...] or better be run by "make install."

No.
On recent systems, make install relinks the libraries, so ldconfig is normally not needed (more exactly, libtool does this).

I have several versions of C::B in parallel on my system, each of them uses the correct set of libraries, which would not work, if I had to use ldconfig, of course.
In this case the libs would need to have different names (hard to maintain) or the exectubales have to  be run through a wrapper-script.
But nothing of it is needed, because make install relinks the libraries.

This is, of course, only tru if the automake-system is used !
And make install is absolutely necessary.

But why do you not use the debian control-files, by just running dpkg-buildpackage in the sources root-folder to create clean isntallable and uninstallable debian packages, or use at least checkinstall ?

And if you want to install a binary version of C::B 10.05, you can of course use my repo.
See http://apt.jenslody.de/ for details.

[BentFX]

Possily you should read more carefully:

Yes it's a shame I missed that, especially since it doesn't apply to my case. /usr/local/lib was in my /etc/ld.so.conf by default, and the error message was completely different than what is documented.

But nothing of it is needed, because make install relinks the libraries.

In this case it didn't.

But why do you not use the debian control-files, by just running dpkg-buildpackage in the sources root-folder.

Done! The build in /usr/local has been removed and I'm reinstalled from debs. I've looked at building packages before, it's a complicated thing. Thank you for setting it up to work so smooth. The only thing that would have made it easier is if you had told me "dpkg -i *.deb" to keep from playing dependency roulette, trying to install the packages one at a time. Just dug a bit... dpkg-buildpackage is mentioned 107 times in the forum, but I don't find it even once on the website, in the wiki, or in the source tarball. "dpkg -i *.deb" is in the wiki. Maybe the BUILD file should just say "go read the wiki... then the forum." I certainly got my butt chewed for following the instructions in the BUILD file.

...you can of course use my repo.

I don't update c::b with every easterly gust. I did this time for a reason. Like I said I wanted the wxGLCanvas capability in wxsmith. Since I was updating I wanted the most recent, stable c::b, and I wanted it linked to the most recent release of wx. Unfortunately that didn't happen exactly as planned.