Build fails for Vim (S905X) Mali target.
Should build fine.
LD retroarch
obj-unix/release/gfx/video_driver.o:video_driver.c:gfx_ctx_drivers: error: undefined reference to 'gfx_ctx_mali_fbdev'
collect2: error: ld returned 1 exit status
make: *** [Makefile:195: retroarch] Error 1
Build log -> https://pastebin.com/drC5qyLb
Update your lokal repo to commit 2bd70abfcdc737bb71b8aed9924a3ee146e58854 or later and try to compile it for Mali.
This commit builds fine b2e8a7add2b3d7712c0160e5c7c636a2a440be37 <- latest working commit
Latest LibreELEC 9.0 build system -> cross compile
Package file: https://github.com/5schatten/LibreELEC.tv/blob/libreelec-9.0-rr/packages/5schatten/emulation-frontends/retroarch/package.mk
Can you find the first bad commit so we know when this started?
I don't have any mali hardware to test.
Please share a full configure and build log.
Does this work?
PKG_CONF_PATH=none ./configure
make
@orbea well... I already included all of these information. There is a full build log included and the last working commit was https://github.com/libretro/RetroArch/commit/b2e8a7add2b3d7712c0160e5c7c636a2a440be37 and this is the package https://github.com/5schatten/LibreELEC.tv/blob/libreelec-9.0-rr/packages/5schatten/emulation-frontends/retroarch/package.mk
I'm rebuilding an RPi image right now to see if it limited to Mali stuff.
Sorry, I missed the build log and only saw the package.mk.
There are a few commits between https://github.com/libretro/RetroArch/commit/b2e8a7add2b3d7712c0160e5c7c636a2a440be37 and https://github.com/libretro/RetroArch/commit/2bd70abfcdc737bb71b8aed9924a3ee146e58854 so I'm not sure which one is the first bad one.
Now that I am looking at the build log I see you are not building the relevant mali file.
I suppose the root issue is this check_pkgconf check is failing.
Checking presence of package egl ... no
The issue probably started here.
https://github.com/libretro/RetroArch/commit/2bd70abfcdc737bb71b8aed9924a3ee146e58854#diff-64b12eb68f319652c8ff364e7ef9f561R244
Where before it would fall back to check_lib if check_pkgconf failed which unfortunately subtly broke the version checks...
So I suppose the good solution is to find out why your pkg-config is not finding egl.pc and how to fix it...
Alternatively this will probably work even if the previous suggestion would be better.
diff --git a/qb/config.libs.sh b/qb/config.libs.sh
index fd9a4cdf31..e58a12b4f2 100644
--- a/qb/config.libs.sh
+++ b/qb/config.libs.sh
@@ -107,7 +107,7 @@ if [ "$HAVE_SSE" = "yes" ]; then
fi
if [ "$HAVE_EGL" != "no" ] && [ "$OS" != 'Win32' ]; then
- check_val '' EGL "-l${VC_PREFIX}EGL $EXTRA_GL_LIBS" '' "${VC_PREFIX}egl" '' ''
+ check_val '' EGL "-l${VC_PREFIX}EGL $EXTRA_GL_LIBS" '' "${VC_PREFIX}egl" '' '' true
if [ "$HAVE_EGL" = "yes" ]; then
EGL_LIBS="$EGL_LIBS $EXTRA_GL_LIBS"
fi
diff --git a/qb/qb.libs.sh b/qb/qb.libs.sh
index 1dfaeb7f99..8a253ded95 100644
--- a/qb/qb.libs.sh
+++ b/qb/qb.libs.sh
@@ -240,9 +240,10 @@ check_switch()
# $5 = package
# $6 = version [checked only if non-empty]
# $7 = critical error message [checked only if non-empty]
+# $8 = forces check_lib when check_pkgconf fails when true [checked only if non-empty]
check_val()
{ check_pkgconf "$2" "$5" "$6" "${7:-}"
- [ "$PKG_CONF_PATH" = "none" ] || return 0
+ [ "$PKG_CONF_PATH" = "none" ] || [ "${8:-}" = true ] || return 0
tmpval="$(eval "printf %s \"\$HAVE_$2\"")"
oldval="$(eval "printf %s \"\$TMP_$2\"")"
if [ "$tmpval" = 'no' ] && [ "$oldval" != 'no' ]; then
Basically this is a mali bug that was fixed in 2014, but no one bothered to merge the PR...
https://github.com/linux-sunxi/sunxi-mali/pull/8
And further background.
https://github.com/linux-sunxi/meta-sunxi/issues/24
I suppose the above fix is good enough...
@orbea
In fact Generic builds come with egl.pc created by the Mesa 3D package. RPi builds provide brcmegl.pc but the package used by Amlogic builds is missing something similar.
I asked the LE devs about this maybe they have a clue why it's missing. Lakka 3.0 will probably have this issue as well if they use the LE 9.0 repo.
I think the main problem is that even if its fixed everywhere today it will take time for users to update their systems to include these fixes. And I would not be surprised if more than one vendor does this.
Hopefully everyone will move to using only mesa in time and this problem will go away.
Most helpful comment
I think the main problem is that even if its fixed everywhere today it will take time for users to update their systems to include these fixes. And I would not be surprised if more than one vendor does this.
Hopefully everyone will move to using only mesa in time and this problem will go away.