Author Topic: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back  (Read 22661 times)

Offline Feneck91

  • Multiple posting newcomer
  • *
  • Posts: 112
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) !

Quote
-----------------------------------------
| 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.
« Last Edit: August 14, 2011, 11:38:47 pm by Feneck91 »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
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 !

Offline Feneck91

  • Multiple posting newcomer
  • *
  • Posts: 112
Ok jens, no problem with it. If I remove point 7 (building own 2.8.x wxWidgets) and modify points :
Quote
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.
« Last Edit: August 15, 2011, 11:20:27 pm by Feneck91 »

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
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: [Select]
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: [Select]
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.

Offline Folco

  • Regular
  • ***
  • Posts: 343
    • Folco's blog (68k lover)
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)
« Last Edit: August 30, 2011, 01:42:03 pm by Folco »
Kernel Extremist - PedroM power

BentFX

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


Build commands...
Code: [Select]
./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: [Select]
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: [Select]
<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: [Select]
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 :) )
« Last Edit: September 25, 2011, 03:07:55 pm by BentFX »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12122
    • Travis build status
Had to run
Code: [Select]
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!
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

BentFX

  • Guest
Quote
And why would you need to do it?
Quite simply, because it solved the problem with the libraries not being found.

Quote
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?

Quote
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.

Quote
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12122
    • Travis build status
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

BentFX

  • Guest
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #10 on: September 25, 2011, 04:45:53 pm »
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..

Quote
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?
« Last Edit: September 25, 2011, 04:58:22 pm by BentFX »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12122
    • Travis build status
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #11 on: September 25, 2011, 05:48:11 pm »
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
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

BentFX

  • Guest
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #12 on: September 25, 2011, 07:22:23 pm »
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:
Quote
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
Quote
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.

« Last Edit: September 25, 2011, 08:01:29 pm by BentFX »

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #13 on: September 25, 2011, 08:58:21 pm »
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

  • Guest
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #14 on: September 26, 2011, 12:01:26 am »
Quote
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.

Quote
But nothing of it is needed, because make install relinks the libraries.
In this case it didn't.

Quote
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.

Quote
...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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12122
    • Travis build status
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #15 on: September 26, 2011, 12:06:49 am »
Quote
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 :

Code: [Select]
deb http://apt.jenslody.de/ any release
deb-src http://apt.jenslody.de/ any release
This is from the repo's description...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

BentFX

  • Guest
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #16 on: September 26, 2011, 12:51:47 am »
Quote
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 :

Code: [Select]
deb http://apt.jenslody.de/ any release
deb-src http://apt.jenslody.de/ any release
This is from the repo's description...

If that was directed at me I'll say it again, NO! Everybody and their cat has a flippin' repo. I don't mean to be disrespectful, but it'll probably be another two years before I update c::b again. I'm not going to have it nag me through update manager till then. as long as it does what I need, I would prefer not to screw with it, and every update is just another chance to break the "does what I need" feature.

And quite certainly, if every update was as difficult as this one I'd never update again. Compiling was easy... Getting it to run was a bit of a trick... Then I posted to the stinking forum... What a headache!


Offline Freem

  • Almost regular
  • **
  • Posts: 219
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #17 on: September 26, 2011, 10:43:26 am »
Ahemmmm... We are speaking about nightly builds, here.
So it is obvious that it can break some features, as they are considered like beta versions. But in facts, it's really uncommon to have more problems with them than with the official and old release.

Compiling have more chances to break something than using an official repo of the project. (yes, jens is an official developper, here) Because you probably (well, only probably) now less things about the code and its dependencies than him.

Offline BentFX

  • Multiple posting newcomer
  • *
  • Posts: 18
    • BentFX
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #18 on: September 26, 2011, 01:10:41 pm »
if (RANT_MODE) {

My original runtime error was...
Quote
codeblocks: symbol lookup error: codeblocks: undefined symbol: _ZTI17wxScrollingDialog
This missing symbol is in libcodeblocks.so.0 I've verified that by dismantling the libcodeblocks0_xxx.deb

Another fun fact... the libcodeblocks postinst and postrm both run ldconfig. Understand that? Install from the deb, it runs ldconfig. The same is also true for libwxsmithlib.so.0, the other library that wasn't found when I first built and installed.

So that brings up the question, if the package manager needs to run ldconfig, why is it so disrespectful if I run it, especially when it sorts out the issue with libraries not being found?

It also brings up the question, as posed elsewhere in this thread, with a twist... If the installer isn't editing /etc/ld.so.conf, why is it running ldconfig? Shouldn't we file a bug report?

This would also bring up another question, from elsewhere in this thread... If the user has parallel installs of c::b and they are all keyed to their individual libraries, does that user not use the package manager? Or more likely is ldconfig being run by the package manager and isn't breaking anything? This is the fact... ldconfig stays within its configured directories. If you put libraries in /usr/lib they may have their symbolic links manipulated. If you have libraries in /some/odball/path/to/your/custom_c::b ldconfig will never touch them.

I point your attention to the Debian Policy Manual section 8.1.1...
Quote
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.

Now a bit more I've found by digging... LD_LIBRARY_PATH has been broken(by design?) in Ubuntu since 9.04 (Ubuntu bug #366728). There is no global LD_LIBRARY_PATH. The man page for ld.so says the library search is three fold, first LD_LIBRARY_PATH(which doesn't exist), then the ld.so.cache, then /lib and /usr/lib. By that it would seem that the libraries in /usr/local/lib would never be found until ldconfig was run to add them to the ld.so.cache. It really seems kinda straight forward. There was no way to make it work except to run ldconfig, or manually move the files, or create symlinks, in a lower directory, and that certainly wouldn't be the correct action.

