[poky] Library paths for Makefile based recipes

[Bruce Ashfield]

On Thu, Dec 30, 2010 at 5:31 PM, Darren Hart <dvhart at 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 at gmail.com>  wrote:
>>>
>>> On Tue, Dec 28, 2010 at 7:54 PM, Darren Hart<dvhart at 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"