**** BEGIN LOGGING AT Thu May 17 03:00:02 2018 May 17 06:20:44 Crofton|work: sadly I dont think I'll be able to make it May 17 09:42:47 Hi. Could somebody help me with "luajit"? I am trying to bitbake rocko branch but ended up with compile error. Those I got fixed with some HOST_LDFLAGS mods. However, I am now stuck with do_install. It is complaining about missing pkgconfig folder in work area. Any idea? (pkgconfig/luajit.pc does exist under image folder) May 17 15:37:18 muppe: you need to install 32bit gcc on host May 17 15:37:37 whats your host distro ? May 17 20:51:36 armpit, I notive only now you're building with glibc May 17 20:51:53 let me retry then May 17 21:08:08 k May 17 21:21:50 with musl (and klibc version) I've seen this May 17 21:21:57 arm-oe-linux-musleabi-ar: `u' modifier ignored since `D' is the default (see `U') May 17 21:22:31 only these sources May 17 21:30:55 that should be a warning May 17 22:05:25 Is it a sane idea to add bitbake and the bsp meta layer to my checkout of openembedded-core? I can see that https://www.openembedded.org/wiki/OE-Core_Standalone_Setup simply checks out bitbake directly into the oe-core directory and also, bitbake is in the .gitignore file of oe-core. Yet, I would like to be able to go back in the git history and restore the exact state used back then. May 17 22:06:05 i'd really suggest using some form of multiple repository management tool to handle lthat May 17 22:06:05 (Idea above: Adding bitbake and the bsp meta layer as git submodule) May 17 22:06:14 git submodules, repo, git-subtree, etc May 17 22:06:24 yea, missed that May 17 22:06:26 which one is best completely depends on your situation and workflow May 17 22:06:38 thx May 17 22:06:50 and I am right to not starting off with poky, correct? May 17 22:07:05 Better starting with oe-core and adding my stuff as I go? May 17 22:07:35 armpit, khem, ok, reproduced with glibc May 17 22:08:09 poky is a demo/example/testing distro, with accompanying already done merged repository, not bad to examine for inspiration, but yeah it's probably best to work with the components directly May 17 22:08:18 thx May 17 22:09:25 khem, should I ad a guard __KLIBC__ around this? May 17 22:09:27 #ifdef HAVE_EXECINFO_H May 17 22:09:27 #include May 17 22:09:27 #endif May 17 22:10:20 strange is, all is fine with musl May 17 22:19:41 we should check if there is execinfo.h during configure May 17 22:19:49 it works with musl because musl does not have this file May 17 22:19:55 I am reading it, is under /usr/include May 17 22:20:02 and checking for execinfo.h... (cached) yes May 17 22:20:09 right May 17 22:20:10 (this is glibc now) May 17 22:20:17 glibc systems have it May 17 22:20:27 with musl its a separate recipe May 17 22:20:51 ok, I had expected issues with musl but not with glibc ;) May 17 22:24:12 well May 17 22:34:06 I am fixing it with #ifndef __KLIBC__ May 17 22:35:13 but the again, glibc ac checks says there is HAVE_GETLINE but then undefined reference to `getline' May 17 22:35:41 adding another one guaqrd in libmissing.h. ugly May 17 22:48:59 getline ? rename it to _getline May 17 22:56:47 khem, hmm, this is different, a patch added a simple getline implementation for klibc May 17 22:57:49 getline should come from stdlib.h May 17 22:57:58 +#ifndef HAVE_GETLINE May 17 22:57:58 +ssize_t getline(char **lineptr, size_t *n, FILE *stream); May 17 23:01:15 no getline in klibc's stdlib.h May 17 23:02:30 if implementation is added then it should add a signature to stdlib.h as well May 17 23:03:23 hheh, the patch comes from upstream, not yet in master May 17 23:07:20 I'll llok tomorrow at this May 17 23:08:14 khem, I am more concerned about kexec-tools and mcmodel=large May 17 23:14:55 ok **** ENDING LOGGING AT Fri May 18 03:00:03 2018