2011-10-20, 22:45
Hello,
I think I've found a fail-to-build-from-scratch bug in the build logic. This is XBMC git 59dec9661fdcaeef88fd0af36fad272cae197e9a (2011-10-20). This has been a persistent problem for several months.
I use Slackware64 (x86-64) as my host distribution. Some packages, both official and third-party, provide a 'config.h' in their include directories.
The issue is, when any given XBMC source tries to #include <config.h>, it will use the wrong copy out of a system search path (such as mysql) in preference to the config.h generated as part of ./configure. My Makefile.include:
This causes most of the autodetected #defines in the XBMC config.h to be ignored, resulting in lots of warning spew about deprecated functions being used and macros being redefined. It will eventually fail the build when it tries to use no-longer-existing interfaces when building against ffmpeg. From http://pastebin.ca/2092015
A simple fix is to add the system -Iincludedir search list *after* the XBMC -Iincludedir list. We can do this by relocating the $(sort @INCLUDES@) to be the very last addition to the list.
When this patch is applied, XBMC sucessfully builds.
I think I've found a fail-to-build-from-scratch bug in the build logic. This is XBMC git 59dec9661fdcaeef88fd0af36fad272cae197e9a (2011-10-20). This has been a persistent problem for several months.
I use Slackware64 (x86-64) as my host distribution. Some packages, both official and third-party, provide a 'config.h' in their include directories.
Code:
root@tv:/usr/include# ls */config.h
OpenSP/config.h mcabber/config.h mysql/config.h ruby/config.h
libcgroup/config.h msn/config.h pci/config.hThe issue is, when any given XBMC source tries to #include <config.h>, it will use the wrong copy out of a system search path (such as mysql) in preference to the config.h generated as part of ./configure. My Makefile.include:
Code:
INCLUDES+=$(sort -I$(abs_top_srcdir) -I/usr/include/mysql -I/usr/include/fribidi -I/usr/include/libpng14 -I/usr/include/freetype2 -I/usr/include/alsa -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/libcec )
INCLUDES+=-I/tmp/SBo/xbmc-pre11.0git.20111020.59dec96/lib
INCLUDES+=-I/tmp/SBo/xbmc-pre11.0git.20111020.59dec96/xbmc
ifneq (1,1)
INCLUDES+=-I/tmp/SBo/xbmc-pre11.0git.20111020.59dec96/lib/ffmpeg
endif
INCLUDES+=-I/tmp/SBo/xbmc-pre11.0git.20111020.59dec96/xbmc/linux
INCLUDES+=-I/tmp/SBo/xbmc-pre11.0git.20111020.59dec96/xbmc/cores/dvdplayerThis causes most of the autodetected #defines in the XBMC config.h to be ignored, resulting in lots of warning spew about deprecated functions being used and macros being redefined. It will eventually fail the build when it tries to use no-longer-existing interfaces when building against ffmpeg. From http://pastebin.ca/2092015
Code:
In file included from /tmp/SBo/xbmc-pre11.0git.20111020.59dec96/lib/DllAvCodec.h:27:0,
from DVDOverlayCodecFFmpeg.h:25,
from DVDOverlayCodecFFmpeg.cpp:22:
/tmp/SBo/xbmc-pre11.0git.20111020.59dec96/lib/DllAvCore.h:53:32: fatal error: libavcore/avcore.h: No such file or directoryA simple fix is to add the system -Iincludedir search list *after* the XBMC -Iincludedir list. We can do this by relocating the $(sort @INCLUDES@) to be the very last addition to the list.
Code:
--- ./Makefile.include.in.orig 2011-10-20 14:22:43.681801349 -0500
+++ ./Makefile.include.in 2011-10-20 14:22:57.883801485 -0500
@@ -34,3 +34,2 @@
LDFLAGS+=@LDFLAGS@
-INCLUDES+=$(sort @INCLUDES@)
INCLUDES+=-I@abs_top_srcdir@/lib
@@ -42,2 +41,3 @@
INCLUDES+=-I@abs_top_srcdir@/xbmc/cores/dvdplayer
+INCLUDES+=$(sort @INCLUDES@)
DEFINES+= \When this patch is applied, XBMC sucessfully builds.