Next lets have a discussion about /usr/local...

On a new install of Ubuntu /usr/local is just a directory structure, there are no files. If a build is configured with --prefix=/usr/local or in the normal case prefix defaults to /usr/local all installed files will reside within the /usr/local directory structure. This does not mix installed files with system files. At any point in time I can do rm -rf /usr/local and the system will not be broken. If program installations properly respect the --prefix, and in my experience they do, deleting the /usr/local directory won't even leave behind any orphaned files, except the occasional ~/.configs that apt doesn't even clean up. Which begs the question, if I can install to a directory within my home dir, why can't I use /usr/local? It is a single user system, and quite honestly, that's why it's there.

Again lets see what the Debian Policy Manual has to say, section 9.1.2...
Quote
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.

Yes, it is possible to create version struggles with similarly named files in /usr and /usr/local. Yet this is possible with any directories in the search path, on any OS. Unix has two wonderful tools for locating these struggles, "find" and "which." I wish windaz came with such powerful tools right out of the box. As long as installs respect --prefix and packages respect Debian Policy there is no mixing of files! The only conflict will be with similar names, and which is found first.

In summary...

No, what I'm doing isn't wrong! Possibly in your "opinion" I should be doing some things differently, but Debian sides with me! When I add a lib to the ld.so directories I WILL run ldconfig, and /usr/local is mine, to do with as I please! I keep my build dirs and at any point I can ./configure to a new --prefix, make install to a clean dir, and work side by side nautilus windows to pick apart everything it installed. Yes I have been there and done that. Most recently, today with Codeblocks. It really is not that tough. Haven't done it often... kinda enjoy it.

}else{

dpkg-buildpackage is the nuts! You've put a lot of work into the build system. Document it in BUILD!

Also the last example in the man page has a typo. It says...
 
Batch rebuild everything in myproject.cpp:
codeblocks --rebuild myproject.cbp

The first .cpp should be .cbp.

I really don't want to come off as a jerk, but I would like to expose how this whole interaction went from my perspective. Firstly, as I've said before, I don't pile on my system with home built apps. If I did, as I've said, the ldconfig would have been a given, and I never would have been here. Currently I have the newest Blender, Bluefish, OpenMesh and for a bit Codeblocks, in my /usr/local. I do enjoy building code! I've built several LFS systems, and there is a kind of hypnotic state that a newbish such as myself gets into watching a build progress without errors. For the number of people downloading the trunk, and the small group actively doing development on c::b, I don't think I'm the only one that gets a kick out of building source code. And for a drub I like to think I'm OK at figuring out build errors. All that aside...

I built the source but had the errors I mentioned earlier. I was stumped! I found no immediate joy on Google, so I started formatting a post to seek out an answer on the forum. Understand, I'm no flippin Mitnick, but I'm trying to put together a reasonable post with a decent amount of pertinent information about what's failing, and it dawns on me "missing symbols" must be a library thing. I did a quick 2+2 and realised ldd was the tool of choice. I had never used ldd before. I got to the point where I was looking at codeblocks and libwxsmith.so with ldd in a terminal. While at the same time I was looking at the missing libraries in /usr/local/lib, in nautilus. The files were there, with their symbolic links, exactly as they were supposed to be, but were not being found. So I was stumped again! And I started rewriting my post to better illustrate what I had discovered the problem to be. Then it struck me like a bolt... run ldconfig! Problem solved!

I had searched for the exact error message with no luck, but I came back and searched ldconfig to see if I couldn't find others with the same issue. The top page in the search result had a user running ldconfig after each make install, and another user saying don't do that. Truth is, and I think it is obvious given Ubuntu's broken LD_LIBRARY_PATH, ldconfig was the answer on my Ubuntu box. Libraries installed to /usr/local/lib will not be found unless they are found in ld.so.cache.

I didn't know that c::b wouldn't link to wx 2.9. Had I done my homework better I probably would have chosen a binary package... actually probably not... now that I've done the homework dpkg-buildpackage is my prefered c::b build.

I know I'm only far enough up the learning curve to realise I should have worn better shoes, but I do know when I'm being piled on. I said run ldconfig and I stuck by it, and that obviously raised the ire of the powers that be. Yet I've asked repeatedly, what would your fix have been? and get no answer. Instead I get, don't install the source or puppies die. I know the dangers of mucking up /usr, but I've also come to realise the annoyance of adding a sources.list line for every repository I come across. Truth is, I might have added the repo if it was apt.codeblocks.org. I recently went through and cleaned out my sources and mostly I had no idea where they came from. jenslody.de? I won't remember what that was in six months. You guys see c::b as an ongoing project, and give it daily attention, I see it as a tool. If it's there when I need it and it does what I need I'm a happy camp stool. And maybe in a couple years when I decide I need an update, it might be way cool, just like Christmas morning. It's tough to get that "Yeah! that's the (offensive slang) I was talkin 'bout!" feeling when downloading nightlys.

Anyhow, I'm rambling. Part of the title of this thread is "experience feedback." I gotta say... No I won't!

Three times, account deleted and recreated. If my mouth doesn't get me banned, that will.

oBFusCATed said...
Quote
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.

@Freem... No, I quit talking about nightlys a long time ago. Surely this could break, that could break, it might break right down the middle and I won't know which half to pick. If my new c::b is solid, I aint gonna change it until it does break. This whole debacle was to gain one feature I wanted. Other than that, my old c::b did everything I needed. And yes, Jens has got me beat in so many ways. I hope neither of you take it personal that I choose to not add the repository. Unless this install turns out to be broken bad, I'm not changing it until the same version is available in Ubuntu repos at least.

} // well that sucked. (let the day shift clean it up)
« Last Edit: September 26, 2011, 02:18:11 pm by BentFX »
Whenever I go to Walmart I always request an intrusive pat-down from the greeter. It looks good on his resume, and it makes us all just a little bit safer.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #19 on: September 26, 2011, 02:04:53 pm »
I will not answer to everything you write.
Again, if you read more carefully, you would know what has happened:
Quote from: libcodeblocks0.postinst
#!/bin/sh
set -e
# Automatically added by dh_makeshlibs
if [ "$1" = "configure" ]; then
        ldconfig
