This is about the relative prefix= definition in dbus-1.pc.

An upstream Libreoffice tree, configured with default options no longer builds
on Fedora 42 beta, but does on 41.
After some debug and discussion on the Libreoffice mailing list, and discussion on the Fedora Libreoffice SIG matrix channel, the conclusion is to file a dbus bug
to see what's going on.

The libreoffice archive discussion is:

https://lists.freedesktop.org/archives/libreoffice/2025-March/093126.html

The problem is triggered on a default libreoffice build configured with:
./configure --srcdir=whereever --enable-option-checking=fatal --enable-debug

it builds it's own ICU library (currently v77) but ends up linking with the systems v 76; the reason for the difference is the path search order at linking;  the link path ends up being:
 -Wl,--start-group  -L/usr/lib64/pkgconfig/../../lib64 -ldbus-1  -L$W/UnpackedTarball/icu/source/lib -licui18n -L$W/UnpackedTarball/icu/source/lib -licuuc  -L$W/UnpackedTarball/curl/lib/.libs -lcurl   -Wl,--end-group

with the strange '-L/usr/lib64/pkgconfig/../../lib64' at the start;  I tracked that down to the /usr/lib64/pkgconfig/dbus-1.pc
prefix=${pcfiledir}/../..

All the other .pc's I have - other than librsvg - have a simple absolute path.
LO's build scripts filter out the obvious system paths, but this relative path confuses it.

So I guess the question is really why is this one and librsvg's relative?  And is this new?
I'm a bit confused in upstream which seems to be different between cmake and ninja builds - but I'm not sure I understand what's going on.

Reproducible: Always

Steps to Reproduce:
1. git clone https://git.libreoffice.org/core
2. cd core
3. ./autogen.sh
4. ./configure --srcdir=$PWD --enable-option-checking=fatal --enable-debug
5. make debug=t
Actual Results:  
/desktop/source/lib/init.cxx:6354: error: undefined reference to 'ublock_getCode_77'

Expected Results:  
A nice happy LO build

dbus-devel-1.16.0-3.fc42.x86_64