EGL/GLES missing pkgconfig to facilitate building #857
Comments
|
I've sent a PR related to this issue: raspberrypi/userland#418 If you merge the PR above and include /opt/vc/lib/pkgconfig/* in libraspberrypi-dev, it will be possible to build against the Broadcom libraries by setting PKG_CONFIG_PATH=/opt/vc/lib/pkgconfig. This will also override the generic glesv2, egl and vg pkgconfig in /usr/lib/*/pkgconfig, ensuring that the new library names are always used for linking. |
|
Thanks. This will be added in the next apt firmware release. |
|
Looking at your PR, I see you want to include glesv2.pc, although in the apt release of the firmware, I was only going to go for brcm*.pc versions. |
|
Let me explain the intent of the PR more clearly. On jessie, I'm running libraspberrypi0 1.20170703-1, which contains both the originally-named libraries alongside the renamed versions: pi@retropie:~ $ dpkg -S GLESv2.so This is fine with the existing pkgconfig: However, on stretch with firmware 1.20170811: pi@retropie:~ $ dpkg -S GLESv2.so The system will no longer be able to link GLESv2 via /opt/vc/lib due to the original library now being removed. However, with my PR: This facilitates compatibility with software that runs on multiple platforms so that glesv2, egl and vg can continued to be specified in automake configurations. Even on RPI, such software will continue to link against mesa libraries by default, when the PKG_CONFIG_PATH is unset. |
|
If there is going to be a distinction between glesv2 to refer to mesa's lib and brcmglesv2 to refer to the broadcom lib, why muddy the water with something like |
|
If that's your position, I can understand. But surely you agree that the existing glesv2, egl and vg .pc files are broken with the Raspbian packages? I can rework the PR to delete the files if you want, or simply close it, if you intend to manually omit those files from the deb packages. The packaging of the pkgconfig will inform projects on how to proceed on building against the Broadcom libs. With my PR, one could build software against the VC4 driver or Broadcom libraries by specifying the PKG_CONFIG_PATH, without having to change existing build configuration. It doesn't seem optimal to encourage the current practice of people manually detecting RPI by the existence of files in /opt/vc and then manually linking -lbcm_host -lvcos -lvchiq_arm -GLESv2 (now brcmGLESv2). |
|
What in the git repos is up to @pelwell and @popcornmix, but I think the apt package will ship with the brcm*.pc only, unless there's a reason to include the other ones. I may of course be missing something. |
|
That's not as optimal as I would've hoped, but definitely would be appreciated. Just to clarify, though, you don't mean literally "brcm*.pc"? Those configurations all depend on bcm_host.pc at the minimum, so it's probably best to include everything except egl.pc, glesv2.pc and vg.pc. |
|
I have been compilling/making Kodi packages and also had problems because of this. The libraspberrypi0 definitly needs to include the pkg-config files missing, although since now it only includes the broadcom firmware files, makes more sense to include only the respective ones (brcmEGL, brcmGLESv2, etc) and include the pkg-config of the open-source/mesa driver in the respective packages. Also notice that rpi-update how it is now, includes the pkg-config files but also creates /opt/vc/lib/libEGL.so, libGLESv2, etc which it shouldn't because it can cause linking problems at compile time, mainly because they don't exist in the new Raspbian Stretch Pixel image (which makes sense in your point of view since Raspbian Stretch Pixel image only ships with the broadcom drivers). This should be only in /usr/lib/arm-linux-gnueabih/*, and created only by the mesa packages. |
|
Any problem with this approach? |
|
This looks good - thank you! Would it not be prudent to do the same for the armel packages? I use a Pi 3, so it doesn't matter to me, but it's probably a good idea to keep things consistent for both ABI types. |
|
The armel parts of the package are a bit vestigial. We don't maintain, build or use anything related to armel, at least as far as the apt repo goes. |
|
Ah, I didn't scroll far enough down to see the recent armel packages were not present. Thanks for the assistance on this matter - I think the issue can be closed now. |
When building software targeting Pi, it's common practice to use the pkgconfig to assist building by specifying PKG_CONFIG_PATH. Unfortunately, the presence of the legacy pkgconfig that conflict with Mesa's libraries will cause issues for users that build against the firmware pkgconfig, but wish to target Mesa. (Pi 4B or earlier revisions using the f/kms overlay). Although a possible workaround may be to omit the custom PKG_CONFIG_PATH of the firmware pkgconfig during build, there are plausible use cases in which to target a software build against Mesa whilst also leveraging the non GL-specific firmware libraries (e.g. MMAL for hardware codec support that works on the FKMS overlay, or BCM_HOST for basic board detection). Note: this conflict is already resolved via the Raspbian packages by deliberately omitting the conflicting .pc files during the packaging stage; see raspberrypi/firmware#857
When building software targeting Pi, it's common practice to use the pkgconfig to assist building by specifying PKG_CONFIG_PATH. Unfortunately, the presence of the legacy pkgconfig that conflict with Mesa's libraries will cause issues for users that build against the firmware pkgconfig, but wish to target Mesa. (Pi 4B or earlier revisions using the f/kms overlay). Although a possible workaround may be to omit the custom PKG_CONFIG_PATH of the firmware pkgconfig during build, there are plausible use cases in which to target a software build against Mesa whilst also leveraging the non GL-specific firmware libraries (e.g. MMAL for hardware codec support that works on the FKMS overlay, or BCM_HOST for basic board detection). Note: this conflict is already resolved via the Raspbian packages by deliberately omitting the conflicting .pc files during the packaging stage; see raspberrypi/firmware#857
Hi,
On Debian stretch, the libraspberrypi0 and libraspberrypi-dev packages now use renamed Broadcom libraries for GLES/EGL/OpenVG, but the packages don't include the requisite pkg-config files (which are present in the repository) to enable successful configuration.
Would you be able to package https://github.com/raspberrypi/firmware/tree/master/hardfp/opt/vc/lib/pkgconfig/*.pc in future deb packages? Installing to /opt/vc/lib/pkgconfig will not be sufficient, as pkg-config looks for configuration in /usr/lib/pkgconfig, /usr/share/pkgconfig, /usr/local/lib/pkgconfig and /usr/local/share/pkgconfig.
The PKG_CONFIG_PATH
environment variable will still need to be set to /opt/vc/lib/pkgconfig, but the dummy .pc files using the original names (egl.pc, gl.pc, vg.pc) in their current state would cause problems. I've open a PR for that: raspberrypi/userland#418
Here's an example on an issue that's arisen due to the stretch upgrade: libretro/RetroArch#5351
The text was updated successfully, but these errors were encountered: