[oe] [PATCH] madwifi-ng_r3837: Fix for LDFLAGS / GNU_HASH QA

Leon Woestenberg leon.woestenberg at gmail.com
Mon Apr 27 16:54:50 UTC 2009


Hello Tom,

thanks for your review, and conditional ack, let me try to make it
unconditional:

On Mon, Apr 27, 2009 at 3:50 AM, Tom Rini <trini at embeddedalley.com> wrote:
> On Sun, Apr 26, 2009 at 04:35:04PM -0700, leon.woestenberg at gmail.com wrote:
>
>> Submit LDFLAGS variable to make.
>> Remove the cleaning of LDFLAGS in the binary Makefiles.
>> Unset LDFLAGS for the kernel modules compile.
>>
>> Compile tested on powerpc (mpc8313e-rdb).
>
> It's not explicit in the patch, but I assume that what happens now is
> that LDFLAGS is used for userland utils (good) and the kernel already
> makes sure this won't leak in as it doesn't pay attention to LDFLAGS at
> all.  Right?  Or some similar explanation?  If so:
>
> Acked-by: Tom Rini <trini at embeddedalley.com>
>

Yes, that's what I did. Let me explain the diff in English:

First we had the recipe clearing the LDFLAGS altogether, I reverted that:

do_compile() {
-       unset LDFLAGS
       oe_runmake all
 }

I then made sure the LDFLAGS are indeed cleared for the kernel case
(i.e. this is old behaviour):

+-      $(MAKE) -C $(KERNELPATH) SUBDIRS=$(shell pwd) modules
++      $(MAKE) -C $(KERNELPATH) LDFLAGS= SUBDIRS=$(shell pwd) modules

I then made sure the user tools do get the LDFLAGS in the Makefiles:

+-LDFLAGS =
++#LDFLAGS =

Then rebuild recipe for powerpc. Looked good. Don't have Wifi h/w to
test madwifi at this point.


Regards,
-- 
Leon




More information about the Openembedded-devel mailing list