From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fred 1 Date: Thu, 4 Mar 2021 11:27:46 +1100 Subject: make O=directory parameter In-Reply-To: <20210226125817.GI10169@bill-the-cat> References: <20210225153521.GQ10169@bill-the-cat> <2e501810-e4ec-b919-175e-173937af9eee@gmail.com> <20210226125817.GI10169@bill-the-cat> Message-ID: <90847a60-e709-b88b-0788-275edc61fb4b@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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= 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