if (RANT_MODE) {My original runtime error was...
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...
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...
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...
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)
