[Buildroot] prefix question for kodi.

[Samuel Martin]

Hi Dagg, all,

On Tue, Jul 12, 2016 at 6:19 PM, daggs <daggs at gmx.com> wrote:
> Greetings,
>
>> Sent: Tuesday, July 12, 2016 at 9:11 AM
>> From: "Samuel Martin" <s.martin49 at gmail.com>
>> To: daggs <daggs at gmx.com>
>> Subject: Re: [Buildroot] prefix question for kodi.
>>
>> Hi all,
>>
>> On Tue, Jul 12, 2016 at 7:24 AM, daggs <daggs at gmx.com> wrote:
>> > Greetings,
>> >
>> >> Hi all,
>> >>
>> >> On Mon, Jul 11, 2016 at 11:00 PM, daggs <daggs at gmx.com> wrote:
>> >> > Greetings,
>> >> >
>> >> >> This is not Kodi-specific, this is done like things for many packages
>> >> >> (i.e. for all packages using a decent build-system, e.g. autotools
>> >> >> [1], cmake [2], etc).. So, almost all packages.
>> >> >>
>> >> >> For building a target package, the prefix must point to /usr, and not
>> >> >> to the staging dir. because:
>> >> >> 1. The --prefix option sets the prefix location in the target
>> >> >> directory, i.e. as its should be at runtime (at runtime in the target
>> >> >> system).
>> >> >> So, in the case of Buildroot, this is not (and must not be) the
>> >> >> absolute location where stuff will be installed.
>> >> >> Note that if you set prefix to STAGING_DIR, I bet your final rootfs
>> >> >> won't look like what you'd expect, and may not work as expected... or
>> >> >> not work at all!
>> >> >> 2. To install stuff in a location different from the runtime one, we
>> >> >> use the standard variable DESTDIR (see [3,4])
>> >> >> So, basically when a package using a decent build-system execute an
>> >> >> install rule, it computes the install location like this:
>> >> >>   stuff_install_path = ${DESTDIR}${prefix}/${stuf_dir}
>> >> >> 3. We don't (want to) build target packages twice, with only the
>> >> >> --prefix option changed between these 2 builds (i.e. once with
>> >> >> --prefix=$(STAGING_DIR)... and a second time with
>> >> >> --prefix=$(TARGET_DIR)...).
>> >> >> So, from the aforementioned reasons we build each target package once
>> >> >> with the right prefix for the target rootfs, and install twice (if
>> >> >> needed), once with DESTDIR=$(TARGET_DIR) and a second time with
>> >> >> DESTDIR=$(STAGING_DIR), see [3,4].
>> >> >>
>> >> >> Note that for the build, things are correctly routed to the staging
>> >> >> dir. thanks to:
>> >> >> - the --sysroot option, optionally with -I.. or -L.. pointing to the
>> >> >> staging tree;
>> >> >> - the Buildroot compiler wrapper that enforce these options to be
>> >> >> correctly set, and also check for poisoning paths (i.e. paths pointing
>> >> >> to standard host system locations, e.g. /usr/lib or /usr/local/lib,
>> >> >> etc).
>> >> >>
>> >> >> So, unless you are not lucky packaging a projet that use a
>> >> >> non-standard build-system, or does nasty things at configure-time, you
>> >> >> should not  paid much attention to this prefix option, Buildroot
>> >> >> handles it for you ;-)
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> [1] https://github.com/buildroot/buildroot/blob/master/package/pkg-autotools.mk#L181
>> >> >> [2] https://github.com/buildroot/buildroot/blob/master/package/pkg-cmake.mk#L91
>> >> >> [3] https://github.com/buildroot/buildroot/blob/master/package/pkg-autotools.mk#L159
>> >> >> [4] https://github.com/buildroot/buildroot/blob/master/package/pkg-cmake.mk#L60
>> >> >>
>> >> >> --
>> >> >> Samuel
>> >> >>
>> >> >
>> >> > thanks for the detailed explenation, I'm not trying to do anyting fancy, only compile kodi with the --enable-codec=amcodec.
>> >> On an autotools package, it should be pretty straight forward...
>> >>
>> >> > as seen in my previous mail, there is no --sysroot passed to kodi, also unless I'm misunderstood something,
>> >> As mentioned above, the Buildroot wrapper ensure --sysroot is
>> >> correctly passed to the actual cross-compiler, but may not print it on
>> >> standard verbose make call. To see the actual full command, try
>> >> setting the BR2_DEBUG_WRAPPER env. var. [5].
>> > thanks for the tip, will enable it take a look.
>> >
>> >>
>> >> > using the DESTDIR doesn't help at it is blank.
>> >> DESTDIR is only useful at install time, not configure/build/run time.
>> > I see, so DESTDIR is not what I need.
>> >
>> >>
>> >> > my issue is that when amcodec is enabled, one of kodi's makefiles define adds new incldue path as follows: ${prefix}/usr/include/<something>.
>> >> > as prefix is empty, instead of searching the code at staging's sysroot, it searches it on the local machine's path,
>> >> Here is your issue.
>> >>
>> >> Few hints to move forward:
>> >> 1- identify what Makefile{,.in,.am} sets this;
>> > found it.
>> >
>> >> 2- how this makefile set this? does it call a *-config script, or call
>> >> pkg_check_modules, or get it from some options/env. vars. when
>> >> invoking the configure script (check: ./configure --help), or  just do
>> >> nasty things manually/handwritten?
>> > not sure I follow, buildroot does not call it, the kodi makefile does that.
>> I meant the makefile from kodi's source.
>> In this makefile, how does this "${prefix}/usr/include/<something>"
>> end in some variables?
>> Is it:
>> - filled thanks to a call to pkg-config or some *-config script? (be
>> carefull here, some intermediate variables set in the configure
>> scripts may be used)
>> - or filled from env. vars. and/or options from the configure script?
>> - or just handwritten/hard-coded in the makefile?
>> - or anything else?
>> Once you have tracked down how this path ends up in the flags, it will
>> be easier to know how to fix this the proper way.
> you can find the code in question at https://github.com/xbmc/xbmc/blob/Jarvis/xbmc/cores/dvdplayer/DVDCodecs/Video/Makefile.in#L26
> the issue is quite simple to understand.
>
In such case, I would fix upstream like this:

ifeq (@USE_LIBAMCODEC@,1)
LIBAMCODEC_INCLUDES ?= -I$(prefix)/include/amcodec -I$(prefix)/include/amplayer
SRCS += AMLCodec.cpp
SRCS += DVDVideoCodecAmlogic.cpp
INCLUDES += $(LIBAMCODEC_INCLUDES)
endif

Then, this allows to override LIBAMCODEC_INCLUDES via the make command
line (or make environment)

>>
>> >
>> >> 3- does amcodec provides a *-config script or a pkg-config module (i.e. a *.pc)?
>> > no, it is a simple makefile project. just enter the folder and run make.
>> Ok.
>> This certainly means you'll have to do something like (in the
>> Buildroot's kodi.mk file):
>>
>> KODI_CFLAGS = $(TARGET_CFLAGS)
>> ...
>> ifeq ($(BR2_PACKAGE_LIBAMCODEC),y)
>> KODI_CONF_OPTS += --enable-amcodec
>> KODI_DEPENDENCIES += libamcodec
>> KODI_CFLAGS += -I$(STAGING_DIR)/usr/include/<something>
>> KODI_LDFLAGS += -L$(STAGING_DIR)/usr/lib -lamcodec
>> else
>> KODI_CONF_OPTS += --disable-amcodec
>> endif
>> ...
>> KODI_CONF_ENV += CFLAGS="$(KODI_CFLAGS)" LDFAGS="$(KODI_LDFLAGS)"
> ok, I see where you are going, that might help.
> will take into account, thanks.

So, here you just need to do:
ifeq ($(BR2_PACKAGE_LIBAMCODEC),y)
KODI_CONF_OPTS += --enable-amcodec
KODI_DEPENDENCIES += libamcodec
KODI_CONF_ENV +=
LIBAMCODEC_INCLUDES="-I$(STAGING_DIR)/usr/include/amcodec
-I$(STAGING_DIR)/usr/include/amplayer"
else
KODI_CONF_OPTS += --disable-amcodec
endif

>
>>
>> >
>> >>
>> >> Depending on your findings in kodi and amcodec, you may need to patch
>> >> the culprit (make?)file from kodi...
>> >>
>> >> > generating a WARNING: unsafe header/library path used in cross-compilation error.
>> >> This is the poisin path check ;)
>> >>
>> >> >
>> >> > how can I use DESTDIR properly?
>> >> I'm not sure you need to do anything special about it.
>> >> AFAICS, amcodec is autotools-based, so everything should already be
>> >> correctly handled.
>> > per your comment above, this isn't the var I need.
>> >
>> > Dagg.
>>
>> Regards,
>>
>> --
>> Samuel
>>
>
> Dagg.

Regards,

-- 
Samuel