**** BEGIN LOGGING AT Fri Jul 29 02:59:56 2011 Jul 29 08:56:48 hu akk Jul 29 08:56:51 er Jul 29 08:56:53 hi all Jul 29 11:16:46 bluelightning, drink some coffee Jul 29 11:17:30 Crofton: yeah :) Jul 29 15:32:06 Good Morning All ! Jul 29 15:58:22 bah, no sgw :) Jul 29 16:09:33 dvhart: gnuplot claims that your commands are crap Jul 29 16:09:35 :-) Jul 29 16:09:58 jefferai, I'm heading into the office - can you send me an email with the output? Jul 29 16:10:04 sure Jul 29 16:10:08 jefferai, did you clean up your .dat file/ Jul 29 16:10:09 ? Jul 29 16:10:16 (remove any error messages, etc) Jul 29 16:10:19 define "clean up"? Jul 29 16:10:22 ^ Jul 29 16:10:26 oh Jul 29 16:10:27 morning Jul 29 16:10:30 no, it doesn't like this line: Jul 29 16:10:30 gnuplot> set term wxt size 640,480 Jul 29 16:10:40 says that wxt is unknown or ambiguous Jul 29 16:10:47 jefferai, /me blames your distro of choice Jul 29 16:10:56 is wxt some kind of wxwidgets thing? Jul 29 16:10:57 not installing the wxt terminal Jul 29 16:11:17 that's the only thing I didn't add in to gnuplot, because, who uses wxwidgets Jul 29 16:11:18 probabably an option component to gnuplot Jul 29 16:11:36 it provides the interactive 3d plot viewer Jul 29 16:11:52 oh Jul 29 16:11:59 that sounds wxwidgety Jul 29 16:12:04 yuck Jul 29 16:12:05 ok Jul 29 16:12:07 I'll build that in Jul 29 16:13:14 cool, looking forward to seeing the results Jul 29 16:18:49 morning all Jul 29 16:20:59 morn Jul 29 16:57:36 sgw: hi Jul 29 16:58:47 Morning khem Jul 29 17:08:56 sgw: Jul 29 17:10:01 khem: here but in a meeting Jul 29 17:10:05 ok Jul 29 17:10:12 my machine is wonky Jul 29 17:10:34 I am currenntly testing some patches for arm brokenness Jul 29 17:10:47 can you throw somethinf together Jul 29 17:10:55 we need these patches Jul 29 17:11:22 I have been testing some of the changes also along with the ppc changes. Jul 29 17:12:02 http://patches.openembedded.org/patch/8863/ http://patches.openembedded.org/patch/8815/ http://patches.openembedded.org/patch/8809/ Jul 29 17:12:11 sgw and one more that I am sending Jul 29 17:12:14 in a moment Jul 29 17:12:30 any specific pointers you want me to look at right away? Jul 29 17:12:40 'er.. I mean patches.. Jul 29 17:12:59 8867 Jul 29 17:13:24 fray: in a meeting. please reveiw the list there is still a meta-toolchain-gmae target (check the autobuilder) Jul 29 17:15:22 http://patches.openembedded.org/patch/8867/ Jul 29 17:15:51 fray: see if they fit into the tune stuff or if you see any further fallouts Jul 29 17:15:57 due to the patches or othereise Jul 29 17:18:10 khem, the only concern I have is that we need to identify the packages build for how they were built.. i.e. if it was arm (no interworking), arm (with interworking) and thumb.. we need three different values for the packages produced.. Jul 29 17:18:35 otherwise we run into the issue that someone changing a setting can produce two packages with exactly the same name, but different contents.. leading to confusion in package feeds and such Jul 29 17:19:00 Anyone mess with SPDX for more than just the license map? e.g. for BOM emission? Jul 29 17:19:09 kergoth: I do Jul 29 17:19:35 manual, or automated from the metadata? Jul 29 17:19:37 fray: interworking is not optional with eabi Jul 29 17:19:38 as for the patches, I'm confused by why there is PREFERRED_ARM_INSTRUCTION_SET and ARM_INSTRUCTION_SET... Jul 29 17:19:58 PREFERRED_ARM_INSTRUCTION_SET is bogus Jul 29 17:20:03 wouldn't it be better to simply have one or the other, then override it as necessary using the _${TUNE} or in the recipe itself? Jul 29 17:20:04 it wont be ther Jul 29 17:20:18 its only ARM_INSTRUCTION_SET which should be needed Jul 29 17:20:36 how so Jul 29 17:20:37 if EABI requires interworking, and we state we don't support OABI.. then we always enable interworking.. and this is no longer an issue right? Jul 29 17:21:08 yes armv4 is a bit special Jul 29 17:21:26 fray: it's there just to override PREFERRED_ARM_INSTRUCTION_SET only while keeping ARM_INSTRUCTION_SET "overrideable" from recipe Jul 29 17:21:31 if EABI says we need the BX.. then armv4 needs to be documented as such -- or am I missing something there.. Jul 29 17:21:35 and if we have interworking then it does not matter if package is thumb or not Jul 29 17:21:44 JaMa, but why do we need to variables? Jul 29 17:21:46 since it should run on eglibc Jul 29 17:22:03 if you do ARM_FOO_tune-armv4t = thumb Jul 29 17:22:15 then ARM_FOO is going to be "thumb" unless overwritten by the recipe manually Jul 29 17:22:28 khem, yes afaik, yes.. Jul 29 17:22:30 fray: using thumb and having it in fratures e.g. using for -march -mtune is different Jul 29 17:22:56 there are two problems.. 1) interworking and 2) thumb enabled or disabled dynamically Jul 29 17:22:57 fray: but then it depends on OVERRIDES order Jul 29 17:23:08 JaMa, correct.. and generally the tune is the last in the overrides order Jul 29 17:23:26 thumb can not be disabled Jul 29 17:23:46 fray: PREFERRED_ARM_INSTRUCTION_SET with overrides makes sure that it sets only default ARM_INSTRUCTION_SET if empty Jul 29 17:23:48 if interworking is proprt Jul 29 17:23:51 Lets backup and take these one at a time.. Jul 29 17:24:07 1) if EABI requires interworking, and oe-core only supports ARM w/ interworking.. Jul 29 17:24:24 then we ensure it's always enabled... so armv4 = arm + interworking.. Jul 29 17:24:28 that reasonable? Jul 29 17:25:28 gah, let me restate.. if EABI requires interworking, and oe-core only support EABI.. then we need to ensure interworking is always enabled.. thus armv4 = arm + interworking.. armv4t = thumb + interworking Jul 29 17:25:34 (and so-on) Jul 29 17:25:40 that resolves the interworking issue right? Jul 29 17:26:00 armv4t can be arm or thumb Jul 29 17:26:29 there are three different settings with similar names.. feature, tune, and pkg architecture.. Jul 29 17:26:42 pkg architecture of "armv4t" is thumb + interworking Jul 29 17:26:50 pkg architecutre of "armv4" is arm + interworking Jul 29 17:26:55 fray current problmwe enalbe thumb code if arch supports it Jul 29 17:26:58 armv4t should NOT be arm + inteworking Jul 29 17:26:59 that is not what we want Jul 29 17:27:13 why? this is confusing me then.. Jul 29 17:27:41 because you can have a 't' core and not use thumb Jul 29 17:28:06 yes.. but pkg architecture defines the instructions and abi of the package.. Jul 29 17:28:27 the instructions used in "armv4t" package include thumb.. or how do you differentiate when you disable thumb and only product arm? Jul 29 17:28:44 -mno-thumb Jul 29 17:28:59 in general default is arm Jul 29 17:29:08 and you say -mthumb to enable it Jul 29 17:29:12 looking at it another way.. I have two developers.. one sets ARM_INSTRUCTION_SET=arm and one sets it to "thumb".. they both create a bash rpm.. if the pkg_architecture is "armv4t" which one is which? Jul 29 17:29:28 again, ignore tune name, and canonical arch.. this is the package arch I'm talking aobut Jul 29 17:29:38 both will be armv4t Jul 29 17:29:51 but there is no differnece Jul 29 17:29:56 but which is thumb and which is arm? how can you tell, without disassebling them? Jul 29 17:30:07 no there are huge differences.. performance and size differences will occur Jul 29 17:30:10 armv4t indicates the arch it will need to run Jul 29 17:30:20 and that can run arm or thumv Jul 29 17:30:31 no, the package arch indicates the ABI and instruction set Jul 29 17:30:32 performance and size differences occur if I use -OS or -O0, but that isn't encoded in the package info either ;) Jul 29 17:30:50 exactly Jul 29 17:30:54 kergoth, but generally when creating a distribution or package feed you don't arbitrarily change the optimization settings Jul 29 17:31:15 but it is a reasonable use case to change the thumb v arm settings on a per-package basis to tune your system for performance vs space Jul 29 17:32:46 I'm looking at the problem from the point of view of someone who has to debug a package not building, functioning or installing.. Jul 29 17:33:04 the first piece of information i get from a customer is "what is the name of the package you are having a problem with" Jul 29 17:33:04 fray ABIs are not different for arm and thumb Jul 29 17:33:25 and intruction set are compatible Jul 29 17:33:25 if the name is "armv4t" then I'm currently going to know they enabled thumb instructions Jul 29 17:33:36 khem the ABI is EABI.. the instruction set is different though Jul 29 17:33:49 thats why package arch encapsulates both instructions set and ABI Jul 29 17:33:59 whatis the use Jul 29 17:34:05 it is a different instruction set.. thumb vs arm Jul 29 17:34:19 you can't just mix and match the instructions in a single function.. etc.. Jul 29 17:34:26 but what is the use when both can execut e on 't' arch Jul 29 17:34:50 building up the system with the functionality that I as a developer want.. size vs performance.. Jul 29 17:35:22 if as a system builder, I decide that I need certain performance for my database app, but everything else doesn't matter.. I'm likely to choose thumb for the system as a whole, and ARM for the database itself Jul 29 17:35:44 thats what ARM_INSTRUCTION_SET will do Jul 29 17:35:49 but when I'm profiling I may find that in certain applications ARM is actually more compact.. so I can build it both ways and compare. then select the appropriate package from the feed for each Jul 29 17:36:03 hmm Jul 29 17:36:08 khem, no that sets the instruction set.. but it doesn't differentiate at all on the back end.. Jul 29 17:36:11 thats what I'm getting at Jul 29 17:36:49 I have to have a way to know (post build system) that this package is thumb or arm.. so I can do my calculations and then build my system based on the size/performance goals that I have as a system designer.. Jul 29 17:36:52 from packaging pov ok Jul 29 17:36:58 I don't see the purpose of having both in one feed, personally. the last thing we need is more multiple provider situations, even in the binary package feed Jul 29 17:37:01 most of the system designers I work with, don't have access to build systems.. Jul 29 17:37:05 but it is not trickling correctly into build system Jul 29 17:37:38 yeah generally feeds are distro based Jul 29 17:37:47 and distros decide intruction set Jul 29 17:37:49 its simple Jul 29 17:38:05 work flow that I've seen is: OS developer.. they use the build system and produce their custom OS (packages).. the device designer then takes these packages and produces an image.. the application developers take the (development) image and produce apps.. cycle back around and repeat.. Jul 29 17:38:25 often the OS developer and device designer are the same people, but not always... Jul 29 17:39:26 fray: I wonder how would you make t and non t feeds for same distro Jul 29 17:39:48 easily.. build say core-image-minimal twice.. once for armv4 and once for armv4t Jul 29 17:39:58 publish the armv4 and armv4t feeds Jul 29 17:40:20 yes thats the only way Jul 29 17:40:27 you can very well have different distro nae Jul 29 17:40:32 I am fully expecting people to be able to use external tooling to pull the feeds together and construct their image Jul 29 17:40:34 like micro and micro-uclibc Jul 29 17:40:43 micro and micro-thumb Jul 29 17:41:02 also with the mutlilib code thats gone/going? in.. there will be a way to build the components multiple times.. Jul 29 17:41:26 anyhow current problem is that armv4t armv5t has confused people Jul 29 17:41:58 that much is obvious Jul 29 17:42:15 then change the name of the tuning to "armv4_thumb" for all I care.. Jul 29 17:42:17 since what it means in tne is not in line with what usually its used for Jul 29 17:42:30 thats why we have three distinct sets of names.. tune, feature and package Jul 29 17:42:44 another problem is that we use -march based on this as well Jul 29 17:42:53 I don't see the problem. Just because the tune/package arch is the same doesn't mean you can't separate the feeds yourself Jul 29 17:43:06 ok, then call the tunings "bob", "john", "mark".. the tune names really don't matter.. Jul 29 17:43:13 it's the "feature" names thats we use to set the -march Jul 29 17:44:52 so I still can use armv4t for arm instruction set Jul 29 17:45:10 it will make sure that compile emits interwoworking code Jul 29 17:45:13 I find that confusing in the opposite direction Jul 29 17:46:06 if it was like what you said then gcc wont have two options one to set the instruction set and another one to set arch Jul 29 17:46:24 since they mean different Jul 29 17:50:29 then rename these all.. Jul 29 17:50:48 I really honestly don't care about the names of the tunes or package archs.. as long as I can differentiate between thumb and non-thumb packages Jul 29 18:07:51 fray: I think it needs a bit of thought Jul 29 18:09:23 khem I replied to oe core based on the discussion we just had.. Jul 29 18:09:42 I think this addresses the issues I'm aware of and preserves the unqiue arch identification based on ABI and ISA Jul 29 18:10:39 fray: ok Jul 29 18:11:11 the other thing to remember is I'm referring to oe-core itself.. if a distro wants to create their own tune files, onw pkg arch definitions, etc.. this should be extensible enough to support that -- easily -- Jul 29 18:12:17 as long as its easily extendible sure Jul 29 18:13:18 khem, BTW its my undstanding that glibc CAN be built with thumb.. (perhaps only thumb2), but it doesn't need to be ARM isa Jul 29 18:13:40 if that is correct, we really need to fix the eglibc integration.. it should save a bunch of space Jul 29 18:13:59 fray yes thumb2 sure but thumb1 no Jul 29 18:14:09 uclibc can be built in all 3 Jul 29 18:14:28 it looked to me like both uclibc and (e)glibc always disabled thumb compilation modes.. Jul 29 18:14:36 eglibc itself may not be thumb but supports running thumb binaries equally well Jul 29 18:14:37 maybe I read it wrong.. but if they do, we want to fix that Jul 29 18:14:46 fray: no uclibc did not Jul 29 18:14:58 it checked ARM_INSTRUCTION_SET Jul 29 18:15:16 but defaults are always arm Jul 29 18:16:19 gmp is another that can build in thumb.. the issue is there is arm assembly in it.. patch out the arm assembly if thumb is enabled and it works fine Jul 29 18:16:54 yes fact is that not all packages are written to keep thumb in mind Jul 29 18:17:00 so we have to mix and match Jul 29 18:17:06 they all can be fixed of course Jul 29 18:17:25 fray: I have an issue where the perl do_install (the installperl script) thinks the perl binary isn't executable when it is. Re-running do_install doesn't affect the behavior, but going into the devshell and running the do_install run script works every time. Any thoughts? Jul 29 18:17:27 mix-match is fine.. but again the original expectation is you'd simply switch the tuning Jul 29 18:17:38 hmmm Jul 29 18:17:48 is it exiting prematurely or? Jul 29 18:30:04 perl script does a -x to check for execute bit, and fails, yet the binary is 0755 Jul 29 18:30:07 afaict anyway Jul 29 20:56:26 fray: ping Jul 29 20:58:51 I've reproduce -a- failure... but it's different from the autobuilder.. (different symptoms at least) Jul 29 20:59:38 fray: Ok, BTW, I am seeing the problem with TUNE_ARCH missing from PACKAGE_ARCHS on powerpc Jul 29 21:00:01 yes.. I am seeing the same thing.. Jul 29 21:00:26 I'm investigating that now.. along with the reported package name of "powerpcppc603e" Jul 29 21:00:29 which is wrong.. ;) Jul 29 21:05:05 well, here's galak, he can shed more light on that :) Jul 29 21:05:16 on what? Jul 29 21:05:18 also, sgw, did you fix live-image.bb yet? Or whatever one that was Jul 29 21:05:23 galak: powerpcppc603e Jul 29 21:05:35 what about it? Jul 29 21:06:24 Well, you figured out the cause and a workaround/fix yes? point fray at the ML posts and save him time perhaps :) Jul 29 21:06:42 ok Jul 29 21:06:46 I saw galak's patch(es).. they're close but not quite right.. Jul 29 21:06:58 fray: what's not right about them? Jul 29 21:07:41 the one that combines powerpc and powerpc64.. (thats how I originally had them) but RP broke them up on purpose.. Jul 29 21:07:50 the tunings that support both ppc and ppc64 should require both of them Jul 29 21:08:23 fray: why, ia32 is merged into one file? Jul 29 21:08:34 because it hadn't been torn apart yet.. Jul 29 21:08:44 that is in the TBD category.. as is mips, if it hasn't already been Jul 29 21:09:01 fray: ok, not sure I see the reason to split it Jul 29 21:09:11 mips is going to be split into a mips and mips64 arch.. the mips64 arch will contain the n32 and n64 ABis Jul 29 21:09:30 galak, again.. thats how I originally did it.. but RP has final say.. convince him to keep them combined.. Jul 29 21:10:08 the rationale to tear them apart is so that anything 32-bit doesn't even see or use the 64-bit tune features -- so there is no chance or errant chunks coming in Jul 29 21:10:50 fray: fair enough, so for a multilib tune would we include both arch-powerpc.inc & arch-powerpc64.inc? Jul 29 21:10:58 yes Jul 29 21:11:07 Tartarus: sorry what live-image.bb issue? Jul 29 21:12:50 sgw: the grub and x8664 one Jul 29 21:13:34 Tartarus: that's what I thought. Jul 29 21:13:44 fray: so are you familiar with the multlib change to the gcc-configure-common.inc Jul 29 21:14:02 I might be which one specifically Jul 29 21:14:26 the sed line to tweak GLIBC_DYNAMIC_LINKER Jul 29 21:15:43 Tartarus: There are bigger issues with that one also, grub2 could fix that, but I am not sure that we to pull that in right now. Jul 29 21:15:48 galak, BTW the patch that makes no ppc64 soft-float.. I've been told one is in development.. but I have no idea if it'll ever be released Jul 29 21:16:04 galak, I don't know much about the GLIBC_DYNAMIC_LINKER.. sorry Jul 29 21:16:05 sgw: I'd like to get world unbroken asap Jul 29 21:16:09 And enhanced next Jul 29 21:16:15 as soon as RP is back, at least :) Jul 29 21:16:27 I thought someone else was working on fixing the glibc_dynamic_linker issues.. Jul 29 21:16:57 the problem (as I see it) is that we don't have static lib directory configurations cause everyone wants to be different.. if we could lock them down as /lib and /lib64.. it'd either just work, or be easy to fix.. Jul 29 21:16:57 fray: its fine, I see from the commit message what the intent was Jul 29 21:17:09 so code is required to make this dynamic (as much as possible) Jul 29 21:17:15 Tartarus: agreed. Jul 29 21:17:31 I will something by Monday for RP Jul 29 21:17:41 fray: didn't see that the other day. The sed line doesn't work on ppc so need to parse the regex and try to understand it better Jul 29 21:18:18 fray: all of this is towards hoping to try a ppc multilib setup Jul 29 21:21:01 sgw: good enough, thanks Jul 29 21:35:41 * Tartarus curses a tiny bit at CC_FOR_BUILD Jul 29 21:59:14 sgw.. still building.. can't believe I built w/o all of the fixes you accumulated Jul 29 22:23:44 arg Jul 29 22:23:55 pseudo needs beating for when 'gcc' isn't enough and you need 'gcc -m64' or 'gcc -m32' Jul 29 22:26:27 OK, the 32bit vs 64bit thing, I don't get Jul 29 22:26:33 fray: I will bug you more, later Jul 29 22:26:54 it comes down to: Jul 29 22:27:07 one a 32-bit chip you include only arch-powerpc.. so m64 isn't even a valid option Jul 29 22:27:26 on 64-bit chip you includ eboth arch-powerpc and arch-powerpc64... so both m32 and m64 are options Jul 29 22:45:09 sgw: around ? Jul 29 22:45:22 just got back on line, sorry was travelling today. Jul 29 22:45:36 Tartarus: fray I wonder how do we handle site files in multilib Jul 29 22:45:56 sgw: can you give oe-core a whirl for qemuarm Jul 29 22:46:26 sure it will take me a few minutes to set it up Jul 29 22:46:36 sgw sure Jul 29 22:46:37 thx Jul 29 22:46:53 just want to know if its building ok now Jul 29 22:51:47 khem, scratch build or sstate ok? Jul 29 22:52:39 scratch is better Jul 29 22:52:47 ok Jul 29 22:53:07 minimal-image should be enough Jul 29 22:58:24 sgw ok FINALLY reproduced it Jul 29 22:58:37 fray awesome Jul 29 23:08:16 sgw.. this failure looks like it has nothing to do with the multilib changes.. Jul 29 23:10:17 now I have: Jul 29 23:10:18 | Unable to find package task-sdk-host-nativesdk (task-sdk-host-nativesdk)! Jul 29 23:23:02 fray: after I took out some of those changes we talked about this morning, the PPC build failed with no TARGET_ARCH, is that something you saw? Jul 29 23:25:08 I didn't see that.. but I reworked some of the ppc tune files.. Jul 29 23:25:38 Ah, maybe I need to get those changes to test Jul 29 23:26:00 my changes don't seem like they're quite right though.. Jul 29 23:26:39 Ok, I guess when you stabilize them. Jul 29 23:39:47 fray: I mean building pseudo-native and the --bits=32 games Jul 29 23:39:51 Don't get, seems kinda wrong Jul 29 23:40:10 [ 64 == 64 -a -e /usr/include/gnu/stubs-32.h -a pseudo-native == pseudo-native -a 0 != 1 ], so build with --bits=32, hunh? Jul 29 23:40:40 build a 32bit libpseudo and loose the rest? Jul 29 23:41:15 it's simpler then that Jul 29 23:41:23 let me load the recipe and walk you through it Jul 29 23:41:29 k Jul 29 23:41:41 fwiw, what I'm fiddling with now is BUILD_CC = "gcc -m64" Jul 29 23:42:37 do_configure is a noop.. so the first op is do_compile.. Jul 29 23:43:04 do_compile will configure for whatever the native bitsize is of the machine.. either lib64 or lib.. and then runs make Jul 29 23:43:30 --but-- do_compile_prepend will run (before that of course) and configure and compile for the alternative system.. Jul 29 23:43:54 the end result is at the end of do_compile you'll have a "lib" "lib64" "bin" directory set.. the bin directory will be overwritten and the default (do_compile) arch.. Jul 29 23:44:03 the lib/lib64 will exist based on the default and the alternative if enabled Jul 29 23:44:05 So why do that alternative system? Jul 29 23:44:08 that make a little more sense? Jul 29 23:44:12 Is that for SDKMACHINE or whatever? Jul 29 23:44:31 If you have a host system with both 32-bit and 64-bit binaries... and you only build for one or the other... Jul 29 23:44:40 then you can't preload libpseudo when runnign the "other" Jul 29 23:44:44 so you must have both copies Jul 29 23:44:52 ok Jul 29 23:45:04 the library is the only thing thats bitsize dependent.. the binary will run equally as well 64-bit or 32-bit Jul 29 23:45:23 So when I must force BUILD_CC to be gcc -m64, I also must have NO32LIBS Jul 29 23:45:49 (Why? Because otherwise gcc defaults to -m32) Jul 29 23:45:51 if you have to force gcc -m64.. then your host is broken.. ;) Jul 29 23:46:10 if gcc is defaulting to -m32, then I strongly suspect your system has both 32-bit and 64-bit.. so you'll need the NO32LIBS=0 Jul 29 23:46:10 No comment ;) Jul 29 23:46:39 the configure in pseudo will set -m32 if --bits=32 Jul 29 23:46:47 I think it does -m64 if the reverse.. but not sure.. let me check Jul 29 23:47:22 So, what needs to be run under pseudo, is gcc? Jul 29 23:47:27 & company Jul 29 23:47:56 potentially -anything- in the system has to be able to run under pseudo Jul 29 23:48:08 that includes compiler, assembler, linker, coreutils, util-linux, etc.. Jul 29 23:48:12 anything that can run in do_install Jul 29 23:48:17 Hmm Jul 29 23:48:25 So, I guess I'll see what shits the bed in a world -k Jul 29 23:48:33 Before I cry over pseudo and this toolchain some more Jul 29 23:49:39 ya.. pseudo automatically adds -m32 or -m64 Jul 29 23:49:52 so even if your gcc is -m32 or -m64.. it's SUPPOSED to work that the last setting takes hold.. Jul 29 23:50:11 Well, then there's a bug later on int he Makefiles Jul 29 23:50:11 so if your gcc can't do gcc -m32 -m64 (and result in an m64 binary) then something is likely wrong with the way it's compiled Jul 29 23:50:16 CCLD or just 'ld' isn't enforcing Jul 29 23:50:31 * Tartarus blew away the failure log, but it was a mix'n'match link failure Jul 29 23:50:33 AFAIK, it's linking using gcc Jul 29 23:50:49 THen it's not forcing -m32/-m64 in CCLD Jul 29 23:50:56 And BUILD_CC_ARCH = "-m64" kills it Jul 29 23:51:13 the only part that is linked in the alternative is the library, which shouldn't be externally linked to anything Jul 29 23:51:20 Right Jul 29 23:51:26 Lemme pastebin some local.conf bits for you Jul 29 23:51:31 'k Jul 29 23:51:33 this shows up as a failure real quick Jul 29 23:51:50 TRUEBUILDARCH = "${@os.uname()[4]}" Jul 29 23:51:50 BUILD_CC_ARCH = "${@base_contains('TRUEBUILDARCH', 'x86_64', '-m64', '', d)}" Jul 29 23:51:55 too short to bother pastebin'ing Jul 29 23:54:01 khem, I built the wrong target, I am resetart, but I also have to head out, back on line later. Jul 29 23:55:06 do you have the hostarch set right? Jul 29 23:56:43 * fray tries to find the damned seeting Jul 29 23:56:54 hm? Jul 29 23:57:09 yes, this is all set right, normally Jul 29 23:57:19 it's just I have a special compiler sometimes Jul 29 23:58:26 "it's special already" Jul 29 23:58:43 the option isn't in the local.conf anymore.. got removed when oe-core came in.. still looking Jul 30 00:00:47 I wonder if it's "SDKMACHINE" Jul 30 00:01:02 the issue is that it tries to detect the machine type of your host.. Jul 30 00:01:14 if it detects x86_64.. then it expects to build -m64 by default with gcc Jul 30 00:04:58 yeah Jul 30 00:05:06 But that's not true here Jul 30 00:07:54 your configuration sounds like it's far from standard.. but the alternative compilation/link of pseudo should work.. if it doesn't then let me see.. and while I suspect it's configuration, I can likely tell you whats wrong Jul 30 00:11:30 Well, did you toss what I gave you into local.conf and try to build psuedo-native? Jul 30 00:11:38 I think it's showing a bug in the Makefile, based on what you said Jul 30 00:11:44 even normal gcc should show it Jul 30 00:12:18 cause I have to fix the sdk building for sgw Jul 30 00:17:47 ha Jul 30 00:17:48 ok Jul 30 00:28:05 sgw: fixed the sdk issue(s) Jul 30 00:28:12 pulling together a patch set.. **** ENDING LOGGING AT Sat Jul 30 02:59:56 2011