-----------------------------------------
| 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 filesThe 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:
Any idea ?
3.3> SELECT: "wxWidgets Cross-platform C++ GUI Toolkit (GTK+ development) (libwxgtk2.8-dev)"Is this like good for you ?
3.4> SELECT: "wxWidgets Cross-platform C++ GUI Toolkit (common support files) (wx-common)"
sudo apt-get install gcc g++ make automake libtool libwxgtk2.8-dev wx-common zip libbz2-dev zlib1g-dev libstdc++6-4.6-dev
svn co svn://svn.berlios.de/codeblocks/trunk .
./configure --with-contrib-plugins=all
make
sudo make install
codeblocks: symbol lookup error: codeblocks: undefined symbol: _ZTI17wxScrollingDialog
<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>
sudo ldconfig
Had to runAnd why would you need to do it?Codesudo 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?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.
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 ?
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:
Then why are you building from SVN sources ?I didn't build from the SVN. I built from the released source at http://www.codeblocks.org/downloads/25
Or using a binary distro? If you like to build source packages install a source based distro like Gentoo :)
Because:1. Understood. That's why it goes into /usr/local.
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.
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.
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.
It should be part of the build instructions, ...]Possily you should read more carefully:
[...] or better be run by "make install."
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.
To install the actual release version instead of the nightlies using apt or one of its frontends please add the following lines to your /etc/apt/sources.list :This is from the repo's description...Codedeb http://apt.jenslody.de/ any release
deb-src http://apt.jenslody.de/ any release
QuoteTo install the actual release version instead of the nightlies using apt or one of its frontends please add the following lines to your /etc/apt/sources.list :This is from the repo's description...Codedeb http://apt.jenslody.de/ any release
deb-src http://apt.jenslody.de/ any release
codeblocks: symbol lookup error: codeblocks: undefined symbol: _ZTI17wxScrollingDialogThis missing symbol is in libcodeblocks.so.0 I've verified that by dismantling the libcodeblocks0_xxx.deb
Any package installing shared libraries in one of the default library directories of the dynamic linker (which are currently /usr/lib and /lib) or a directory that is listed in /etc/ld.so.conf[58] must use ldconfig to update the shared library system.libcodeblocks.so.0 and libwxsmithlib.so.0 are the only two files that go into the base /usr/lib or in the case of "make install" without a --prefix /usr/local/lib. On a recent Ubuntu /usr/local/lib is listed in /etc/ld.so.conf by default and thus is managed by ld.so.
As mandated by the FHS, packages must not place any files in /usr/local.... because /usr/local and its contents are for exclusive use of the local administrator, a package must not rely on the presence or absence of files or directories in /usr/local for normal operation.That says quite straight up... Installations in /usr/local do not mix with installed packages or system files.
I asked for the explanation why ldconfig is needed, so we can have a reason to add it to the "make install" process.Quite simply, Debian says use it. .deb packages are already using it. It would simply be enough to add a line to the BUILD file that says "If after doing "sudo make install" you get an error similar to this, run ldconfig. Recent Ubuntu's don't have LD_LIBRARY_PATH and outside of /lib and /usr/lib ld.so.cache is the only way to ensure your library will be found. Mainly, don't think that ldconfig is just for changes to ld.so.conf. It also has to be run when libs are added or removed from those directories in order for ld.so.cache to remain in sync with the installed libraries. Do understand, that I also understand, ldconfig is primarily a Debian thing. Would I run it in Fedora? Not without doing some research. But in Debian it carries the water for the ld.so dynamic library linker.
#!/bin/sh
set -e
# Automatically added by dh_makeshlibs
if [ "$1" = "configure" ]; then
ldconfig
fi
# End automatically added section
I will not answer to everything you write. likewiseAnd again Debian insists it be used on Debian systems. That is probably why it is added automatically. Yesterday I had real world experience looking at the linker not finding files that were exactly where they belonged. And ldconfig fixed the issue.
And again, it works fine without ldconfig.
The cause might be, that I always start with full (or relative) path from console or desktop-file.Does this break the file? Whether it is added automatically, or not, the fact is the debs are installed with ldconfig. Are the debs broken?
The libs are definitely relinked (clearly stated in the buildlog and visible with ldd).
About removing the software, you write removing /usr/local should not harm the system. That's of course correct, but as you also write, you have several other installations there, and they would surely break, if you remove the fodler they are in.No! They'd just be gone. My menu items would be broken.
One sentence about sources-list, you can add entries and comments, so you do not need to remember "manually" what the entry is for.Didn't realise that option existed. I'll look into it. Seems everybody wants you to add their repo and accept their digital trust file, but nobody wants to add a meaningful comment to their sources entry.
Thanks for pointing to the typo in BUILDIt's in the man page actually. Could I write a patch? I've never written a patch, and one character in one line of one file seems like the perfect first-timer project. :)
On the ldconfig thing, do what you do. Debian says use it.That's not true !
I point your attention to the Debian Policy Manual section 8.1.1...it's not needed to run ldconfig, or did I misunderstand something.QuoteAny package installing shared libraries in one of the default library directories of the dynamic linker (which are currently /usr/lib and /lib) or a directory that is listed in /etc/ld.so.conf[58] must use ldconfig to update the shared library system.
And again Debian insists it be used on Debian systems. That is probably why it is added automatically. Yesterday I had real world experience looking at the linker not finding files that were exactly where they belonged. And ldconfig fixed the issue.1. Debian is not the only distro in the world
No! They'd just be gone. My menu items would be broken.Facepalm 1
Didn't realise that option existed. I'll look into it. Seems everybody wants you to add their repo and accept their digital trust file, but nobody wants to add a meaningful comment to their sources entry.Facepalm 2
The debian-packages have to call ldconfig, because they install their libs in /usr/lib .And if the plain jane "make install" is done on a recent Ubuntu the files go into /usr/local/lib... OMG!!! I just checked out the trunk and its BUILD file suggests "make install" into /usr I think our conversation is done.
--- src/src/codeblocks.1 2011-09-26 06:59:41.700778880 -0700
+++ src/src/codeblocks.1.fixed 2011-09-26 07:03:11.188781482 -0700
@@ -57,7 +57,7 @@
.nf
codeblocks \-\-build \-\-target="Debug" \-\-no\-batch\-window\-close myproject.cbp
-Batch rebuild everything in myproject.cpp:
+Batch rebuild everything in myproject.cbp:
.nf
codeblocks \-\-rebuild myproject.cbp
.SH AUTHOR
The debian-packages have to call ldconfig, because they install their libs in /usr/lib .And the only point I'm trying to make is on some systems ldconfig is also needed for /usr/local/lib. And you all can't wrap your heads around that.
Facepalm 1Who ever said working software??? I was only trying to illustrate that /usr/local is not system files!!! Since you've got your face in your palm, go ahead and try to get a grip.
What is the definition of working software, then?
Facepalm 2Again, get a grip! If you want to deride me because I don't know every option to every program on my system then so be it. The fact remains, I'm not going to add the repo. I'll use my Codeblocks... Ha Ha! Hear that? My Codeblocks! Yeah, I'll download what I need, and I'll always be a bit disgusted by you. What a sad case.
RTFM! And there is a whole web page with information about what you should do and what the repo provides.
What you say is, that a software that is removed is not broken.QuoteAbout removing the software, you write removing /usr/local should not harm the system. That's of course correct, but as you also write, you have several other installations there, and they would surely break, if you remove the fodler they are in.No! They'd just be gone. My menu items would be broken.
And again, it works fine without ldconfig.
The cause might be, that I always start with full (or relative) path from console or desktop-file.
The libs are definitely relinked (clearly stated in the buildlog and visible with ldd).
Read it yesterday... scanned it just now... can't find where it says how to set a comment on the source line... please show me... http://apt.jenslody.de/ or are you just talking out your apps.Documentation about apt/dpkg/debian must be on the debian.org web site, not on the Jens' repo.
@Admins: can you extract the last posts, because we are too much off topic.
Read it yesterday... scanned it just now... can't find where it says how to set a comment on the source line... please show me... http://apt.jenslody.de/ or are you just talking out your apps.Documentation about apt/dpkg/debian must be on the debian.org web site, not on the Jens' repo.
Why do you want everybody to serve the info you need on a platter?
man sources.list
Should not be too hard for someone who builds his own software.Yes, I will sort it out. Fact is, inside Synaptics, now that I've thought about it, the original CD(disabled) has a second line of text below it. I just wrote my first patch using nothing but man pages, and trial by fire. I can figure it out.
The solution is on "buggy/broken" distros you have to run ldconfig after you run make install. Simple as that...None! It has it's place, and for what it does there isn't really another workaround. But it is very system specific and just saying "run ldconfig" without asking a few questions first is not the proper approach.
What other solution do you want from us?