[poky] Library paths for Makefile based recipes

[Bruce Ashfield]

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 :)

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 at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>



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