By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 755

Summary: kdebase: Can't build package without dbus header patch
Product: TDE Reporter: Darrell <darrella>
Component: tdebaseAssignee: Timothy Pearson <kb9vqf>
Status: RESOLVED FIXED    
Severity: major CC: bugwatch, darrella
Priority: P1    
Version: R14.0.0 [Trinity]   
Hardware: Other   
OS: Linux   
Compiler Version: TDE Version String:
Application Version: Application Name: kdebase
Attachments: Ensure dbus and libhal header files are found when building
make mediamanager compiler search dbus include directories

Description Darrell 2011-12-20 15:15:25 CST
Created attachment 234 [details]
Ensure dbus and libhal header files are found when building

For some reason, the kdebase compile defaults disable HAL support. Adding the -DWITH_HAL=ON option results in kdebase not building. The problem is caused by not finding necessary header files.

Patch included but I don't know how this affects other distros. I don't know why HAL support is disabled as the default. Is this an Ubuntu thing? Is this a build issue that needs to be explained in the wiki?
Comment 1 Darrell 2011-12-21 00:21:28 CST
The patch provided allows kdebase to build and in Slackware 13.1, solves the problem reported in bug report 634 by enabling HAL support.

However, building with HAL support neutralizes the patch submitted in bug report 388, which restores the 'Keep password' check box to the kdesu dialog box.

Please do not close this report or that of 388 unless both issues are resolved.
Comment 2 Darrell 2011-12-21 21:07:28 CST
Never mind the clash between HAL support and this patch. I found the problem.

In my build script inadvertently I changed package file ownerships to root:root. That change modified the $PREFIX/bin/kdesud binary from 2755 and root:nogroup to 0755 root:root.

The actual "damage" is caused by changing permissions from 2755 to 0755. Changing the group has no noticeable effect. I can toggle the permissions between 2755 and 0755 and see the effect immediately regardless of the group. Apparently kdesud must run set GID.

Setting kdesud to other than 2755 triggers not showing the 'Keep password' check box.
Comment 3 Timothy Pearson 2012-01-11 16:43:04 CST
This patch is unfortunately not portable across distributions.

You will need to instead figure out why HAL_INCLUDE_DIRS is not being set properly in CMakeCache.txt during the initial configuration process.  Likely this is due to a problem in your distribution's HAL package-config (.pc) file.
Comment 4 Darrell 2012-01-11 22:09:06 CST
How is the HAL_INCLUDE_DIRS variable detected or created by cmake? I think you are implying through the hal.pc file?

I can manually create the variable in my build script: export HAL_INCLUDE_DIRS=/usr/include/hal.

My hal.pc file looks correct:

prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib
includedir=${prefix}/include
haluser=haldaemon
halgroup=haldaemon

Name: hal
Description: Free desktop hardware abstraction layer
Version: 0.5.14
Requires: dbus-1
Libs: -L${libdir} -lhal
Cflags: -DDBUS_API_SUBJECT_TO_CHANGE -I${includedir}/hal

The dbus.pc file looks good too:

prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib
includedir=${prefix}/include
system_bus_default_address=unix:path=/var/run/dbus/system_bus_socket
sysconfdir=/etc
session_bus_services_dir=/usr/share/dbus-1/services
daemondir=/usr/bin

