Re: [LTP] RANLIB not set?

[Kumar G. <ga...@ke...>]

On Aug 10, 2009, at 10:40 AM, Garrett Cooper wrote:

> On Mon, Aug 10, 2009 at 1:20 AM, Subrata
> Modak<su...@li...> wrote:
>> On Fri, 2009-08-07 at 08:14 -0500, Kumar Gala wrote:
>>> On Aug 6, 2009, at 12:17 PM, Garrett Cooper wrote:
>>>
>>>> On Thu, Aug 6, 2009 at 9:18 AM, Kumar
>>>> Gala<ga...@ke...> wrote:
>>>>> I'm seeing this on fedora 11 on ppc64:
>>>>>
>>>>> make[3]: Leaving directory `/root/ltp/testcases/network/ipv6'
>>>>> make[3]: Entering directory `/root/ltp/testcases/network/lib6'
>>>>> cc -Wall  -I../../../include -g -D_GNU_SOURCE   -c -o runcc.o  
>>>>> runcc.c
>>>>> ar cr runcc.a runcc.o
>>>>> runcc.a
>>>>> make[3]: runcc.a: Command not found
>>>>> make[3]: *** [runcc.a] Error 127
>>>>> make[3]: Leaving directory `/root/ltp/testcases/network/lib6'
>>>>> make[2]: *** [all] Error 2
>>>>> make[2]: Leaving directory `/root/ltp/testcases/network'
>>>>> make[1]: *** [all] Error 2
>>>>> make[1]: Leaving directory `/root/ltp/testcases'
>>>>> make: *** [all] Error 2
>>>>>
>>>>> - k
>>>>
>>>>    Make sure to export CROSS_COMPILER=1 at the top-level make, or
>>>> define RANLIB=$(CROSS_COMPILE)ranlib, where $(CROSS_COMPILE) is the
>>>> prefix for your compiler set, e.g. $(CROSS_COMPILE)gcc.
>>>>    One of the many things that will be fixed in a more kosher  
>>>> manner
>>>> in the next couple months.
>>>> Thanks,
>>>> -Garrett
>>>
>>> I see you committed a change to the lib6/Makefile for ranlib.  I
>>> believe we need a similar patch to the toplevel Makefile since it
>>> exports RANLIB:
>>>
>>
>> True. But, can you create a patch from LTPROOT, as, the below fails  
>> to
>> apply:
>>
>> patching file Makefile
>> Hunk #1 FAILED at 9.
>> 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
>>
>> Regards--
>> Subrata
>>
>>> diff --git a/Makefile b/Makefile
>>> index 953eddf..9f8056a 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -9,6 +9,8 @@ AR=$(CROSS_COMPILER)ar
>>>   RANLIB=$(CROSS_COMPILER)ranlib
>>>   endif
>>>
>>> +RANLIB         ?= ranlib
>>> +
>
> Hi Kumar,
>    The suggestion you made (noble as it may have been) is completely
> useless as you're not exporting the variable in the Makefile (and thus
> the value goes out of scope when you drop into the lower level
> Makefiles). Please see this link for more details:
> http://www.gnu.org/software/make/manual/make.html#Variables_002fRecursion

But we are exporting it..

ifdef CROSS_COMPILE
CROSS_COMPILER = $(CROSS_COMPILE)
endif
ifdef CROSS_COMPILER
CC=$(CROSS_COMPILER)gcc
AR=$(CROSS_COMPILER)ar
RANLIB=$(CROSS_COMPILER)ranlib
endif

...

export CFLAGS += -Wall $(CROSS_CFLAGS)
export CC AR RANLIB CPPFLAGS LDFLAGS HAS_NUMA

>    All in all, please be patient... give me another 2 weeks and I'll
> have a better solution (the new Makefile infrastructure) back in HEAD.
> I just did the quick fix because it was gating any building off of

Just reporting what I'm seeing and trying to help.  I'll look forward  
to trying out the new Makefile infrastructure.

- k