**** BEGIN LOGGING AT Sun Sep 09 02:59:58 2012 Sep 09 09:09:20 morning all Sep 09 14:58:06 Is there a way to drop into a debugging environment with oe to inspect environment variables? Sep 09 15:00:08 spacecolonyone: bitbake -c devshell Sep 09 15:00:40 spacecolonyone: although bitbake -e might be more appropriate depending on what you want to query Sep 09 15:02:39 task-native-sdk is failing on gcc_4.5 and the logs indicate autoconf is trying to use the host's cc Sep 09 15:03:30 I'm on a stock (in the sense I got it from Koen's angstrom setup scripts) oe configuration Sep 09 15:04:33 so I'm not sure what is going on, but I figure there might be an environment variable that is pointing to /usr/lib/cmplrs/cc2.11 instead of trying to pul it in from within the OE tree Sep 09 15:05:02 that said, I searched the OE tree for cc2.11 & 3.11 and came up empty Sep 09 19:30:13 How does one get OE to build both an arm-angstrom-linux-gnueabi AND an arm-none-eabi cross compiler? Newlib support is greatly desired for a bootloader recipe that I'm working on, but I can't figure out how to get it done with just arm-angstrom-linux-gnueabi (using all the -nostdinc, etc. flags). Sep 09 19:32:21 You'd have to make a special recipe for the arm-none-eabi compiler, possibly just setting TARGET_SYS and then "require"ing the regular one. Sep 09 19:33:27 pb_: Thanks, that's what I was thinking was required but hoped an existing mechanism was in place. Appreciate the help/clarification! Sep 09 19:35:42 No, there's no automatic mechanism for that: the standard infrastructure in OE only understands one "target" at any given time. In some future utopia it would be nice to rework the compiler bits along the lines of BBCLASSEXTEND, so you could just declare a dependency on "arm-none-eabi-gcc" and it would sort everything out automatically. Sep 09 19:36:35 (and the existing standard dependency on "gcc-cross" would just become ${TARGET_SYS}-gcc, at which point gcc could stop having the wrong architecture declared on it as well and everything would be much neater.) Sep 09 19:38:09 pb_: So if I created a gcc-baremetal recipe (native?) that produced the arm-none-eabi compiler with newlib support, then add DEPENDS += "gcc-baremetal" in my bootloader recipe file, I should be able to use arm-none-eabi from the bootloader recipe? Sep 09 19:41:05 yeah, exactly Sep 09 19:41:36 there might be a tiny bit of extra fiddling around required to get arm-none-eabi-gcc into your $PATH at the right point, but in principle that's about all you need. Sep 09 19:46:30 pb_: Yeah, I'm familiar with the oddities of sysroot finagling, though not an expert by any means. I'll use gcc-cross as a base for gcc-baremetal, I guess. Sep 09 19:46:36 pb_: Thanks again! Very helpful, appreciate it! Sep 09 20:26:51 wow, adding LIC_FILES_CHKSUM to all these perl modules is tedious Sep 09 20:26:59 * pb_ stabs perl and all its friends **** ENDING LOGGING AT Mon Sep 10 02:59:58 2012