While koffice-data correctly detects lcms during config, it looks like it may be confused on the version, and later terminates the build saying it can't find the required packages: -- checking for module 'lcms' -- found lcms, version 1.18 -- Found lcms version 1.13, /usr/lib64/liblcms.so -- The following REQUIRED packages could NOT be located on your system. -- Please install them before continuing this software installation. ----------------------------------------------------------------------------- + LittleCMS, 1.15 or higher: Color management engine <http://www.littlecms.com> Required by KOffice ----------------------------------------------------------------------------- CMake Error at /usr/share/apps/cmake/modules/MacroLogFeature.cmake:93 (MESSAGE): Exiting: Missing Requirements Call Stack (most recent call first): CMakeLists.txt:228 (MACRO_DISPLAY_FEATURE_LOG) FWIW: equery b /usr/lib64/liblcms.so * Searching for /usr/lib64/liblcms.so ... media-libs/lcms-1.18-r1 (/usr/lib64/liblcms.so -> liblcms.so.1.0.18) Of significance, I recently rebuilt my system against glibc-2.10.1, using gcc-4.4.0. This is on amd64 no-multilb. Full build log and emerge --info to be attached.
Created attachment 192814 [details] emerge --info
Created attachment 192818 [details] emerge log
The >= lcms-0.18 is specified in the ebuild. Also works for me. Try to wipe out lcms and install it again. Check if some lcms.so is not somewhere in /share/local/ for example.
(In reply to comment #3) > The >= lcms-0.18 is specified in the ebuild. The ebuild dependencies seem to be fine. It's the cmake/configure detection that seems screwed. As posted, it says it finds version 1.18 (which it should), then turns around and says on the next line, version 1.13. This despite my double-check of the library .so symlink, to 1.18 both as confirmed by equery and as visually confirmed on the system itself. The cmake detection appears to want >= 1.15, so naturally, it fails when it thinks it sees 1.13. > Also works for me. > Try to wipe out lcms and install it again. I tried. No luck. I also tried the following, no luck: CFLAGS="-march=opteron-sse3 -pipe -O2" CXXFLAGS="-march=opteron-sse3 -pipe -O2" LDFLAGS= MAKEOPTS=-j1 So it's not strange CFLAGS, etc. Of course, I can't easily try reverting to gcc-4.3 because cmake is gcc version dependent and won't work with 4.3 when it was compiled with 4.4. cmake isn't too hard to recompile itself, but from past experience that seldom works either as it hangs on something else. > Check if some lcms.so is not somewhere in /share/local/ for example. I checked /usr/local, which I expect is what you meant, nothing there. I did a bit more browsing as well, but didn't find anything strange lurking around. Meanwhile, can you confirm when building there, whether it reports lcms 1.18, then immediately says lcms 1.13 on the next line? It should be ~ line 75 in the log, or it is here (and in the attached log). If yours is saying 1.18 then 1.13 as well, that's a dead-end, but that's where it looks to be going wrong to me. It seems the version check is screwed and it's reporting 1.13 for some reason. Unfortunately, while between the .configure script and its log, I could sometimes find the problem in them, cmake based configs are much more a black-box to me and I haven't a clue how to figure out what it's doing there to come up with 1.13. Based on previous gcc upgrade troubleshooting, etc, I suspect a test compile that fails with gcc 4.4 (or maybe glibc 2.10), but have no idea where to look to actually see what it's doing and check that.
set(FIND_LCMS_VERSION_SOURCE "#include <lcms.h>\n int main()\n {\n return LCMS_VERSION;\n }\n") set(FIND_LCMS_VERSION_SOURCE_FILE ${CMAKE_BINARY_DIR}/CMakeTmp/FindLCMS.cxx) file(WRITE "${FIND_LCMS_VERSION_SOURCE_FILE}" "${FIND_LCMS_VERSION_SOURCE}") This is detection code for lcms. Check file FindLCMS.cmake in the cmake/ folder for sources. Try to run the app/commands yourself to see output. There might be error so we can patch it out.
OK, I didn't expect FindLCMS.cmake to belong to kdelibs, or to be under /usr/share/apps, but so it was. I think (KNOW!) I have a bit better understanding of cmake now. Thanks. I traced it down. Seems I had a stale /usr/include/lcms subdir. Naturally, that was version 1.13 according to the version info in that lcms.h. rm-ed that dir and koffice-data-2 emerged just fine. So I'm going to go ahead and resolve/invalid this. Thanks again for the cmake hints. Given that I'm a KDE guy, I'm sure I'll be using these new cmake troubleshooting skills again. =:^s
He he, no problem :] I had to learn cmake the hard way, test and play with fake project to see what does what. So i am happy that i can help others without the need for doing the sleepless nights finding why the IF is not evaluated ;D Cheers
Perhaps we shouldn't be so quick do mark this one INVALID - I have the exact same symptom and cause on an x86 box and it's not finger trouble here. /usr/include/lcms/ exists, dated 5 July 2005 and contains lcms.h from version 1.13. The directory is orphaned as are it's contents. Which makes me ask - why did portage not remove it when lcms-1.13 was unmerged? lcms-1.8 provides /usr/include/lcms.h correctly. Seems like a real bug to me, I just don't know what to allocate it to. I'd be happy to supply any info you need to resolve this - no attachments yet because I don't want to clutter the bug page guessing what you might want.
@alan: The reason I was so quick to mark it invalid here was that a couple years ago, I had a disk die on me (heat death, the AC had gone out and the room temp was likely 50 C, no telling what the disk had hit!). Well, more like partially die. Where the disk I/O heads were at the time the disk was unreadable, but I had backup partitions that were fine. Only the backups weren't all in sync so when I restored, /var, with the installed package database, was out of sync with what was actually installed. Since I use FEATURES=buildpkg, I was able to relatively quickly restore to current versions, but of course where it wasn't a direct overwrite, that left stale copies of what was actually on disk behind. Well, I learned my lesson and when I replaced the disk (which I did ASAP as I didn't know how long the rest of it would remain usable), I arranged for everything portage touches, so including most of /usr and /var, to be on the same partition, /, so it all stays in sync now. And for /lib64 and /usr/lib64, among others, I went thru the process of finding what package every file belonged to and for the orphans, deciding whether it was stale or simply not directly part of a normal package, and removing the stale files. But I didn't do that with /usr/include, so when I discovered the stale lcms dir therein, I assumed it was cruft left over from that event, and thus not a problem from some bad package update along the line, but due to the unique history of this system. Now you're telling me you have the issue too. Assuming you never had an event similar to my overheated disk, the issue is now far more likely to be related to a bad lcms ebuild or portage version way back in 2005 that we both hit. If that's the case, then it may be wise for current lcms ebuilds to check for and manually remove that directory, if necessary. However, that would make it an lcms bug instead of the original kde bug. So, my question to you is this, /did/ you have an event similar to mine, above, or is there any other reason likely unique to your install that the /usr/include/lcms dir may have still existed on your machine? If so, the bug remains invalid as it's one-offs of the sort Gentoo couldn't possibly test and correct for all possibilities of. If not, I should reopen the bug, perhaps change the summary to reflect that it's an lcms issue now, and see about getting it assigned to the lcms people (herd and maintainer printing, according to epkginfo) instead of kde, so we can at least see what they think of adding a check for stale include dir and remove if found procedure, to the current ebuilds, maybe with a revision-bump, maybe not. Even without it tho, it'd be simply a matter of remerging lcms to take care of the issue. I guess that makes it your move, now. =:^)
(In reply to comment #9) > @alan: > > The reason I was so quick to mark it invalid here was that a couple years ago, > I had a disk die on me (heat death, the AC had gone out and the room temp was > likely 50 C, no telling what the disk had hit!). Duncan, I did not have any harmful disk events. My desktop is a little used machine with an install from 2004 and has orphaned lcms lib dirs. I checked again and find quite a lot of really old orphans as per 'qfile -o'. There could be many causes for this, even old bugs from long-gone portage versions :-) Let's wait for the dev to respond, he's in a better position to decide how to proceed than I.
Per disscussion over irc with our portage master Zac: Orphans used to be quite common with older versions of portage, but since portage-2.1.3, FEAUTURES=unmerge-orphans prevents any orphans. If those files are dated 2005 then the are probably orphans from older portage. So probably removal of the folder is clear approach for fixing this issue. Also there is onle slight problem, because older portages really dont care about orphans so you should probably consider backuping /var/lib/portage and your configuration files and reinstalling system to get it clean :(
That makes sense. My emerge.log shows I unmerged lcms-1.13-r1 on 13 Feb 2006 and at the time I was using portage-2.0.54 so it's clear what the cause is. I fear more folks are going to run into this though, there are plenty of boxes out there dating from Feb 2006 or earlier and all will have this orphan directory. With luck, this bug report will show them what to do: remove the orphan directory /usr/include/lcms Thanks for your assistance and willingness to help. Much appreciated.