Name: dbus
Description: Free desktop message bus
Version: 1.2.24
Libs: -L${libdir} -ldbus-1 -lpthread -lrt
Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include
Comment 5 Timothy Pearson 2012-01-11 23:09:21 CST
(In reply to comment #4)
> How is the HAL_INCLUDE_DIRS variable detected or created by cmake? I think you
> are implying through the hal.pc file?
yes
> 
> My hal.pc file looks correct:
> 
> prefix=/usr
> exec_prefix=${prefix}
> libdir=/usr/lib
> includedir=${prefix}/include
> haluser=haldaemon
> halgroup=haldaemon
no, it does not.  includedir should be ${prefix}/include/hal
Comment 6 Darrell 2012-01-11 23:16:14 CST
Cflags: -DDBUS_API_SUBJECT_TO_CHANGE -I${includedir}/hal
Comment 7 Darrell 2012-01-12 11:33:15 CST
To revisit this problem I rebuilt kdebase.

I did not explicitly export HAL_INCLUDE_DIRS. I did not merge my patch. I did not modify hal.pc. I only enabled -DWITH_HAL=ON. As far as I can tell from the build logs, hal support built for ksmserver and mediamanager.

The build fails because of not finding a dbus header, not the hal headers:

/dev/shm/kdebase/kioslave/media/mediamanager/halbackend.h:43:29: error: dbus/connection.h: No such file or directory

Although -DWITH_HAL=OFF is the default, I think I got sidetracked because of that along with focusing on "hal" in halbackend.h. Regardless, we still have a bug. I'm changing the bug report description.

Short story:

Is there a way in mediamanager/CMakeLists.txt to add the dbus header path in the "include_directories" section, such as (${DBUS_INCLUDE_DIR}/dbus)? Or to search down one level? I think cmake defaults to looking for /usr/include/dbus-1.0 but not /usr/include/dbus-1.0/dbus.

Longer story:

The as-is include statement in halbackend.h:

#include <dbus/connection.h>

ConfigureChecks.cmake does the following test:

#include <dbus/connection.h>

which is the same path as in halbackend.h. But there is no fatal error so cmake is finding dbus/connection.h.

The build log shows -- checking for one of the modules 'dbus-1' and no errors. I see numerous instances of -I/usr/include/dbus-1.0 in the build log, but not -I/usr/include/dbus-1.0/dbus.

The dbus headers are installed at /usr/include/dbus-1.0/dbus. The dbus-1.pc file Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include.

Seems the build process should find dbus/connection.h because concatenating -I${includedir}/dbus-1.0 and the include statement yields a path of ${includedir}/dbus-1.0/dbus/connection.h, which is correct.

Unless ${includedir} points to somewhere other than /usr/include.

With only the dbus portion of my patch, kdebase builds without errors. We can ignore the hal portion of the patch.

My patch changes halbackend.h to:

#include <dbus-1.0/dbus/connection.h>

When I disable the patch the build fails.

To explore further, I modified my build environment variables to add /usr/include/dbus-1.0/dbus:

CMAKE_INCLUDE_PATH: /opt/trinity:/opt/trinity/lib/qt3-3.3.8.d/include:/usr/include/tqt:/usr/include/dbus-1.0/dbus
CPLUS_INCLUDE_PATH: /opt/trinity/lib/qt3-3.3.8.d/include:/opt/trinity/include:/usr/include:/usr/include/tqt:/usr/include/dbus-1.0/dbus

That too failed.

Next I tried adding -DINCLUDE_DIRECTORIES="/usr/include/dbus-1.0/dbus" to the build script.

Same failure. The only solution I have discovered is to patch halbackend.h, but I'm guessing this can be solved within cmake.

What next?
Comment 8 Timothy Pearson 2012-01-12 11:46:23 CST
Created attachment 269 [details]
make mediamanager compiler search dbus include directories

That makes a lot more sense...

Try this patch, it should fix the problem.
Comment 9 Darrell 2012-01-12 14:28:58 CST
Good job! The patch works. I did not need to apply my patch.

Where are these variables defined? Seems so easy but one has to first know about the variables.
Comment 10 Timothy Pearson 2012-01-12 17:25:43 CST
(In reply to comment #9)
> Good job! The patch works. I did not need to apply my patch.
> 
> Where are these variables defined? Seems so easy but one has to first know
> about the variables.

Once you initiate a build (i.e. after gcc starts executing) look in the CMakeCache.txt file.  The file is persistent, but is only created after CMake has finished its configuration and generation processes.

Fix has been committed to GIT in hash 9cccdc1.

Thanks for reporting!
Comment 11 Darrell 2012-01-12 21:48:05 CST
Ah, CMakeCache.txt. So much to learn. Thanks!