make O=directory parameter

[Fred 1]

On 26/2/21 11:58 pm, Tom Rini wrote:
> On Fri, Feb 26, 2021 at 10:27:46PM +1100, Fred 1 wrote:
>> On 26/2/21 2:35 am, Tom Rini wrote:
>>> On Thu, Feb 25, 2021 at 12:50:47PM +1100, Fred 1 wrote:
>>>
>>>> like in the linux kernel build
>>>>
>>>> make O=builds/arm
>>>>
>>>> builds the result to the specified output directory
>>>>
>>>>
>>>> is this supposed to work for uboot also ?
>>>>
>>>> doesn't seem to work for me, i've fetched older tar files and same problem
>>>>
>>>> maybe my environment?
>>>>
>>>>       fedora32
>>>>
>>>>       5.10.13-100.fc32.x86_64
>>>>
>>>>       GNU Make 4.2.1
>>>>
>>>> the O=<dir>  does mostly work on older uboot like from ~2010 though....
>>>>
>>>>
>>>> thought i'd ask as debugging the make process is,well umm...horrible,
>>>>
>>>> (i've inserted some extra debug print codes in gnu make (it self no code to
>>>> be praised about!
>>>>
>>>> esp when so much open source depends on it!!)
>>>>
>>>> so atm, a bit of a rabbit hole........should I persist?
>>> Can you provide a sample failure?  The last "make O=... fails" I saw was
>>> because they were passing ARCH= which isn't valid for U-Boot and
>>> specifically breaks if you're say building for an aarch64 platform as in
>>> the linux kernel you would do ARCH=arm64 but it's all "arm" here.
>>> Thanks!
>>>
>> so ok, i'v dropped using the ARCH=
>> still
>>
>> All the configs i tried failed:
>>
>> make O=builds/rpi2  rpi_2_defconfig
>> make O=builds/rpi2 mrproper   <==tried this too
>>
>> make O=builds/rpi2 -w -d V=1 CROSS_COMPILE=arm-none-eabi-
>> qemu_mips_defconfig
>> orangepi_zero_defconfig
>>
>> qemu_arm_defconfig
>>
>>
>> Of course the builds all work just fine without O=, and results in the main
>> directory.
>>
>> So this is not just a problem on my machine?, i guess everyone just uses it
>> like so ?
>>
>> anyway i am sufficiently annoyed with it, i'll have a go at finding out
>> why......
> I don't know what's going on with your local environment.  For me, I
> just now did:
> make O=builds/rpi2 -w -d V=1 CROSS_COMPILE=<my path to it> rpi_2_defconfig all
> and it completed.  Perhaps you have something set in your environment?
> It's hard to say without seeing your error message.
>
Thanks your reply, so that lead me to create a new user and try it. It 
worked!
so ok i'm floored about that.
doing a diff with output of $set

the user where it worked has additional shell functions

make ()
{
.....
}
make_target_extract_script ()
{
}
and missing

LD_LIBRARY_PATH
pyenv ()
{
}
_pyenv_virtualenv_hook ()
{
}
I had tried previously with $unset LD_LIBRARY_PATH
and didn't help
I don't know the origin or  why one shell has the make() function....and 
works and where/when the other has it removed
or whether that is the actual problem