dbus installs one header in a weird location where it cannot find it, which breaks qt53-kde

[barracuda156]

Not sure why, but one of dbus headers is installed into /opt/local/lib/dbus-1.0/include/dbus/dbus-arch-deps.h instead of a normal location. However, /opt/local/include/dbus-1.0/dbus/dbus.h has that header together with others:

#include <dbus/dbus-arch-deps.h>
#include <dbus/dbus-address.h>
#include <dbus/dbus-bus.h>
#include <dbus/dbus-connection.h>
#include <dbus/dbus-errors.h>
#include <dbus/dbus-macros.h>
#include <dbus/dbus-message.h>
#include <dbus/dbus-misc.h>
#include <dbus/dbus-pending-call.h>
#include <dbus/dbus-protocol.h>
#include <dbus/dbus-server.h>
#include <dbus/dbus-shared.h>
#include <dbus/dbus-signature.h>
#include <dbus/dbus-syntax.h>
#include <dbus/dbus-threads.h>
#include <dbus/dbus-types.h>

So nothing can find it, and configure of qt53-kde breaks down on dbus with a fatal error.

[RJVB]

On Monday January 27 2025 09:08:01 Sergey Fedorov wrote: Not sure why, but one of `dbus` headers is installed into `/opt/local/lib/dbus-1.0/include/dbus/dbus-arch-deps.h` instead of a normal location.

It's the normal location for that header: the dbus-1.pc pkgconfig file has ``` Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include ```

So nothing can find it, and configure of `qt53-kde` breaks down on dbus with a fatal error.

In fact, Qt 5.3 probably wasn't tested with this new a dbus version. The easiest thing to do would to add the missing -I flag to configure.cppflags .

[barracuda156]

Looks like this is some systemic issue with Qt. It cannot find glibconfig.h, which is also located in the similar odd directory. (Perhaps it fails to use pkgconfig properly?)

[RJVB]

On Monday January 27 2025 09:43:31 Sergey Fedorov wrote: Looks like this is some systemic issue with Qt. It cannot find `glibconfig.h`, which is also located in the similar odd directory.

we'll have to assume that freedesktop.org project started putting headers like these (whatever that means) under $prefix/lib (well) after Qt 5.3 stopped getting updates. A quick look at the mainstream port:qt53 didn't reveal any special fixes and so unless the current port:dbus and port:glib2 change the install location of these headers, port:qt53 will fail similarly. IMHO the proper thing to do here would be to test that (on "supported" Mac I guess) and then file a trac ticket to see how the issue is solved. If you don't want to bother with that the best workaround will be to add the missing paths or to symlink the headers to somewhere under $workpath and add that path with a -I flag. That will have the advantage of not having to rerun the configure step each time you discover a header that's not being found.