[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