| Summary: | kdesupport libfam is disabled for standard (although libfam 2.7.0 is present on system) | ||
|---|---|---|---|
| Product: | [I don't know] kde | Reporter: | TimWetter <info> |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | finex |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
TimWetter
2007-12-14 15:24:40 UTC
You most probably miss the -dev (or -devel) packages of it. No! My libfam is compiled from source .. also the files in /usr/include are present. I'm using gentoo and have compiled libfam (2.7.0-r4) through portage, and I have the same problem. a) the problem is strigi-specific (so, to be reported in strigi bugtracker [that's not this one]) b) strigi do not look for FAM autmatically, but adding -DWITH_FAM=ON to cmake will do the job, hopefully Sorry, but adding: "-DWITH_FAM=ON" is not a good solution. Thats the same as ccmake with "~ FAM: ON"! I think the advantage of cmake should be: - faster - more detail (e.g. not compile... because of missing ...) - more proper or why changing from configure to cmake ??? Adding -Dvar=value is *exactly* like adding --with-var=value to the ./configure - that is, setting an option at configure time. The fact that there's the autotools stuff or cmakr to do the configuration phase, does not change much. For the other, no need to comment the nonsense. Anyway, Pino is right. This is not the right place for reporting this issue. |