fi
# End automatically added section

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).

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.

One sentence about sources-list, you can add entries and comments, so you do not need to remember "manually" what the entry is for.
The update frequence of the release-component of my repo is very low. Until there is no new release, it will not change.
Not the same for the trunk binaries, of course.
I started with my repo on my home-server, before I became a C::B developper and I called it unofficial therefore.
In the meantime, I am one of the core-developpers of C::B and the server has moved to a (more or less) real server, with a much better performance (and much higher costs), but I decided not to change the repo's title, because it's still not on an official codeblocks.org-server.
But right now (while posting) I changed the title to "(un-)official", because it uses the official sources, with one little change (I have one plugin more to download in the additional-plugins packages).

Thanks for pointing to the typo in BUILD, I try to keep it in mind, that all thes files need some work (the debian/copyright-file needs the most by the way), but I have to do some other annoying work, to earn enough money to feed my family and me and work for C::B in my spare-time (as all other C::B devs do).

Offline BentFX

  • Multiple posting newcomer
  • *
  • Posts: 18
    • BentFX
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #20 on: September 26, 2011, 03:04:34 pm »
I will not answer to everything you write. likewise
And again, it works fine without ldconfig.
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.

Quote
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).
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?

Quote
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.

Quote
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.

Quote
Thanks for pointing to the typo in BUILD
It'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. If you can get by without it that's fine, but on my system if a program fails with "undefined symbols" and the files exist, I'm probably going to run it. and if it fixes the issue I'm probably going to say so.
Whenever I go to Walmart I always request an intrusive pat-down from the greeter. It looks good on his resume, and it makes us all just a little bit safer.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #21 on: September 26, 2011, 03:31:09 pm »
On the ldconfig thing, do what you do. Debian says use it.
That's not true !
As I wrote, I have installed several versions, none of them is below /usr/local (all below $HOME, because I did not work as root in about 20 years of using unix/linux on any of my machines, if it was not absolutely needed), but /usr/local is not in ld.so.conf.d on my system anyway, so according to:
I point your attention to the Debian Policy Manual section 8.1.1...
Quote
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.
it's not needed to run ldconfig, or did I misunderstand something.

The debian-packages have to call ldconfig, because they install their libs in /usr/lib .

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12122
    • Travis build status
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #22 on: September 26, 2011, 03:36:57 pm »
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
2. If you don't know what you're doing -> you should use prebuild packages
3. If you compile from source you should know your system and its requirements!
   We can't handle every system in the world. This is the job of the packages/distro maintainers!

No! They'd just be gone. My menu items would be broken.
Facepalm 1
What is the definition of working software, then?

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
RTFM! And there is a whole web page with information about what you should do and what the repo provides.

(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline BentFX

  • Multiple posting newcomer
  • *
  • Posts: 18
    • BentFX
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #23 on: September 26, 2011, 05:23:04 pm »
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.

Don't any of you lecture me about what I do on my system. :)

No I won't delete the account, you've either got to look at it, or delete it yourselves.

The funny part is I did write the patch for the man page... http://BentFX.com/manpage.patch

Simple "patch -p0 < manpage.patch" from within trunk will do it.

Code: [Select]
--- 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

It boggles my mind. You keep replying with such as this...
Quote
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.

Quote
Facepalm 1
What is the definition of working software, then?
Who 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.

Quote
Facepalm 2
RTFM! And there is a whole web page with information about what you should do and what the repo provides.
Again, 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.

AND STILL YOU HAVE NEVER ANSWERED!!! WHAT WOULD YOUR SOLUTION HAVE BEEN??? What a flea king loser.

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.
« Last Edit: September 26, 2011, 05:33:45 pm by BentFX »
Whenever I go to Walmart I always request an intrusive pat-down from the greeter. It looks good on his resume, and it makes us all just a little bit safer.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12122
    • Travis build status
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #24 on: September 26, 2011, 05:37:21 pm »
@BentFX:
The solution is on "buggy/broken" distros you have to run ldconfig after you run make install. Simple as that...
What other solution do you want from us?

@Admins: can you extract the last posts, because we are too much off topic.

(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #25 on: September 26, 2011, 05:39:54 pm »
Quote
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.
What you say is, that a software that is removed is not broken.

But where is the difference between a software, that does not work, because it can not find a lib and a software that does not work, because someone has deleted it ?
Both do not work, and that's the point that interests me, if I want to use software.

And I did not tell you that you should not use ldconfig, the only thing I told you, is that it works here (and on several other actual distros I use for testing purposes) without running ldconfig, and if I remember correctly it also works on ubuntu this way (for me).
But as I wrote, I never install software as root (and that's needed for /usr/local) if it is not absolutely necessary.
And if I am the only user, there's no need to do so.

Again  : please read more carefully:
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).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12122
    • Travis build status
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #26 on: September 26, 2011, 05:42:04 pm »
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?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #27 on: September 26, 2011, 05:48:20 pm »
@Admins: can you extract the last posts, because we are too much off topic.

Not everything is off-topic, because some users seem to have a problem with the automake-system, and if someone is brave enough to read through tons of nonseless text to extract the interesting parts, it might be of help for someone, even if the solution (running ldconfig) is in our wiki for a very long time (at least for people who are willing to read).

That's my opinion at the moment, but I'm not the only admin here, and my opinion can change of course.

@BentFX:
be aware, that you are not far away from a ban, if you are not able to calm down and return to a more unemotional discussion.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #28 on: September 26, 2011, 05:50:10 pm »
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?

Type
Code: [Select]
man sources.list and search for comment.

Should not be too hard for someone who builds his own software.

Offline BentFX

  • Multiple posting newcomer
  • *
  • Posts: 18
    • BentFX
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #29 on: September 26, 2011, 06:03:52 pm »
Quote
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.

Other than that... man what a loudmouth I am... Huh?
Whenever I go to Walmart I always request an intrusive pat-down from the greeter. It looks good on his resume, and it makes us all just a little bit safer.

Offline BentFX

  • Multiple posting newcomer
  • *
  • Posts: 18
    • BentFX
Re: Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
« Reply #30 on: September 26, 2011, 06:42:06 pm »
Quote
The solution is on "buggy/broken" distros you have to run ldconfig after you run make install. Simple as that...
What other solution do you want from us?
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.

I don't fully understand how ldconfig can break things, because I've only dealt with it on a system that is built around it. As for its relinking??? Not really sure what the impact of that is. As long as the lib still loads I'm kind of oblivious.

Anyhow, I'm sorry for being a mouthy whatchacallit. Just please don't treat me like I'm stupid. A little gentle direction and room to stumble is all I need.

And yes, in many ways we have gotten strongly off topic.
Whenever I go to Walmart I always request an intrusive pat-down from the greeter. It looks good on his resume, and it makes us all just a little bit safer.