**** BEGIN LOGGING AT Mon Dec 30 02:59:57 2019 Dec 30 08:53:55 Hello. Dec 30 13:27:09 anybody have experience on situation where autotools based recipe seemingly succeeds without any problems but the actual files are not in the baked image? Dec 30 19:45:06 Hmm.... glibc dlopen()'s libgcc_s in some cases, but it's not in RDEPENDS so it won't necessarily get pulled into the rootfs... Dec 30 19:53:12 thats one but there are more whack-a-moles Dec 30 19:53:38 e.g. if app use system() API to open random binaries Dec 30 19:54:03 we only detect shlibs that too only direct deps Dec 30 19:54:10 that's where explicit rdepends aditions come in, we can only do so much Dec 30 19:54:20 * khem nods Dec 30 20:09:12 Sure, I'm more interested in where the correct place to add the RDEPENDS is. My first instict would be to add it to the glibc package Dec 30 20:09:30 RDEPENDS_${PN} += "libgcc" Dec 30 20:10:02 This of course, rebuilds *everything* so I'm a little leery :) Dec 30 20:22:24 that is not really correct representation, glibc does not need it Dec 30 20:22:53 but you might want to override the pthreads unwind behaviour Dec 30 20:22:58 in app Dec 30 20:23:03 The app is python Dec 30 20:23:03 then it should ask for it Dec 30 21:39:30 I'm getting an error on the linux-libc-headers package build, "Failed to spawn fakeroot worker to run ...: Broken Pipe" Dec 30 21:40:26 Looking into that a bit, I find that if I try to manually run pseudo, out of tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo, it fails Dec 30 21:41:46 The reason is it was apparently compiled against my native glibc, 2.30, while when it runs, it's using a glibc from sysroot-uninative, which is version 2.26 Dec 30 21:43:11 should I expect psuedo to run when invoked directly? It doesn't require some kind of special invocation (LD_PRELOAD, fakeroot, etc) to use the correct libraries? Dec 30 21:59:02 xyzzy42: whats your build host distro Dec 30 22:00:04 uninative is preferred to be used and it seems thats in play in your build which is ok Dec 30 22:01:15 khem, fedora 31 Dec 30 22:12:20 xyzzy42: ok I think f31 is used on some of Autobuilders nodes too so this issue should have appeared ther Dec 30 22:13:04 Am I correct the poky has built a native version of glibc 2.5.90 to link native executables against? Dec 30 22:13:22 oh only uptill f30 are there https://autobuilder.yoctoproject.org/typhoon/#/workers Dec 30 22:14:31 but I am sure there are users here who use f31, I dont so I have not seen the issue myself Dec 30 22:15:05 This is an old poky I'm using, so it's possible that the issue isn't present anymore Dec 30 22:15:24 xyzzy42: pseudo perhaps should be run in uninative env if you have used that to build it Dec 30 22:15:33 I didn't see any bugs or commits that appear related to this Dec 30 22:15:35 hmmm which version of poky Dec 30 22:16:06 It's a snapshot that was taken a bit after rocko-18.0.1 Dec 30 22:16:07 yes because there are tested distros and thats what would be recommended to build for a given release Dec 30 22:17:14 how would I see if psuedo-native was built in an uninative env? Dec 30 22:18:11 :) so you should mention that first what does bitbake -e busybox | grep "^SANITY_TESTED_DISTROS=" say ? Dec 30 22:19:11 empty Dec 30 22:19:30 I'm sure this poky was not build on f31, since it predates f31 by almost 3 years Dec 30 22:22:54 but it's not like the distro is fundamentally at odds with building. There's some specific problem here. Dec 30 22:23:28 It seems to be related to the library choice being different at link time vs run time Dec 30 22:26:42 It's entirely unclear to me where the heck the libc-2.25.90.so in sysroots-uninative came from. I see no other files from a native build of glibc. As well, trying to combine the host gcc with another glibc seems unlikely to work very well. Dec 30 22:27:05 host version is a large factor. getting an old release building on a new distro is non-trivial due to compiler changes (warnings changing to errors, etc) and glibc version incompatibilities, etc Dec 30 22:27:24 if you look through oe-core ou'll find fixes that went in for newer glibc versions Dec 30 22:27:34 through git history, that is Dec 30 22:29:11 kergoth, yes, I've had to fix a few of those to get this far. host gcc+glib has issues with old version of package X Dec 30 22:31:17 here, it's not clear to me what poky is trying to do. I don't see any flaw in pseudo itself. It looks like poky is trying to link it against one glibc and run it with another, which is just broken by design. Dec 30 22:43:21 I see where the glibc-2.25.90 is coming from. The uninative system downloads a pre-compiled c library and tries to use that. Dec 30 22:44:31 xyzzy42: right, thats the way to nullify different libc APIs that different distros will otherwise offer Dec 30 22:44:33 looks like it's an attempt to allow copying binaries for host tools across different distributions Dec 30 22:45:02 if you do not care for that then I would say disable the feature Dec 30 22:45:36 conf/distro/poky.conf:require conf/distro/include/yocto-uninative.inc Dec 30 22:45:37 conf/distro/poky.conf:INHERIT += "uninative" Dec 30 22:45:41 comment those out Dec 30 22:45:47 Hmm, I don't see how that can work very well. What happens when a host library linked against the host's glibc is used in the same executable as the different uninative glibc? Dec 30 22:59:21 generally that wont happen because it modifies the ldso Dec 30 22:59:26 loading path Dec 30 22:59:44 ldso will be used from uninative and that the hook to load the libs Dec 30 23:00:04 yes, I see the patchelf to change the interpreter to a local one. That's where it change the lib search order to uninative first Dec 30 23:01:07 also while "ldd native-build-exe" reports the incorrect libs, since it doesn't appear to reflect the ELF's interpreter and instead uses the host's Dec 30 23:02:19 but it seems like as soon as any build of a native executable uses a library which is not in uninative it will create the possibility of trying to pull in conflicting library versions Dec 30 23:04:16 I've tried to stop using uninative, I'm only interested in building an image, not a cross-distro SDK, but it looks like it's still getting pulled in. Dec 30 23:05:03 If there is a log line of "DEBUG: Inheriting /.../uninative.bbclass", that's means I've see got something inheriting it, right? Dec 30 23:10:27 Is the goal of uninative to replace _every_ host library with a locally built/downloaded one? Dec 30 23:52:37 not all Dec 31 00:13:34 JPEW: I think the solution we were going to look for were applications that used (linked to) the cancel pthread function, then we could autodetect it Dec 31 00:13:41 * RP -> Zzzz Dec 31 00:48:46 RP: poky/kraj/misc updated with your review and rebased on master with couple of patches I sent today Dec 31 01:53:03 khem, avoiding uninative has helped, thanks. Still plowing through build breakage of native packages but must be getting near the end. Why I need a native grub-efi for an ARM system that uses neither grub nor efi I have no idea... Dec 31 02:33:39 And I think I've made it past all the native package builds. But I'll keep my fingers cross until systemd finishes with the qemu based hwdb build. What a mess that is. **** ENDING LOGGING AT Tue Dec 31 02:59:57 2019