**** BEGIN LOGGING AT Wed Apr 15 02:59:58 2015 Apr 15 04:19:34 is there a way to detect machine type (x86 vs x86-64) inside a recipe? Apr 15 04:23:58 redengin: There is a MACHINE_FEATURE for "x86" i believe Apr 15 04:25:15 yeah, but its there for x86_64 as well, I need to know which library to copy the 32bit or 64bit Apr 15 04:25:57 oh, in that case you could just check the TARGET_ARCH value for "x86-64" Apr 15 04:26:35 ah thanks Apr 15 06:30:44 why does yocto freak out when I try to add to ${libdir} but not if I add to ${libdir}/libpath/ Apr 15 06:32:42 redengin: you mean when changing libdir =? Apr 15 06:33:50 no, I have a recipe, if I install the lib to ${libdir} rootfs task says the lib isn't provided, but if I install it to ${libdir}/something/ all is fine Apr 15 06:34:49 redengin: did you update the FILES variable to reflect the install locations? Apr 15 06:35:25 nrossi, yes, but it only works with ${libdir}/something/libfoo.* Apr 15 06:36:39 perhaps I need somthing like FILES_libfoo ? Apr 15 06:37:12 yer you will need that if you have a recipe that generates multiple packages Apr 15 06:37:18 aka if you add to "PACKAGES" Apr 15 06:37:33 you will need "FILES_foo" set to consume the lib Apr 15 06:37:51 nrossi, packages will be the next step, I just want to get the shared lib installed for now Apr 15 06:38:33 currently I have FILES_${PV} = "${libdir}/libfoo.*" and rootfs freaks out Apr 15 06:38:42 FILES_${PN} you mean? Apr 15 06:39:32 it should also problably be a += instead of just an = Apr 15 06:39:46 otherwise you trash the defaults for FILES_${PN} Apr 15 06:41:14 doh, you're right I typo'ed PV into the recipe too! grrr Apr 15 06:51:32 ok, so it still has the same problem :( Apr 15 06:52:08 so the error you get is the "installed-vs-shipped" QA error? Apr 15 06:52:46 nrossi, no, rpm works fine, its the rootfs that fails to find libfoo1 and doesn't include the package foo Apr 15 06:56:57 ok so your recipe is it called "libfoo1"? Apr 15 06:58:29 the recipe is hadoop.bb and it create FILES_${PN} = "${libdir}/libhadoop.*" Apr 15 06:59:05 ok, and so your IMAGE_INSTALL/CORE_IMAGE... does it add "hadoop" or "libhadoop"? Apr 15 06:59:44 the local.conf adds hadoop to IMAGE_INSTALL_append Apr 15 07:00:05 ok, does the recipe have a "RDEPENDS_${PN}"? Apr 15 07:00:16 or just a RDEPENDS? Apr 15 07:00:39 it has an RDEPENDS_${PN} Apr 15 07:00:50 whats it value? Apr 15 07:01:44 RDEPENDS_${PN} = "java2-runtime" Apr 15 07:02:28 hmm ok, odd. do you have the exact error the rootfs step gives? Apr 15 07:03:52 ERROR: libhadoop1 not found in the base feeds (... NO HADOOP package in here ) Apr 15 07:05:00 perhaps some other rpm takes over ${libdir} and additions don't get included by rootfs? Apr 15 07:06:07 could you run bitbake -e > temp, and then open temp and get the value of "PACKAGE_INSTALL" Apr 15 07:06:24 just want to make sure something is not trying to install "libhadoop1" Apr 15 07:06:43 and that it is just coming from a dependency chain Apr 15 07:17:03 export PACKAGE_INSTALL="packagegroup-core-boot run-postinsts kernel-modules linux-firmware-rtl8168e rsync grub mdadm e2fsprogs ethtool oracle-jse-jre hadoop spark run-postinsts packagegroup-core-ssh-dropbear" Apr 15 07:17:55 ok that looks good. How big is the hadoop recipe you have? Apr 15 07:18:47 tiny, let me pastebin it Apr 15 07:18:58 good morning Apr 15 07:19:06 morning mckoan Apr 15 07:20:20 recipe: http://pastebin.com/psxjfNiW Apr 15 07:23:52 redengin: hmmm i think i might know what is causing it. It might just be easier to setup the package for libhadoop though Apr 15 07:24:25 nrossi, what do you think is going on? Apr 15 07:25:19 the package handling code in oe automatically detects shared dependencies, and will add them to the packages dependencies automatically Apr 15 07:25:34 (shared libraries on an elf itself) Apr 15 07:26:31 ah, so if I don't include hadoop in IMAGE_INSTALL it'll get picked up "automagically"? Apr 15 07:27:36 i think it might be the hadoop package that is getting the dependency added on Apr 15 07:27:53 i assume there are like test programs or example programs that are built as part of the hadoop build? Apr 15 07:28:13 not that I've declared on FILES_${PN} Apr 15 07:28:27 yep, but they might be in just /usr/bin/ Apr 15 07:28:47 nrossi, even if I don't do_install them? Apr 15 07:28:57 have a bit of a look in the working directory. tmp/work//hadoop/.../image/ Apr 15 07:29:22 redengin: not sure, have a check to be sure Apr 15 07:29:46 only file tmp/work/core2-64-poky-linux/hadoop/1.2.1-r0/image/usr/lib/libhadoop.so Apr 15 07:30:38 ok, lets see if we can track it down. give me a minute to grab your recipe and setup a build Apr 15 07:35:03 redengin: what layers are you using to get java? Apr 15 07:35:37 I made my own, but I'm pretty sure the lib itself has no java dependency Apr 15 07:35:59 if you want the java recipe I can provide it Apr 15 07:36:31 np, i will just remove the dep on java2-runtime Apr 15 07:38:16 ok i have it building now, should be done in 10 minutes (i dont develop for x86 so it has to build the toolchain ;)) Apr 15 07:39:59 wow, you can get a toolchain out in 10 mins? what are you running on? Apr 15 07:40:40 Dell PowerEdge R620 :), 20 core (+HT) and 128GB Ram Apr 15 07:40:55 nice Apr 15 07:41:29 managed to snag it for myself when the IT wars begun Apr 15 07:41:43 actually bitbake does complain about an oracle dependency even though I see no dependencies in nm of libhadoop.so Apr 15 07:42:04 does bitbake look at all the package files even if they aren't installed? Apr 15 07:42:39 not if they dont get put into the package itself Apr 15 07:46:12 * rink_ idly wonders what 'WARNING: QA Issue: ELF binary '...' has relocations in .text' means Apr 15 07:47:18 rink_: looks like there was a discussion on oe-core about it -> http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/33590 Apr 15 07:47:56 oh thanks Apr 15 07:51:38 * rink_ looks somehow jealous towards nrossi... the best I could do is get an i7 to build on .... Apr 15 07:52:32 nrossi, I apologize, I finally used nm and found the dependencies Apr 15 07:53:56 looks like it needs libhdfs.so as well. is there anyway bitbake would tell me that? it seems pretty error prone to have to use nm to find dependencies Apr 15 07:54:41 redengin: not sure, there might be a insane.bbclass rule for it. Apr 15 07:56:00 seems like rootfs log should tell me it didn't have a dependency Apr 15 08:02:56 morning all Apr 15 08:05:23 hi bluelightning Apr 15 08:07:55 morning (from here in the later afternoon:) Apr 15 08:08:14 I am getting certain errors on my yocto build. Can you help me with it? Apr 15 08:08:14 hi mckoan, imrehg Apr 15 08:08:37 mime: sure, what's the error? (use pastebin if its more than 2 or 3 lines) Apr 15 08:11:04 http://pastebin.com/g5UYGZxw Apr 15 08:11:41 My build is on an Ubuntu 14.10 system 64bit for a cyclone5 board Apr 15 08:15:37 hmm, that's a bit ugly... Apr 15 08:16:01 it's that looks like it's specific to the linaro toolchain recipes Apr 15 08:16:07 any linaro folks on? Apr 15 08:23:59 mime, where is the linaro 2.24 source? Apr 15 08:33:36 huuuuum: Apr 15 08:33:39 "Once the merger is complete, our plan is to keep the NXP Semiconductors name and operate as one company under the NXP brand." Apr 15 08:41:19 abelloni: aw i was hoping they would name as "FreeNXPScale" Apr 15 08:43:19 <_4urele_> nrossi, with free samples? Apr 15 08:43:32 _4urele_: of course! Apr 15 08:58:31 hi redengin the linaro source is there in meta-linaro/meta-linaro-toolchain folder Apr 15 08:59:35 mime, I finally found it, I agree with the compiler error :) Apr 15 09:00:08 can you elaborate please redengin Apr 15 09:00:24 I don't understand why the TRUE is in the macro Apr 15 09:01:35 yes that is something I noticed too, but I am not sure how to correct it Apr 15 09:02:26 patching the macro is simple, but without knowing why it was there to begin with makes that dangerous Apr 15 09:02:36 Shall I just remove the ', TRUE' Apr 15 09:02:44 yeah Apr 15 09:03:07 okay let me try Apr 15 09:03:33 but it looks like that code got refactored and used the macro without knowing what it did Apr 15 09:05:03 on a sidenote what is the best place to get the linaro layer? Apr 15 09:06:27 you could also just just remove -Wno-error=unused-value Apr 15 09:06:48 mime, I don't know I don't use linaro Apr 15 09:11:14 http://comments.gmane.org/gmane.linux.linaro.toolchain/4343 Apr 15 09:13:16 seems like it'd be better defined by an inline function than a macro Apr 15 09:16:25 Hi, I'm trying to build enlightnment. During the build of efl_1.11.4 I get following error. Apr 15 09:16:34 eglvivante.h:244:2: error: #error "Platform not recognized" Apr 15 09:17:31 I have seen in an old yocot irc log that someone had the same error about a year ago, but couldn't find what the solution was. Apr 15 09:19:17 DatGizmo, looks like it needs headers that define Status Apr 15 09:20:00 DatGizmo, err nevermind Apr 15 09:21:28 #if defined(_WIN32) || defined(__VC32__) && !defined(__CYGWIN__) && !defined(__SCITECH_SNAP__) Apr 15 09:22:22 I had a look at the header file, and I think that this define should be triggerd: 220 #elif defined(LINUX) || defined(__APPLE__) Apr 15 09:22:42 Becaus I also see a -DLINUX in the compiler call. Apr 15 09:28:53 hello guys Apr 15 09:29:34 I am trying to compile an example that uses libusb... i'm using arm ds-5 on windows Apr 15 09:30:03 although I added libusb source files to inlcude Apr 15 09:30:20 and added a flag -lusb-1.0 Apr 15 09:30:52 but compiler gives error that -lusb-1.0 couldn't be found Apr 15 09:31:22 any thoughts pleasee? Apr 15 09:31:43 DatGizmo can you link to the recipe? Apr 15 09:32:42 siraj, compile where? do you need the -dev to provide headers? Apr 15 09:33:19 compiling on windows machine and targeting linux yocto Apr 15 09:33:37 how can I tell if I need -dev? Apr 15 09:34:03 siraj: i actually fail to understand the question, and how it is yocto related. which example are you trying to compile? where did you get it? are you using a proper yocto generated toolchain including sysroot, or something else coming from your IDE? Apr 15 09:34:41 I'm using DS-5 GCC Apr 15 09:34:50 * ARM DS-5 GCC Apr 15 09:35:29 then you have to make sure this gcc can see the libraries you are trying to use, e.g. that they are installed into its sysroot Apr 15 09:35:48 no idea how DS-5 wants that to be done, i think you should check its documentation. Apr 15 09:36:02 redengin: meta-openembedded/meta-efl/recipes-efl/efl/efl_1.11.4.bb Apr 15 09:36:31 Good... a question please... Apr 15 09:37:02 libraries means "source code" or compiled source code? Apr 15 09:37:22 compiled, properly installed. Apr 15 09:37:47 if ds-5 is worth using, it should have proper documentation on how to use libraries. Apr 15 09:37:49 siraj, if you are trying to compile on your target it will need headers and libraries Apr 15 09:38:08 so I should compile libusb and install it in ds-5 sysroot? Apr 15 09:38:13 redengin: here on openembedded git: http://git.openembedded.org/meta-openembedded/tree/meta-efl/recipes-efl/efl/efl_1.11.4.bb?h=dizzy Apr 15 09:38:28 siraj: no, you should read up on how ds-5 intends to use libraries. Apr 15 09:38:39 we don't know about the magic it uses/includes. Apr 15 09:38:40 redengin: no, I am trying to compile on windows host Apr 15 09:39:14 siraj, can you postbin your recipe? Apr 15 09:39:37 what recipe? Apr 15 09:40:28 siraj, the recipe that is compiling your "thing" that requires libusb Apr 15 09:40:39 siraj: this is actually not a yocto problem, but a "how-to-use-ds-5 problem" Apr 15 09:40:49 mmm... I see then Apr 15 09:41:08 redengin: he doesn't have a recipe, probably just some source code blob and an ide that he doesn't know what its doing beneath the hood Apr 15 09:41:13 I don't use recipe to compile... Apr 15 09:41:18 does anyone know if yocto dizzy 1.7 supports Cyclone5 platform? I found the latest yocto builds on git Apr 15 09:41:55 mime: are you using cyclone V ? Apr 15 09:42:03 siraj, then I'm with LetoThe2nd we can't help you Apr 15 09:42:03 yes Apr 15 09:42:29 redengin: it's OK... maybe I still don't know how to use DS-5 Apr 15 09:42:52 mime: good... I'm using it too Apr 15 09:43:20 mime: do you use DS-5 to compile? Apr 15 09:43:45 redengin I have a noob question. So the link that you have given has the solution to exactly my issue. Apr 15 09:43:56 Basically macros with comas may not work with my compiler Apr 15 09:44:12 so they have given some inline functions as a replacement correct? Apr 15 09:44:48 no what is DS-5? Apr 15 09:45:53 mime, the choice to make it an inline function is for code correctness, the fact that its a bad macro still exists Apr 15 09:47:04 yes agreed. So all I do is go to the appropriate file marked with a * and remove the lines with a '-' sign before them and add the ones with a '+' or nothing in front of them Apr 15 09:47:25 DatGizmo, I'm guessing you need a DEPENDS on a -dev somewhere Apr 15 09:48:11 mime, what output are you talking about that has * and -? Apr 15 09:48:28 https://sourceware.org/ml/binutils/2014-01/msg00334.html Apr 15 09:48:34 Im talking abou this message Apr 15 09:48:59 ah, thats a patch file Apr 15 09:49:43 mime, do you know how to edit a yocto recipe to apply a patch? Apr 15 09:49:48 oh so there should be an easy way to just ad that to my build right? aaaahhh such a steep learning curve for me Apr 15 09:50:28 Im afraid I don't let me google that and see how to do that Apr 15 09:50:44 mime, don't google it Apr 15 09:51:20 :O hmm Apr 15 09:52:08 redengin: any ideas what -dev ? Apr 15 09:52:21 I don't know anything about DS-5 and the help you get here will probably break DS-5 Apr 15 09:53:02 DatGizmo, unfortunately no, but you could grep on headers in work that define LINUX Apr 15 09:53:13 redengin then how should I add that patch any pointers? Apr 15 09:53:32 redengin: oki, I will have a look. Thanks so far. :) Apr 15 09:54:11 mime, the patch would clean up the linaro source, but if DS-5 manages that source your going to be stuck in a losing battle Apr 15 09:55:57 mime, if you don't mind me asking what does DS-5 do for you? Apr 15 09:57:08 Im not working on DS-5 Apr 15 09:57:10 we're working on yocto Apr 15 09:58:10 I think just applying that patch should solve the issues that Im facing. all I am not sure is how to apply that patch Apr 15 09:59:14 well you can add the patch to the recipe and it'll do its thing, but I fear DS-5 will resync and destroy your edits to the recipe Apr 15 09:59:47 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-patching-code Apr 15 09:59:59 I havent edited the recipe Apr 15 10:00:36 you'll need to edit the recipe to apply the patch Apr 15 10:00:53 okay.. Apr 15 10:01:21 do you know which recipe to change? Apr 15 10:01:46 Im afraid not :s Apr 15 10:02:28 do you have a link to the DS-5 yocto source? Apr 15 10:03:17 so Im getting my yocto sources from Yocto 1.6 Daisy git clone -b daisy git://git.yoctoproject.org/poky.git pushd poky git clone -b angstrom-v2014.06-yocto1.6 git://git.rocketboards.org/meta-altera.git git clone -b daisy git://git.linaro.org/openembedded/meta-linaro.git Apr 15 10:04:47 did my reply make sense to you? Apr 15 10:05:21 mime, yes, but I'm getting tired, can you repost your error again Apr 15 10:05:39 http://pastebin.com/g5UYGZxw Apr 15 10:06:42 oh Im sorry if Im being a pain. Ive been working on it for 3 days now and have not made any progress and you've been very helpful Apr 15 10:10:36 you need to find binutils-native_*.bb Apr 15 10:12:00 the source layout is atrocious, now cloning to run find Apr 15 10:12:51 that seems familiar let me see if I can find that file Apr 15 10:13:58 meta-linaro/meta-linaro-toolchain/recipes-devtools/binutils/binutils_linaro-2.25.bb Apr 15 10:14:23 yes! Apr 15 10:14:29 got it Apr 15 10:14:57 and you have the link to the yocto doc on how to add a patch to recipe so you should be good Apr 15 10:15:27 and since they patch themselves you should be good (why on earth would you need to self-patch) Apr 15 10:15:45 hmm seems complicated. let me try it Apr 15 10:17:29 meta-linaro/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25.inc applies the internal patch Apr 15 10:19:00 so I just copy the message to the .inc file? Apr 15 10:19:37 or a separate .patch / .diff file Apr 15 10:20:15 you need to create a new .patch with the data from that message and then add that file to the SRC_URI Apr 15 10:20:44 brilliant understood it. let me try it! Apr 15 10:22:09 bah, this linaro script is bullshit..... I'll help you for 10 minutes then I'm going to bed Apr 15 10:22:26 ok Ill be quick! Apr 15 10:23:03 shall I place the file in the same folder as the .bb file? Apr 15 10:23:08 *.inc file Apr 15 10:23:13 you're going to have to update the chksums now as well Apr 15 10:23:43 bloody hell Apr 15 10:23:48 sorry for the profanity Apr 15 10:24:50 have you run the bitbake with the patch yet? Apr 15 10:25:08 not yet Apr 15 10:25:17 hurry.... Apr 15 10:25:20 where do I place the patch file? Apr 15 10:25:30 Ive put it in the same folder as .inc file Apr 15 10:26:28 ideally you'd put it in its own directory, but who cares under linaro's BS, just put it in the same directory Apr 15 10:26:45 I need to update it in the bblayer.conf I think Apr 15 10:27:05 nope Apr 15 10:27:31 just put the patch into meta-linaro/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25.inc Apr 15 10:27:46 err. into meta-linaro/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/ Apr 15 10:28:59 yes its running now Apr 15 10:29:02 lets see if the error pops up Apr 15 10:30:00 stay awake stay awakw red!!! :) Apr 15 10:30:59 I'll stay awake for a job offer in seattle or a transfer of money at this point Apr 15 10:31:09 the same error again :( Apr 15 10:31:16 haha where do you work? Apr 15 10:31:23 did you add the patch file to the SRC_URI Apr 15 10:31:41 I work in seattle Apr 15 10:31:50 yes I did Apr 15 10:32:06 it even gave me warnings that the checksums dont match Apr 15 10:32:23 yes, I told you the chksums wouldn't match Apr 15 10:32:52 but its a warning thats it Apr 15 10:32:53 copy/paste the new chksums into the meta-linaro/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25.inc Apr 15 10:33:54 ok 5 more minutes..... Apr 15 10:35:05 yaay Apr 15 10:35:09 you're the best Apr 15 10:36:06 mime, so its all working now? Apr 15 10:38:21 well I just added all the md5 checksum Apr 15 10:38:26 as well as one more schecksum Apr 15 10:38:27 its running now Apr 15 10:39:12 *biting nails* Apr 15 10:42:39 going forward you probably want to create a new layer that will just supply your changes so that you don't corrupt the linaro version Apr 15 10:42:57 I'll be back tomorrow night if you want to learn how Apr 15 10:43:06 yes please! thanks a lot! Apr 15 10:43:09 goodnight Apr 15 10:43:26 atleast let me know if it compiles! :) Apr 15 10:43:55 btw, are you a coder? Apr 15 10:44:43 I will. well I just got started into linux 3 days ago Apr 15 10:45:09 I have about a year experience doing microcontrollers but absolutely none with linux Apr 15 10:45:16 well that linaro source smells rotten, so you may want to find other alternatives Apr 15 10:45:40 well apparently these guys dont want me to use anything else I dont know why but for the academic feel of it I will try alternatives Apr 15 10:47:34 how long does this compile take? Apr 15 10:48:13 or, would it have failed by now in previous runs? Apr 15 10:48:39 ls Apr 15 10:48:51 AndersD, I'm here Apr 15 10:50:05 mime, you're killing me... I'm going to bed Apr 15 10:50:27 waaaiiit! Apr 15 10:51:04 you're past runs were much quicker, it'd have failed by now Apr 15 10:51:53 what task is it on? Apr 15 10:52:15 same error :( Apr 15 10:52:57 I'll be back tomorrow during the day, pm me Apr 15 10:53:03 okay sure Apr 15 10:53:16 and if you can get me an ssh into your build env Apr 15 10:54:14 Im behind a protected firewall. Its difficult for me to get permissions for ssh setup Apr 15 10:54:34 lol, then I'll show you tomorrow how to build a tunnel :) Apr 15 10:54:56 or just work with pastebin Apr 15 10:56:05 okay! Apr 15 10:56:10 goodnight Apr 15 10:56:22 have a good one, you have all the info you need, looks like you didn't configure it right, make sure the patch has a .diff or .patch extension Apr 15 10:57:36 sure will do thanks Apr 15 12:02:24 Hey all Apr 15 12:03:22 In my project I have to build an additional bootloader stub with a different toolchain that I'd quite like to bring under Yocto as well - is that going to be a bit of a faff or is there a good example of this somewhere? Apr 15 12:05:25 Or is it a bit outside the scope of what I should be doing in Yocto! :-) (I've also got a small micro on the board it would also be nice to automate the build of in the same way) Apr 15 12:23:07 pev, technical this should be possible, but might be tricky Apr 15 12:23:28 people have done some interesting things, like build their fpgas with recipes Apr 15 12:24:04 Thats along the same kind of lines... Basically have orig distribution, some patches and a binary toolchain tarball Apr 15 12:24:23 So would just like to automate it as it's also a critical component in the build... Apr 15 12:24:37 Crofton|work: Are you aware of any examples I can dissect? Apr 15 12:24:49 sure Apr 15 12:25:13 not really, basically you need something that uses two toolchains Apr 15 12:25:41 I'm not a toolchain guy Apr 15 12:25:57 * Crofton|work is hoping RP or kergoth know something Apr 15 12:27:43 this might be of interest: http://openembedded.org/wiki/Adding_a_secondary_toolchain Apr 15 12:27:54 pev: ^ Apr 15 12:28:16 nice Apr 15 12:28:28 it was written a while ago, I assume it's still applicable Apr 15 12:28:44 if not you can ping fray ;) Apr 15 12:28:50 pev: I'd suggest looking at multilib, you can have two toolchains coexisting with that Apr 15 12:29:06 two different arches is tricky at the moment though Apr 15 12:31:35 Hello Apr 15 12:31:43 _4urele_: tu es là ? (encore moi :D ) Apr 15 12:34:37 bluelightning: hi, is it acceptable at times to extend CFLAGS in the recipe? Apr 15 12:34:52 e.g. in case of some software, I would like to add the "-shared" flag to avoid static linkage. Apr 15 12:35:11 bluelightning: Oooh. That's a marvellous link, thanks! Apr 15 12:35:58 RP: Hm, define arch :-) Both ARM but ones 926 based, the other A8 IIRC Apr 15 12:36:16 lpapp: certainly, we do that all the time Apr 15 12:36:17 pev: both arm is fine Apr 15 12:36:41 bluelightning: hmm, the only issue is that the software does not seem to respect what comes from Yocto as it does a CFLAGS = ... Apr 15 12:36:52 RP: Cool, I might be in with a chance then! Apr 15 12:36:58 without override, so in that case, I probably need to patch the buildsystem of theirs? Apr 15 12:37:17 lpapp: shouldn't that be overridden by our default use of make's -e option? Apr 15 12:37:29 or is this not using make? Apr 15 12:38:26 it is the Linux makefiles, yes. Apr 15 12:38:37 but some third-party gpib driver as it could not make it into the kernel. Apr 15 12:38:39 they do use Makefiles, yes. Apr 15 12:38:51 make -e will pass it, but without override, what will happen Apr 15 12:41:54 because I think the basic problem is that I would like prepend Apr 15 12:41:57 I would not like to lose either Apr 15 12:44:39 if -e is specified, the value in the makefile will be overridden automatically by the value from the environment, i.e. the value set by OE Apr 15 12:44:47 that is how make is supposed to behave Apr 15 12:44:57 unless they use override Apr 15 12:45:10 what do you mean by "use override"? Apr 15 12:45:13 override CFLAGS += Apr 15 12:45:22 how would they be doing that? Apr 15 12:45:28 just like that Apr 15 12:45:37 that is what I also do in my software to respect Yocto's settings and add mine. Apr 15 12:45:59 https://www.gnu.org/software/make/manual/html_node/Override-Directive.html Apr 15 12:46:02 To append more text to a variable defined on the command line, use: Apr 15 12:46:02 override variable += more text Apr 15 12:46:14 ok, well I don't believe we have any mechanism to work around that Apr 15 12:46:24 why would you? Apr 15 12:46:33 it is a legit case as far as I can tell. Apr 15 12:46:35 it sounded like you were asking for one... Apr 15 12:46:53 ah, right, well, no. Apr 15 12:47:02 the buildsystem uses CFLAGS = and CFLAGS += Apr 15 12:47:22 I wanted to avoid touching their buildsystem Apr 15 12:47:28 but I guess I cannot do that, then. Apr 15 12:48:07 I would assume not, but I am by no means a make expert Apr 15 12:48:41 that is a good thing imho :) Apr 15 12:48:47 thank you. Apr 15 12:54:22 How do I get the Yocto KERNEL Headers on my Yocto ? Apr 15 12:54:28 I need it to build PCI Drivers Apr 15 13:08:00 cart_man: sdk images should have them. http://www.yoctoproject.org/docs/1.7.1/kernel-dev/kernel-dev.html probably answers your question, regardless of how you want to build the driver. See 2.5 for out-of-tree modules if that was the problem Apr 15 13:11:10 jku, Thanks allot Apr 15 13:12:54 is there any way I can copy those headers from the one machine to the one I am working on? Will that work? Apr 15 13:13:06 To ReInstall Yocto to this machine is a bit of a pain Apr 15 13:14:06 jku, ^^ Apr 15 13:33:20 in yocto we have /sbin/fsck -> /bin/busybox.nosuid, how can I get fsck.ext3 ? Apr 15 13:35:19 bluelightning: can you please run a command for me? Apr 15 13:36:54 bluelightning: https://paste.kde.org/pwmdd6sig Apr 15 13:36:57 with and without shared Apr 15 13:37:10 seems that the shared pthread library is broken in Yocto based on this. Apr 15 13:40:00 but I wonder if you can reproduce it with this simple test case. Apr 15 13:43:15 (or anyone else, too) Apr 15 14:01:52 mckoan: install e2fsprogs-fsck Apr 15 14:18:17 JaMa: thx Apr 15 14:24:32 JaMa: do you mean recipe e2fsprogs_1.42.9.bb ? Apr 15 14:25:14 what is the best way of patching a patch in Yocto again? Apr 15 14:25:29 bitbake -c patch and then recreating and copying it back to its files/ directory? Apr 15 14:26:20 generally, yeah. you can use quilt to make it easy, just pop to the appropriate patch if it's not on top, make your changes, quilt refresh Apr 15 14:27:42 yep, we used quilt at Nokia for maemo/meego back then :) Apr 15 14:27:56 kergoth: thanks, btw, do you have any idea for the static pthread linkage? Apr 15 14:28:13 why is that not giving me the pthread_atfork symbol like the dynamic library? Both are generated by meta, I would assume Apr 15 14:28:42 I provided the reproduction case above, but I am still not convinced whether it is a bug or pebkac. Apr 15 14:30:42 sadly not, don't have all that much experience with pthread Apr 15 14:30:49 that said, from a bit of googling, http://ryanarn.blogspot.com/2011/07/curious-case-of-pthreadatfork-on.html may be the info you need Apr 15 14:31:28 looks like it shouldn't bein the actual .so, but in the _nonshared, and the libpthread.so linker script should pull both in, so it should work when dynamic linking, but via that mechanism Apr 15 14:31:47 but *shrug*, not an expert on this, never seen this before Apr 15 14:32:10 ah. "So when -lpthread is added before foo.o on the linker invocation, libpthread_nonshared.a is linked and pthread_atfork is purged as unneeded before foo.o is processed. So to solve this we need to make sure that the reference to pthread_atfork by foo.o is registered before libpthread_nonshared.a is linked. " Apr 15 14:33:16 obviously assuming that blog post is accurate, but it's certainly worth looking into Apr 15 14:33:30 I agree, thank you very much :) Apr 15 14:33:41 np Apr 15 14:38:59 FYI, I would recommend devtool be used for patch updating from 1.8/fido and later Apr 15 14:39:11 well, unless you really like quilt I guess Apr 15 14:39:13 unfortunately, it is daisy Apr 15 14:39:53 mckoan: e2fsprogs-e2fsck is name of package created by e2fsprogs recipe Apr 15 14:41:19 lpapp: right, it was more for others' benefit (and perhaps your future self ;) Apr 15 14:41:55 we will update to fido in one year time if all goes well. Apr 15 14:42:22 lagging about one year behind to wait for stable releases, i.e. not .0 Apr 15 14:43:27 fair enough Apr 15 14:43:49 kergoth: The default quilt doesn't refresh the link target in yocto though does it? I had to write a patch to fix that here... Apr 15 14:49:43 JaMa: perfect! thx Apr 15 15:03:47 pev, that is intentional.. as it's the developer who needs to decide their change is correct and to move the patch out to the recipe --- as well as do the other necessary things for their CM practices.. put it in a layer, submit a patch to OE, etc etc etc.. a lot of people automate pieces of this work.. but I don't believe there is a general right answer for everyone at this point Apr 15 15:04:47 kergoth: unfortunately, changing the order did not help me. Apr 15 15:06:21 fray: Really? The way it's set up (certainly in 1.6 I'm using) is that a quilt refresh *should* refresh the patch in the recipe, it's only because theres a bug (feature?) in quilt where it doesn't follow symlinks properly this doesn't happen. I'd agree that of course it needs to be reviewed etc but that's all down to your vc management surely? Apr 15 15:07:07 If I'm a consumer of OE but not a contributor.. and I patch something.. I shouldn't be modifying oe-core.. I should be modifying my own layer Apr 15 15:07:18 which requires adding a .bbappend, SRC_URI to my new patch, etc, etc, etc.. Apr 15 15:07:36 That's a different issue :-) Apr 15 15:07:39 in the past we've had people ask that we "fix" the issue.. and it's been turned down for that reason Apr 15 15:07:58 I'm talking about an existing patch in a layer that you're refreshing via quilt which should follow the symlink Apr 15 15:08:15 i.e. patch editing as it were not creation Apr 15 15:08:27 thats the issue where does it write new patches to.. and even if you edit them.. you may not want it to go where it's putting it.. Apr 15 15:08:46 I'm talking about existing not new patches Apr 15 15:08:48 I agree, it's inconvienent.. but it's been intentionally 'ignored' as a problem because there was a clear solution Apr 15 15:09:03 So when you do_fetch the build dir has the patch symlinked back to the recipe Apr 15 15:09:13 I regularly have to modify existing patches, that end up getting copies in my project layers.. I don't want to modify upstream layers when I do that.. Apr 15 15:10:20 Sure but you'd need to explicitly push your changes for that. On balance losing all your changes because of a bitbake -c clean is worse as that's outside the scope of vc Apr 15 15:12:46 I don't disagree.. Apr 15 15:12:59 propose a solution and workflow, it might be good enough to be adopted.. Apr 15 15:13:19 (mailing list, likely oe-core is the right place to discuss that.) Apr 15 15:13:40 (openembedded-core@lists.openembedded.org) Apr 15 15:19:07 kergoth: seems hidden is different to undefined symbol. Apr 15 15:19:11 or something along those lines. Apr 15 15:28:27 is there any option to set to enable checkroot.sh at boot ? Apr 15 15:38:53 the script fails due to fsck: fsck.auto: No such file or directory Apr 15 15:49:32 fray: TBH I was just going to submit the patch that makes quilt respect symlinks and let that start a discussion, but have been busy recently! Apr 15 16:05:35 looks like checkroot.sh is unusable Apr 15 16:28:47 Hello! How can I create a directory in "do_install", e.g. /home/myFolder/Foo. "install /home/myFolder/Foo" fails (getting root_fs errors) Apr 15 16:29:09 do_install installs to ${D} Apr 15 16:29:19 install -d ${D}/foo Apr 15 16:29:40 that said, packaging files destined for a home directory is almost always the wrong approach, unless it's a short term hack Apr 15 16:33:17 why is it wrong? Apr 15 16:33:23 lpapp: did you check your libpthread.so and libpthread_nonshared.a using nm —defined-only to see if either have pthread_atfork? that'd be my next step, figure out if your libs actually have what you need Apr 15 16:33:52 yes, that was the first thing that I did. Apr 15 16:34:18 ah. well, i'm just about out of ideas then :) Apr 15 16:35:36 I do not understand, why are home folders under yocto are located unter /usr/share/myUser?? Apr 15 16:35:46 when using the useradd-script? Apr 15 16:35:57 kergoth: https://paste.kde.org/pscbbmimb Apr 15 16:36:11 isnt it supposed to be "/home/myUser" Apr 15 16:38:19 kergoth: I appreciate the ideas. Do you have any other? Apr 15 16:39:26 looks like it's right where it's supposed to be, so that's good to know, just need to figure out why your linker can't find it.. i guess make sure the libpthread.so linker script looks correct, beyond that look a the link line? Apr 15 16:39:35 not sure as to the next step beyond that Apr 15 16:40:10 the linker script is also generated by Yocto and that looks ok to me. Apr 15 16:42:58 fwiw, the libgpib library uses pthread_atfork and not the application Apr 15 16:43:14 so I added -lgpib before -lpthread just in case. I also tried adding -pthread. Apr 15 16:53:35 please, could someone help me why the useradd-script installs the home folders to "/usr/share/"? why not at /home/ ?? Apr 15 16:53:43 what is the reason for that Apr 15 16:56:58 lpapp: was libgpib linked with pthread itself? Apr 15 16:58:06 yeah, I am just browsing the logs in temp :) Apr 15 16:58:48 perhaps it is easier to run ldd through libgpib than browsing the log? Apr 15 16:59:02 although if it is statically linked against libpthread_nonshared.a.... Apr 15 17:06:46 hi, I'm compiling a recipe that installs headers in ${D}${includedir} they are well installed in the image but they are not in the build/tmp/sysroots/*/ directory, so I can't use those headers from other recipes. Can someone tell me how I could install the headers in the sysroot? Apr 15 17:10:17 kergoth: seems that the answer is "nope", ./log.do_compile.12467:693:arm-foo-linux-gnueabi-gcc -mno-thumb-interwork -marm -shared -Wl,--version-script=./gpib_version_script -Wl,-soname -Wl,libgpib.so.0 -o libgpib.so.0.1.7 ibCac.o ibClr.o ibCmd.o ibEos.o ibEot.o ibFind.o ibLines.o ibOnl.o ibPad.o ibRd.o ibRpp.o ibRsp.o ibRsv.o ibSad.o ibSic.o ibSre.o ibTmo.o ibTrg.o ibWait.o ibWrt.o ibGts.o ibBoard.o ibutil.o Apr 15 17:10:23 globals.o ibask.o ibppc.o ibLoc.o ibDma.o ibdev.o ibbna.o async.o ibconfig.o ibFindLstn.o ibEvent.o local_lockout.o self_test.o pass_control.o ibstop.o ibConfLex.o ibConfYacc.o -lc Apr 15 17:11:32 perhaps that should be linked against -lpthread then rather than the app? Apr 15 17:12:15 kido: if your recipe installs headers into ${D}${includedir} and other recipes have your recipe in DEPENDS then that should be enough Apr 15 17:13:42 kido: you can double-check the process by looking at the image/ and sysroot-destdir/ directories in the work directory for your recipe Apr 15 17:15:53 oh thank you I didn't think about DEPENDS, what if the recipe that provides the headers provides a virtual package ? Apr 15 17:18:49 kergoth: I thought the following linkage order oughta still work, -o foo -lgpib -pthread -lpthread -> is that wrong in this case? Apr 15 17:20:11 kido: what do you mean by a virtual package? Apr 15 17:23:07 well the first package is called "full-X" it provides virtual/X-headers and the second package named Y depends on X-headers Apr 15 17:24:08 so by package in this context you mean recipe? i.e. we're talking about DEPENDS here right, not RDEPENDS? Apr 15 17:25:21 yes Y DEPENDS on virtual/X-headers Apr 15 17:25:44 not RDEPENDS Apr 15 17:25:57 shouldn't be an issue, as long as the recipe that actually installs the headers has virtual/X-headers in its PROVIDES Apr 15 17:26:19 and sorry I meant recipe, I'm still not used to the yocto's vocabulary Apr 15 17:26:56 yes full-X PROVIDES virtual/X-headers Apr 15 19:35:12 * kergoth notices that anibal changed his license priority implementation in a way that loses a bit of functionality, and also he wasn't credited for it in any way Apr 15 22:16:52 where do the *.wks files for wic live in the tree? Apr 15 22:20:26 ahhh. http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/image/canned-wks **** BEGIN LOGGING AT Thu Apr 16 00:33:47 2015 **** ENDING LOGGING AT Thu Apr 16 02:59:59 2015