**** BEGIN LOGGING AT Sat May 17 02:59:59 2014 May 17 17:37:50 I have a makefile based 32bit app that I'm trying to put under a recipe. The issue that I'm having is that the build keeps trying to link it to the X86_64 bit libs (the native sysroot as the host is 64bit). The libs in question is ncurses, any suggestions? May 17 17:47:16 not sure what you mean.. are you building for an x86 machine? May 17 17:47:37 is it trying to build a native package? May 17 17:47:39 no, target system is 32bit. May 17 17:47:58 then it shouldn't matter if the host is 64bit or not May 17 17:48:16 build for the target. The build does compile the objects into 32bit, but then trys to link to 64bit libraries. May 17 17:48:43 ie, if MACHINE is something like qemux86 it should build a 32bit x86 binary May 17 17:49:02 wrong sysroot? May 17 17:49:07 MACHINE is not qemu, it is a real device. May 17 17:49:08 heh May 17 17:49:28 you could try forcing it i suppose May 17 17:50:05 the run.do_configure is pointing to correct sysroot PKG_CONFIG_SYSROOT_DIR="/home/tom/Projects/CPU8/Dora/cpu8/tmp/sysroots/cpu8" May 17 17:50:58 LD="i586-poky-linux-ld --sysroot=/home/tom/Projects/CPU8/Dora/cpu8/tmp/sysro May 17 17:50:58 ots/cpu8 " May 17 17:51:06 so the configure is correct. May 17 17:51:32 that is where the 32bit target libs are. May 17 17:52:27 I dunno, I'll just keep banging away at it. This app is different as it is linking against ncurses. May 17 17:53:10 there should be a -L in there somewhere if it's finding the wrong ones May 17 17:54:03 are you getting the "unsafe for cross compile" error, or is it finding the native sysroot? May 17 17:57:25 no unsafe, it appears to be looking into the native sysroot. I turned on the -v of gcc and am going through that now. I think the thing to do is go into devshell, edit the run.do_compile and get it "corrected". That may give me more info as to what is going on. May 17 17:57:49 I can build this app on the target system (have gcc + the libs there), so I know the makefile does work. May 17 17:58:05 problem is the cross build under bitbake. May 17 17:58:35 I keep coming up with linking errors: undefined reference to `werase' May 17 17:59:56 just when you think that you understand how to use bitbake, it smacks you upside the head... May 17 18:00:32 I've been doing this stuff (oe) for nearly 4 years, it still gets nasty at times. May 17 18:00:45 is the x86 ncurses built correctly? May 17 18:01:00 ie, does the wide lib exist? May 17 18:02:01 and does your make file define/use the SYSROOT and other vars in it? May 17 18:07:01 No, my makefile does not define sysroot, removed competing defines such as "CC=$(CROSS)gcc" from it as well. The makefile is very simple, one source file, one header file, and 14 lines in the make. May 17 18:07:10 including blanks. May 17 18:07:53 I think my best bet is to edit the run.do_compile. May 17 18:08:01 you could try adding a few back... May 17 18:08:24 CROSS=TARGET_PREFIX stuff like that May 17 18:08:48 hmm, yeah, I have another simple app that bitbake builds just fine. But, that one only uses libc to link against. May 17 18:09:33 you can test the makefile by hand with those things defined on the commandline May 17 18:09:49 I'm assuming the ncurses lib is present (I see it under the correct sysroot) and is 32bit as it does get loaded into the target image. May 17 18:10:02 ie, test building cross by hand, without those it should build native May 17 18:11:05 does the recipe use oe_runmake or just make? May 17 18:27:30 BUILD_CFLAGS and BUILD_LDFLAGS are both pointing into the native library areas instead of into the 32bit lib sysroot'ed area. May 17 18:28:15 change that and it builds. So, it appears that bitbake does not know / recognize that the app is NOT a native app, but one that is for the target system. May 17 18:28:49 This is true also for my other application (that does not link against anything else), the same issue is there, wrong sysroot. May 17 18:29:33 the correct compiler and linker are used, but the -L and -I parameters are totally wrong. May 17 18:29:48 again, they point into the native area. May 17 18:34:02 I don't think this is a recipe problem, per se. I think that there must be something in the meta/conf/machine/ file that needs to be there to tell bitbake that the target is a 32bit. apparently, bitbake thinks the target is 64bit. May 17 18:34:06 can you paste the makefile? May 17 18:34:49 TESTBUS=testBus May 17 18:34:49 TESTBUSRC=busTest.c May 17 18:34:49 TESTBUSOBJS=$(subst .c,.o,$(TESTBUSRC)) May 17 18:34:49 all: $(TESTBUS) May 17 18:34:49 $(TESTBUS): $(TESTBUSOBJS) May 17 18:34:50 @$(CC) $(CFLAGS) -v $(TESTBUSOBJS) -o $(TESTBUS) -lncurses May 17 18:34:52 clean: May 17 18:34:54 @rm -f *~ *.P May 17 18:34:58 @rm -f $(TESTBUS) $(TESTBUSOBJS) May 17 18:35:02 i meant psatebin... May 17 18:35:07 ok May 17 18:35:48 http://pastebin.com/rRcKFFu2 May 17 18:36:13 i would avoid setting things like CFLAGS/LDFLAGS and similar May 17 18:36:26 use MY_CFLAGS instead in your makefile May 17 18:37:00 otherwise you're overriding the bitbake env stuff May 17 18:37:13 I can take that out but don't think it makes any difference. I'm not overriding / adding to CFLAGS May 17 18:40:29 that's it. May 17 18:40:43 Why is the mention of CFLAGS doing this? May 17 18:42:39 that is weird. May 17 18:42:45 nerdboy: thank you! May 17 18:43:30 works now? May 17 18:48:39 builds anyway, I'll load up this board with the new image and try it out. It should work, now that I'm past the linker. May 17 18:51:08 This is odd, CFLAGS does not have a mention of a sysroot, while BUILD_CFLAGS does. It seems that using CFLAGS on the compile line is overriding the values in BUILD_CFLAGS May 17 18:51:22 Not sure, will have to drill a bit deeper. May 17 18:51:50 btw, BUILD_CFLAGS does have the correct sysroot in it. May 17 20:19:55 Are Yocto or Poky suitable if all I need is to build tools for cross-development? I don't need to compile a kernel or mount a filesystem, just userspace code. Specifically I'm looking to work on beaglebone May 17 20:22:43 yeah, you can built sdk/adt/other tools May 17 20:23:01 they have bitbake targets too May 17 20:26:40 Okay that is what I thought, I'm working through the documentation here for building the adt, but i'm running into an error. It's just saying that the DISTRO angstrom-v2013.12 is not found. Do I need to build angstrom before it can build the cross development tools? May 17 20:27:29 no May 17 20:27:32 Same error for bitbake adt-installer, and bitbake meta-toolchain May 17 20:27:43 the DISTRO setting seems off May 17 20:28:01 what repos did you clone for core stuff? May 17 20:28:14 poky? oe-core? May 17 20:28:20 I'm using poky May 17 20:28:30 did you use the angstrom setup script? May 17 20:28:59 I sourced the oe-init-build-env script May 17 20:29:01 then it should default to poky-version-blah May 17 20:29:14 in local.conf May 17 20:29:25 did you set angstrom somewhere? May 17 20:29:47 I set machine to beaglebone May 17 20:29:49 grep for that distro string May 17 20:30:22 and the DISTRO variable is set to poky May 17 20:30:53 grep for that angstrom distro string May 17 20:31:00 in local.conf? May 17 20:31:16 what layers are you using besides poky? May 17 20:31:43 I've only been looking into this stuff for a few hours, i'm honestly not sure May 17 20:32:09 just trying to follow the documentation under "Using the ADT installer" May 17 20:33:12 In bblayers.conf is listed poky/meta, poky/meta-yocto, poky/meta-yocto-bsp May 17 20:33:20 well, the first time you source that script, it creates a build tree with a conf dir, you need to edit local.conf and bblayers.conf May 17 20:33:34 you need some other layers May 17 20:33:57 clone meta-ti and look at the layer deps in the readme May 17 20:34:19 probably meta-openembbed and meta-ti would do it May 17 20:37:38 * nerdboy never tried to build anything with just poky before... May 17 20:38:28 Is that not an advisable approach? May 17 20:40:42 I build some apps outside of poky using the compiler + libs from poky. May 17 20:41:04 devshell is not the best solution for software cross-dev. May 17 20:41:33 just sysroot your makefile May 17 20:42:13 What does that mean? May 17 20:43:27 jyan, as an example, look at the gcc doc (e.g. man gcc) and search for --sysroot May 17 20:47:15 jyan: but, if all you need is the binutils, gcc stuff, then a simple path statement would do. May 17 20:47:45 sysroot if you want to link into the libraries created by poky for the target arch (e.g. libc, libncurses, etc.) May 17 20:48:10 Yeah i just read the sysroot option. Don't I still need to build a suitable compiler though? May 17 20:49:16 jyan: yes May 17 20:49:29 jyan: what is your target processor? May 17 20:49:47 I'm just trying to cross-compile for beaglebone, so ARM May 17 20:52:29 clone meta-ti, as it's more uptodate than meta-beaglebaord May 17 20:54:22 Okay, I'm cloning meta-ti and openembedded-core May 17 20:54:36 these are referred to as layers? May 17 20:54:54 The trick that I use to sysroot into poky so i can build outside of poky, is that I take one of the run.do_compile that were built under tmp/work, modify it, then include it into my Makefile. May 17 20:55:24 heh, like onions? May 17 20:56:31 What is the reason to want to build outside of poky? May 17 20:57:14 jyan, every try to develop an app while building INSIDE poky? May 17 20:57:22 clumsy May 17 20:57:55 I almost no development experience in embedded i'm a student May 17 20:58:11 I've done some work with the STM discovery, but I just used their IDE May 17 20:58:40 building outside poky allows me to use a git repo redirectly, rather than wrestling with git-indirection. May 17 21:00:18 that would be the other thing, if you are using eclipse (i don't) it is easier to do. Devshell is okay for resolving recipe issues with something already written, but if you try to write something from scratch, devshell can get in your way really quickly. May 17 21:00:48 I'm trying to avoid using IDEs like eclipse, I learn a lot more doing it like this May 17 21:01:06 For me, just forget to update the repo and go for a full build by eraseing the tmp/ tree. Then your source changes disappear. too dangerous. May 17 21:01:25 I see May 17 21:01:28 jyan: that's fine. I'm a vi + makefile guy. May 17 21:01:47 I'd sooner write a make script than run up an ide. May 17 21:02:29 Yeah May 17 21:03:39 My understanding is that I can build a toolchain, and link it to the right libraries, then work outside of poky in my own git repo? May 17 21:03:58 absolutely. May 17 21:04:06 but its necessary to build the toolchain and get the libraries in poky May 17 21:04:10 correct May 17 21:04:15 alright May 17 21:04:35 Now just trying to figure out how to get it to build May 17 21:05:33 I build on new iron, so I need to build the file system image to load into the target system(s). Then, once I have the basic system booting up, then I can build my specific applications for the device (target system). May 17 21:06:27 I'm trying to avoid having to build the whole fs, the board is already running May 17 21:06:38 I do that via sysroot. Nothing different from what they are doing, at the basic level, in poky. It is the same approach, but, I do not build my value-added apps under the tmp/work tree. May 17 21:06:52 jyan, slow dev box? May 17 21:07:28 I could build it, but I'm trying to tackle one thing at a time haha May 17 21:14:16 just follow the meta-ti readme as if you were building it all May 17 21:14:48 then start with the meta-toolchain build May 17 21:15:19 you should get a build info listing once it parses everything May 17 21:16:13 like this => https://github.com/sarnold/meta-alt-desktop-extras/wiki/Layer-Config May 17 21:16:35 don't overcomplicate it... ;) May 17 21:24:03 Alright I think I have something working, it is parsing recipes... May 17 22:15:34 T0mW: by default, unless you inherit autotools, we have -e in EXTRA_OEMAKE, which says obey vars from the environment in preference to the vars in the file. it means it Just Works more often than not, but it can cause consequences where things you want to retain are lost. you can alter EXTRA_OEMAKE to explicitly pass the variables in, and in the makefile it should ideally distinguish between the options that are required and those which can be May 17 22:15:35 overridden. e.g. -W & the like belong separate from -O2 & the like. you can also use e.g. "override FOO += bar" to forcibly append bar to FOO even if FOO came from the environment and make was run with -e May 17 22:15:48 not sure if thats the issue you were hitting, i only skimmed the scrollback, but it's useful information regardless :) May 17 22:16:36 kergoth: kind of figured that EXTRA_OEMAKE was / has to be involved. May 17 22:17:12 it was a terrible thing in retrospect, we should have forced people to be explicit when passing variables in, so it's more clear exactly what's happening May 17 22:17:13 kergoth: the app builds, cannot look too deeply into this, I have 10 days to get the unit ready for a show in Las Vegas. :( May 17 22:17:16 * kergoth nods May 17 22:18:14 kergoth: good info though, it means that I will look more closely into how run.do_compile behaves. May 17 22:50:17 has anyone ran into "ParseError ... unparsed line" before? May 17 23:25:32 missing quote mark maybe? May 17 23:27:14 Yeah I had actually just fat-fingered something >.> May 17 23:42:27 * nerdboy has skinny fincgers May 17 23:42:33 doesn't help **** ENDING LOGGING AT Sun May 18 02:59:58 2014