**** BEGIN LOGGING AT Tue Nov 27 03:00:01 2018 Nov 27 05:36:36 ant_home: use meta-kodi Nov 27 05:37:03 ant_home: kodi on mips+musl is rare combo Nov 27 05:37:07 so you might have issues Nov 27 08:02:57 good morning Nov 27 12:18:06 what release has gcc-6 in it? Nov 27 12:18:31 Crofton: pyro or rocko, IIRC Nov 27 12:19:42 thanks Nov 27 12:20:18 too many gcc verions to little time Nov 27 12:20:34 Crofton: you gettin' old? Nov 27 12:20:48 Of course not! Nov 27 12:20:56 * Crofton waves his cane at the youngster Nov 27 12:23:39 metal cane? Nov 27 12:23:57 hah Nov 27 14:59:56 Before recipe specific sysroot -native packages would often be built to look for config files, modules, etc off of sysroots. Now I find some packages are built to looks for the same such files off of their recipe-sysroot-native. While this used to "work" it no longer does since the executables need to look in the recipe specific sysroot they're running under, not the one they used to build. In general, what are the ways of deal with this problem? I see for Nov 27 14:59:56 openssl, OE uses a wrapper script to override environment variables so the baked in paths aren't used (OPENSSL_CONF, SSL_CERT_DIR, SSL_CERT_FILE, OPENSSL_ENGINES). If a software package doesn't allow you to use environment variables to override such paths what are the possible solutions other than adding support for such variables? Nov 27 15:10:37 I really have to wonder whether it would be wise to setup a chroot jail for each recipe with recipe-sysroot-native being /. I'm sure someone has thought of this already though and it would undoubtedly cause other major design challenges. Nov 27 15:56:19 georgem: assumptions that build sysroot is constant was broken anyway Nov 27 15:56:35 if i build openssl in build1 but then use it in build2 with different tmpdirs, the sysroot paths are different Nov 27 15:56:44 so recipe-specific-sysroots just made it break more obviously Nov 27 15:57:41 a reimplentation of the core classes using user-mode containers would definitely be interesting Nov 27 15:58:46 rburton_: right. which is why I said "work". What are the correct ways of dealing with this? If something is built with a compiled in path does the code pretty much need to be changed so that it can be overridden by an environment variable? Nov 27 16:01:57 ye Nov 27 16:01:58 yes Nov 27 16:02:31 if that path can be overridden with a command line option or env var then there's tooling to create wrappers Nov 27 16:02:43 env var or cmdline arg, or better yet, let the tool find its paths relative to its own location and sidestep the issue entirely Nov 27 16:03:03 the latter is usually more invasive, but if you're having to add the support anyway... Nov 27 16:03:06 :) Nov 27 16:04:03 i've been meaning to extend the relocation magic we can do for SDKs to the sysroot stuff Nov 27 16:04:29 which lets you mark up the hardcoded paths to a special segment and our tooling will rewrite it for you Nov 27 16:27:26 nice. i've t hought about that sort of thing too. using a proper placeholder would avoid the necessity of overriding prefix in native **** ENDING LOGGING AT Wed Nov 28 03:00:01 2018