New comment by newbluemoon on void-packages repository

https://github.com/void-linux/void-packages/pull/11891#issuecomment-507023934
Comment:
I tried with the `fmit` package. The problem was that `qmake` hardcoded the required qt-libraries `fmit` is linked to in the `Makefile` when generating it with a full path (`/usr/lib/...`) which fails, of course, when cross-compiling.

The `qt.conf` has to be in `.../masterdir/usr/lib/qt5/bin/`. For now I just put it there manually. I used the one from above, just changed

    Libraries=/usr/lib

to

    Libraries=/usr/armv7l-linux-musleabihf/usr/lib

and that worked. `qmake` used the right paths in the generated `Makefile` and the package was built successfully. Just haven’t tested it on my RPi, but don’t think there will be a problem.

It would be nice to do the same for the includes so that the required qt-modules don’t have to be added to `hostmakedepends` in the cross-case anymore, but the required `*.pri` files in `/usr/lib/qt5/mkspecs/modules/` are still missing in the cross-devel-packages. The same persisting problem I mentioned above. But we will find a solution one day! ;)

Perhaps it’s best to generate `qt.conf` in the build-style and insert the corresponding target architecture there. Then after the build remove the file.

A sidenote: You can check if `qmake` uses `qt.conf` when you `xbps-src chroot` into the masterdir and run `qmake -query`. The modified values should be displayed.

However, I also tested `zrandr` and there was a problem with `lrelease`. But this could be an entirely different problem. I’ll look into it.

Also, I think it might be a good idea to check all qmake-style packages if other problems arise or if changing that path leads to new ones. Anyway, I’ll try to check some more. :)