Re: make O=directory parameter

2021-03-03 Thread 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=  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 holeshould 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= 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() functionand 
works and where/when the other has it removed

or whether that is the actual problem







Re: make O=directory parameter

2021-02-26 Thread Tom Rini
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=  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 holeshould 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= 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.

-- 
Tom


signature.asc
Description: PGP signature


Re: make O=directory parameter

2021-02-26 Thread Fred 1

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=  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 holeshould 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..





Re: make O=directory parameter

2021-02-25 Thread Tom Rini
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=  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 holeshould 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!

-- 
Tom


signature.asc
Description: PGP signature


make O=directory parameter

2021-02-25 Thread Fred 1

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=  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 holeshould I persist?