[poky] Library paths for Makefile based recipes

[Chris Larson]

On Tue, Dec 28, 2010 at 5:29 PM, Darren Hart <dvhart at linux.intel.com> wrote:
> I'm working on packaging kernelshark ("make gui" for the trace-cmd recipe
> basically). It fails trying to link to -lgtk-x11-2.0. I have added gtk+
> as a DEPENDS and the library does exist in the sysroots. I have also added
> "inherit pkgconfig" as the project Makefile uses it extensively.
>
> gcc trace-view-main.o trace-view.o trace-view-store.o trace-filter.o trace-compat.o trace-hash.o libtracecmd.a -rdynamic -o trace-view -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0   -L. -ltracecmd -ldl
> | /usr/bin/ld: cannot find -lgtk-x11-2.0
> | collect2: ld returned 1 exit status
> | make[1]: *** [trace-view] Error 1
> | make[1]: *** Waiting for unfinished jobs....
> | make: *** [gui] Error 2
> | FATAL: oe_runmake failed
> | ERROR: Task failed: ('function do_compile failed', '/vol/1/dvhart/poky.git/build/tmp/work/core2-poky-linux/kernelshark-1.0.4+git0+0d252224626bd6926324f023a65f20c165232891-r0/temp/log.do_compile.12830')
> NOTE: package kernelshark-1.0.4+git0+0d252224626bd6926324f023a65f20c165232891-r0: task do_compile: Failed
> ERROR: Task 8 (/home/dvhart/data/poky.git/meta/recipes-kernel/trace-cmd/kernelshark_git.bb, do_compile) failed with 1
> ERROR: '/home/dvhart/data/poky.git/meta/recipes-kernel/trace-cmd/kernelshark_git.bb' failed
>
> Without the "gui" target, trace-cmd doesn't link against anything outside of
> libc and ld, so the original recipe doesn't run into this.
>
> How does bitbake try to make the library path available to a make based
> project? I've tried various incantations from other non-autotools gtk+
> based recipes:
>
> do_compile_prepend = " \
>        export LDFLAGS='${LDFLAGS} `${STAGING_BINDIR_NATIVE}/pkg-config gtk+-2.0 --libs`'; \
>       export CFLAGS='${CFLAGS} -I./ `${STAGING_BINDIR_NATIVE}/pkg-config gtk+-2.0 --cflags`'; "

This will only work if EXTRA_OEMAKE is default, by the way.  The
default EXTRA_OEMAKE is "-e MAKEFLAGS=", which means "override all
makefile variables with the values from the environment, if they
exist, and don't pass the -e flag into submakes".

In my opinion, the better bet is to be explicit -- pass variables into
the make execution explicitly, rather than relying on exports and the
environment to do so, e.g.:

EXTRA_OEMAKE = "\
    'CC=${CC}' \
    'CFLAGS=${CFLAGS}' \
    'LFLAGS=${LDFLAGS}' \
"

Or what have you -- of course, what you pass in and how these are used
depends on the buildsystem in question.

> However, these don't appear to impact the commands executed by the project
> Makefile (despite the fact that it tries to import existing CFLAGS).

You don't want cflags, you want the ldflags, or whatever corresponding
variable is used in the makefiles.  Short answer: read the makefiles.
The default behavior for non-autotools recipes is actually an
unfortunate one: it tends to "just work" for a lot of cases, which
actually encourages people to not actually read and at least minimally
grasp the buildsystem of what they're building, which causes problems
later on.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics