Library paths for Makefile based recipes

Library paths for Makefile based recipes

[Darren Hart]

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`'; "

export VERBOSE=1
CFLAGS += "-L ${STAGING_LIBDIR}"
LDFLAGS += "-L ${STAGING_LIBDIR}"
CFLAGS_prepend = "-L ${STAGING_LIBDIR}"
LDFLAGS_prepend = "-L ${STAGING_LIBDIR}"

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

-- 
Darren Hart
Yocto Linux Kernel

Re: Library paths for Makefile based recipes

[Chris Larson]

On Tue, Dec 28, 2010 at 5:29 PM, Darren Hart <dvhart@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

Re: Library paths for Makefile based recipes

[Tian, Kevin]

>From: Darren Hart
>Sent: Wednesday, December 29, 2010 8:30 AM
>
>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

it looks that native gcc/binutils are used here, instead of the cross one. Or else gcc 
should have a target prefix like i568-poky-linux-gcc, and ld should come from your 
native sysroot...

>| 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+0d2522
>24626bd6926324f023a65f20c165232891-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.

given earlier confusion, I'm worried whether original trace-cmd does work as expected,
e.g. whether it runs on a non-x86 target?

>
>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`'; "
>
>export VERBOSE=1
>CFLAGS += "-L ${STAGING_LIBDIR}"
>LDFLAGS += "-L ${STAGING_LIBDIR}"
>CFLAGS_prepend = "-L ${STAGING_LIBDIR}"
>LDFLAGS_prepend = "-L ${STAGING_LIBDIR}"
>
>However, these don't appear to impact the commands executed by the project
>Makefile (despite the fact that it tries to import existing CFLAGS).
>

No idea here. You may need check the Makefile carefully whether there's any
tricky lines breaking things here... At least you may change Makefile directly first. :-)

Thanks
Kevin

Re: Library paths for Makefile based recipes

[Darren Hart]

On 12/28/2010 04:43 PM, Tian, Kevin wrote:
>> From: Darren Hart
>> Sent: Wednesday, December 29, 2010 8:30 AM
>>
>> 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
>
> it looks that native gcc/binutils are used here, instead of the cross one. Or else gcc
> should have a target prefix like i568-poky-linux-gcc, and ld should come from your
> native sysroot...


Yes, I noticed this too. Turns out the Makefile was forcing CC=gcc.


>
>> | 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+0d2522
>> 24626bd6926324f023a65f20c165232891-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.
>
> given earlier confusion, I'm worried whether original trace-cmd does work as expected,
> e.g. whether it runs on a non-x86 target?


I'm confident it does not. I'll be sending a fix for that along with my 
kernelshark recipe.


>
>>
>> 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`'; "
>>
>> export VERBOSE=1
>> CFLAGS += "-L ${STAGING_LIBDIR}"
>> LDFLAGS += "-L ${STAGING_LIBDIR}"
>> CFLAGS_prepend = "-L ${STAGING_LIBDIR}"
>> LDFLAGS_prepend = "-L ${STAGING_LIBDIR}"
>>
>> However, these don't appear to impact the commands executed by the project
>> Makefile (despite the fact that it tries to import existing CFLAGS).
>>
>
> No idea here. You may need check the Makefile carefully whether there's any
> tricky lines breaking things here... At least you may change Makefile directly first. :-)

Yes, this is the path I took. Now working back up the stack to try and 
get it working with poky.

Thanks,

-- 
Darren Hart
Yocto Linux Kernel

Re: Library paths for Makefile based recipes

[Darren Hart]

On 12/28/2010 04:41 PM, Chris Larson wrote:
> On Tue, Dec 28, 2010 at 5:29 PM, Darren Hart<dvhart@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`'; "
>

Turns out the project Makefile is doing this:

CC = $(CROSS_COMPILE)gcc
AR = $(CROSS_COMPILE)ar

Removing those lines from the Makefile allows the project to build.


> 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}' \
> "

The Makefile ignores LDFLAGS, but that doesn't appear to be necessary if
you actually use the right compiler :) Leaving the Makefile alone and 
trying something like the above works for me.

I'll be taking a closer look at the Makefile, it's a rather complex 
beast and I suspect more dragons are lurking.

Thanks!

-- 
Darren Hart
Yocto Linux Kernel

Re: Library paths for Makefile based recipes

[Koen Kooi]

Op 29 dec 2010, om 01:29 heeft Darren Hart het volgende geschreven:

> 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.

'inherit pkgconfig' only does DEPENDS_prepend = "pkgconfig-native "

regards,

Koen

Re: Library paths for Makefile based recipes

[Darren Hart]

On 12/29/2010 01:18 AM, Koen Kooi wrote:
>
> Op 29 dec 2010, om 01:29 heeft Darren Hart het volgende geschreven:
>
>> 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.
>
> 'inherit pkgconfig' only does DEPENDS_prepend = "pkgconfig-native "

Right, but omitting it could result in the package being built using the 
host pkg-config, which shouldn't be a build dependency.


-- 
Darren Hart
Yocto Linux Kernel

Re: Library paths for Makefile based recipes

[Richard Purdie]

On Wed, 2010-12-29 at 08:19 -0800, Darren Hart wrote:
> On 12/29/2010 01:18 AM, Koen Kooi wrote:
> >
> > Op 29 dec 2010, om 01:29 heeft Darren Hart het volgende geschreven:
> >
> >> 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.
> >
> > 'inherit pkgconfig' only does DEPENDS_prepend = "pkgconfig-native "
> 
> Right, but omitting it could result in the package being built using the 
> host pkg-config, which shouldn't be a build dependency.

Worse, it might use the host systems pkgconfig which might have broken
sysroot support or suffer from some other issues our own pkgconfig does
not.

E.g:

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/recipes-devtools/pkgconfig/pkgconfig/disable-legacy.patch

and versions prior to 0.25 have broken sysroot support.

Cheers,

Richard

Re: Library paths for Makefile based recipes

[Richard Purdie]

On Tue, 2010-12-28 at 16:58 -0800, Darren Hart wrote:
> Turns out the project Makefile is doing this:
> 
> CC = $(CROSS_COMPILE)gcc
> AR = $(CROSS_COMPILE)ar
> 
> Removing those lines from the Makefile allows the project to build.

You could also set CROSS_COMPILE to the right value (TARGET_PREFIX?) and
things should work. This looks very similar to how we cross compile the
kernel.

Cheers,

Richard

Re: Library paths for Makefile based recipes

[Chris Larson]

On Thu, Dec 30, 2010 at 4:21 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2010-12-28 at 16:58 -0800, Darren Hart wrote:
>> Turns out the project Makefile is doing this:
>>
>> CC = $(CROSS_COMPILE)gcc
>> AR = $(CROSS_COMPILE)ar
>>
>> Removing those lines from the Makefile allows the project to build.
>
> You could also set CROSS_COMPILE to the right value (TARGET_PREFIX?) and
> things should work. This looks very similar to how we cross compile the
> kernel.

I'm not familiar with this particular project, but unless it's bare
metal or nearly so like a kernel or bootloader, that's likely not a
good idea, since it won't end up obeying our TARGET_CC_ARCH.  An
alternative to setting CC/AR in EXTRA_OEMAKE or removing those lines
from the makefile would be to set them there, but using ?=.  This
would let the versions in the environment be used in preference to
those.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Library paths for Makefile based recipes

[Darren Hart]

On 12/30/2010 03:21 AM, Richard Purdie wrote:
> On Tue, 2010-12-28 at 16:58 -0800, Darren Hart wrote:
>> Turns out the project Makefile is doing this:
>>
>> CC = $(CROSS_COMPILE)gcc
>> AR = $(CROSS_COMPILE)ar
>>
>> Removing those lines from the Makefile allows the project to build.
>
> You could also set CROSS_COMPILE to the right value (TARGET_PREFIX?) and
> things should work. This looks very similar to how we cross compile the
> kernel.

I tried that first, it led to loads of cross-compilation errors. I 
didn't investigate much further as explicitly setting CC, AR, etc for 
oe_runmake resolved the issue.

-- 
Darren Hart
Yocto Linux Kernel

Re: Library paths for Makefile based recipes

[Darren Hart]

On 12/30/2010 06:11 AM, Chris Larson wrote:
> On Thu, Dec 30, 2010 at 4:21 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org>  wrote:
>> On Tue, 2010-12-28 at 16:58 -0800, Darren Hart wrote:
>>> Turns out the project Makefile is doing this:
>>>
>>> CC = $(CROSS_COMPILE)gcc
>>> AR = $(CROSS_COMPILE)ar
>>>
>>> Removing those lines from the Makefile allows the project to build.
>>
>> You could also set CROSS_COMPILE to the right value (TARGET_PREFIX?) and
>> things should work. This looks very similar to how we cross compile the
>> kernel.
>
> I'm not familiar with this particular project, but unless it's bare
> metal or nearly so like a kernel or bootloader, that's likely not a
> good idea, since it won't end up obeying our TARGET_CC_ARCH.  An
> alternative to setting CC/AR in EXTRA_OEMAKE or removing those lines
> from the makefile would be to set them there, but using ?=.  This
> would let the versions in the environment be used in preference to
> those.

I'll ask Steven if he'd accept such a change.


-- 
Darren Hart
Yocto Linux Kernel

Re: Library paths for Makefile based recipes

[Bruce Ashfield]

On Tue, Dec 28, 2010 at 7:54 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> On 12/28/2010 04:43 PM, Tian, Kevin wrote:
>>>
>>> From: Darren Hart
>>> Sent: Wednesday, December 29, 2010 8:30 AM
>>>
>>> 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
>>
>> it looks that native gcc/binutils are used here, instead of the cross one.
>> Or else gcc
>> should have a target prefix like i568-poky-linux-gcc, and ld should come
>> from your
>> native sysroot...
>
>
> Yes, I noticed this too. Turns out the Makefile was forcing CC=gcc.
>
>
>>
>>> | 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+0d2522
>>> 24626bd6926324f023a65f20c165232891-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.
>>
>> given earlier confusion, I'm worried whether original trace-cmd does work
>> as expected,
>> e.g. whether it runs on a non-x86 target?
>
>
> I'm confident it does not. I'll be sending a fix for that along with my
> kernelshark recipe.

Something smells wrong here, must have been an update to trace-cmd,
I ran trace-cmd on all architectures when doing the initial work. So I'm
quite confident that it did :)

Bruce

>
>
>>
>>>
>>> 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`'; "
>>>
>>> export VERBOSE=1
>>> CFLAGS += "-L ${STAGING_LIBDIR}"
>>> LDFLAGS += "-L ${STAGING_LIBDIR}"
>>> CFLAGS_prepend = "-L ${STAGING_LIBDIR}"
>>> LDFLAGS_prepend = "-L ${STAGING_LIBDIR}"
>>>
>>> However, these don't appear to impact the commands executed by the
>>> project
>>> Makefile (despite the fact that it tries to import existing CFLAGS).
>>>
>>
>> No idea here. You may need check the Makefile carefully whether there's
>> any
>> tricky lines breaking things here... At least you may change Makefile
>> directly first. :-)
>
> Yes, this is the path I took. Now working back up the stack to try and get
> it working with poky.
>
> Thanks,
>
> --
> Darren Hart
> Yocto Linux Kernel
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: Library paths for Makefile based recipes

[Bruce Ashfield]

On Thu, Dec 30, 2010 at 4:08 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Tue, Dec 28, 2010 at 7:54 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>> On 12/28/2010 04:43 PM, Tian, Kevin wrote:
>>>>
>>>> From: Darren Hart
>>>> Sent: Wednesday, December 29, 2010 8:30 AM
>>>>
>>>> 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
>>>
>>> it looks that native gcc/binutils are used here, instead of the cross one.
>>> Or else gcc
>>> should have a target prefix like i568-poky-linux-gcc, and ld should come
>>> from your
>>> native sysroot...
>>
>>
>> Yes, I noticed this too. Turns out the Makefile was forcing CC=gcc.
>>
>>
>>>
>>>> | 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+0d2522
>>>> 24626bd6926324f023a65f20c165232891-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.
>>>
>>> given earlier confusion, I'm worried whether original trace-cmd does work
>>> as expected,
>>> e.g. whether it runs on a non-x86 target?
>>
>>
>> I'm confident it does not. I'll be sending a fix for that along with my
>> kernelshark recipe.
>
> Something smells wrong here, must have been an update to trace-cmd,
> I ran trace-cmd on all architectures when doing the initial work. So I'm
> quite confident that it did :)

Hit send too soon. A quick check shows that we were carrying a patch
that modified trace-cmd a bit, which might explain how it was working
on all archs previously.

Bruce

>
> Bruce
>
>>
>>
>>>
>>>>
>>>> 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`'; "
>>>>
>>>> export VERBOSE=1
>>>> CFLAGS += "-L ${STAGING_LIBDIR}"
>>>> LDFLAGS += "-L ${STAGING_LIBDIR}"
>>>> CFLAGS_prepend = "-L ${STAGING_LIBDIR}"
>>>> LDFLAGS_prepend = "-L ${STAGING_LIBDIR}"
>>>>
>>>> However, these don't appear to impact the commands executed by the
>>>> project
>>>> Makefile (despite the fact that it tries to import existing CFLAGS).
>>>>
>>>
>>> No idea here. You may need check the Makefile carefully whether there's
>>> any
>>> tricky lines breaking things here... At least you may change Makefile
>>> directly first. :-)
>>
>> Yes, this is the path I took. Now working back up the stack to try and get
>> it working with poky.
>>
>> Thanks,
>>
>> --
>> Darren Hart
>> Yocto Linux Kernel
>> _______________________________________________
>> poky mailing list
>> poky@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky
>>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: Library paths for Makefile based recipes

[Darren Hart]

On 12/30/2010 01:10 PM, Bruce Ashfield wrote:
> On Thu, Dec 30, 2010 at 4:08 PM, Bruce Ashfield
> <bruce.ashfield@gmail.com>  wrote:
>> On Tue, Dec 28, 2010 at 7:54 PM, Darren Hart<dvhart@linux.intel.com>  wrote:
>>> On 12/28/2010 04:43 PM, Tian, Kevin wrote:
>>>>>
>>>>> From: Darren Hart
>>>>> Sent: Wednesday, December 29, 2010 8:30 AM
>>>>>
>>>>> 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
>>>>
>>>> it looks that native gcc/binutils are used here, instead of the cross one.
>>>> Or else gcc
>>>> should have a target prefix like i568-poky-linux-gcc, and ld should come
>>>> from your
>>>> native sysroot...
>>>
>>>
>>> Yes, I noticed this too. Turns out the Makefile was forcing CC=gcc.
>>>
>>>
>>>>
>>>>> | 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+0d2522
>>>>> 24626bd6926324f023a65f20c165232891-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.
>>>>
>>>> given earlier confusion, I'm worried whether original trace-cmd does work
>>>> as expected,
>>>> e.g. whether it runs on a non-x86 target?
>>>
>>>
>>> I'm confident it does not. I'll be sending a fix for that along with my
>>> kernelshark recipe.
>>
>> Something smells wrong here, must have been an update to trace-cmd,
>> I ran trace-cmd on all architectures when doing the initial work. So I'm
>> quite confident that it did :)
>
> Hit send too soon. A quick check shows that we were carrying a patch
> that modified trace-cmd a bit, which might explain how it was working
> on all archs previously.

Where is this patch? Is it one we need to re-apply or send to Steven?

-- 
Darren Hart
Yocto Linux Kernel

Re: Library paths for Makefile based recipes

[Bruce Ashfield]

On Thu, Dec 30, 2010 at 5:31 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> On 12/30/2010 01:10 PM, Bruce Ashfield wrote:
>>
>> On Thu, Dec 30, 2010 at 4:08 PM, Bruce Ashfield
>> <bruce.ashfield@gmail.com>  wrote:
>>>
>>> On Tue, Dec 28, 2010 at 7:54 PM, Darren Hart<dvhart@linux.intel.com>
>>>  wrote:
>>>>
>>>> On 12/28/2010 04:43 PM, Tian, Kevin wrote:
>>>>>>
>>>>>> From: Darren Hart
>>>>>> Sent: Wednesday, December 29, 2010 8:30 AM
>>>>>>
>>>>>> 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
>>>>>
>>>>> it looks that native gcc/binutils are used here, instead of the cross
>>>>> one.
>>>>> Or else gcc
>>>>> should have a target prefix like i568-poky-linux-gcc, and ld should
>>>>> come
>>>>> from your
>>>>> native sysroot...
>>>>
>>>>
>>>> Yes, I noticed this too. Turns out the Makefile was forcing CC=gcc.
>>>>
>>>>
>>>>>
>>>>>> | 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+0d2522
>>>>>> 24626bd6926324f023a65f20c165232891-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.
>>>>>
>>>>> given earlier confusion, I'm worried whether original trace-cmd does
>>>>> work
>>>>> as expected,
>>>>> e.g. whether it runs on a non-x86 target?
>>>>
>>>>
>>>> I'm confident it does not. I'll be sending a fix for that along with my
>>>> kernelshark recipe.
>>>
>>> Something smells wrong here, must have been an update to trace-cmd,
>>> I ran trace-cmd on all architectures when doing the initial work. So I'm
>>> quite confident that it did :)
>>
>> Hit send too soon. A quick check shows that we were carrying a patch
>> that modified trace-cmd a bit, which might explain how it was working
>> on all archs previously.
>
> Where is this patch? Is it one we need to re-apply or send to Steven?

It was just one that made CROSS_COMPILE work for all major architectures,
but it looks to be somewhat tied to the toolchain (and some toolchain
wrappers).

If you already had plans to address this with the more bare-bones yocto/poky
gcc toolchain, it is probably best to pursue that. If you run into
trouble, I can
track them down. But I did double check, and I've got logs of trace-cmd, being
run on several non-x86 architectures (which is what caught my eye initially, we
can come up with something different here).

Cheers,

Bruce

>
> --
> Darren Hart
> Yocto Linux Kernel
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"