User forums > General (but related to Code::Blocks)
Compile Code::Blocks from SVN under ubuntu (for newbie): experience feed back
BentFX:
--- Quote from: oBFusCATed on September 25, 2011, 04:10:34 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 :)
--- End quote ---
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.
--- End quote ---
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:
--- 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.
--- End quote ---
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.
--- End quote ---
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:
--- Quote from: BentFX on September 25, 2011, 02:40:29 pm ---It should be part of the build instructions, ...]
--- End quote ---
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
--- Quote from: BentFX on September 25, 2011, 02:40:29 pm ---[...] or better be run by "make install."
--- End quote ---
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:
--- Quote ---Possily you should read more carefully:
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version