**** BEGIN LOGGING AT Fri Aug 03 03:00:00 2018
Aug 03 06:31:06 <malanecora> Hello everyone! I'm trying to compile PostGIS v2.4.4 (actually cross-compile with Yocto Project) but I'm running into trouble...GCC complains about "error: ../liblwgeom/.libs/liblwgeom.a: No such file or directory" when running 'do_compile' and that's bothering me because it seems that liblwgeom is never generated (at /liblwgeom/Makefile.in we can see that only liblwgeom.la is generated, indeed, there're a couple of commented lines
Aug 03 06:31:18 <malanecora> Does anyone know why is it trying to compile against a non-generated lib?
Aug 03 06:58:17 <yocti> New news from stackoverflow: Unable to executes the specified task a given target recipe <https://stackoverflow.com/questions/51666679/unable-to-executes-the-specified-task-a-given-target-recipe>
Aug 03 07:17:33 <malanecora> Can I just replace all references to liblwgeom.a by liblwgeom.la?
Aug 03 07:17:40 <malanecora> Or that would be no sense?
Aug 03 08:00:57 <aehs29> malanecora: no you cant, .a isnt the same as .la
Aug 03 08:01:14 <aehs29> malanecora: I would check the MAkefile rules to check why the static library isnt being built
Aug 03 08:03:22 <neverpanic> malanecora: I think yocto defaults to not compiling static libraries nowadays. If you want them, you'll have to explicitly enable them.
Aug 03 08:08:28 <malanecora> aehs29: neverpanic : I have checked the Make rules and seems that liblwgeom.a is not intended to be built. Just .la (along with .so) is built.
Aug 03 08:09:36 <malanecora> Also, I don't know where the flag to compile against liblwgeom.a comes from, because it shouldn't exist!
Aug 03 08:10:48 <malanecora> It's a bit crazy. Right now I'm building PostGIS inside my target system (i have already made it before) in order to check if, there, liblwgeom.a is built
Aug 03 08:11:26 <malanecora> (I don't think so, but who knows...)
Aug 03 08:36:13 <malanecora> Ok. To my surprise, it does build liblwgeom.a in the target device...
Aug 03 08:38:32 <malanecora> In fact, libtool automatically builds liblwgeom.a. The Makefile is pretty much the same as in Yocto.
Aug 03 08:38:57 <malanecora> Wizardry
Aug 03 08:52:57 <malanecora> Some in Yocto may be forcing the static lib not to be built
Aug 03 08:53:04 <malanecora> Something*
Aug 03 08:57:04 <JaMa> see meta/conf/distro/include/no-static-libs.in
Aug 03 09:00:37 <malanecora> https://paste.ofcode.org/xf6GtXieZZx2s5F3xwCQP8
Aug 03 09:04:44 <malanecora> Default Poky configuration
Aug 03 09:08:03 <malanecora> The strange thing is that it doesn't build liblwgeom.a along with libtool liblwgeom.la and .so as it is intended to be
Aug 03 09:08:56 <malanecora> But if I write a make rule to build liblwgeom.a in the classical way (ar cru lib...ranlib lib)
Aug 03 09:09:17 <malanecora> It build it, but fails when linking
Aug 03 09:10:46 <neverpanic> malanecora: That's the point. Yocto's default config is not to build static libs (as you can see in the no-static-libs.in file, see EXTRA_OECONF_append = "${DISABLE_STATIC}".
Aug 03 09:11:12 <neverpanic> For that reason, liblwgeom's build system likely disables building static libraries (although it could easily support building them)
Aug 03 09:12:02 <neverpanic> The problem is that PostGIS attempts to use the static library although it's not available. You should figure out why it does that and make it use the shared library.
Aug 03 09:12:38 <neverpanic> And if it can't or shouldn't use the shared library, you'll have to set DISABLE_STATIC_pn-liblwgeom = "" so enable building a static library.
Aug 03 09:17:28 <malanecora> neverpanic: Thank you very much! I'll try it out!
Aug 03 09:22:20 <malanecora> JaMa: Also, thank you for the tip!
Aug 03 09:35:17 <malanecora> Is there a way to modify that file (meta/conf/distro/include/no-static-libs.in) since it is not recommended to directly modify anything under poky folder?
Aug 03 09:41:46 <malanecora> Well, it seems to have worked!
Aug 03 09:42:06 <malanecora> Just had to add DISABLE_STATIC = "" to the postgis recipe
Aug 03 09:58:55 <yocti> New news from stackoverflow: How to use qemu for the image build for nanopi-neo-air in yocto <https://stackoverflow.com/questions/48150393/how-to-use-qemu-for-the-image-build-for-nanopi-neo-air-in-yocto>
Aug 03 14:22:16 <ttllkk> Hi, I am trying to remove 'ModemManager' from NetworkManager's PACKAGECONFIG from the local.conf, could someone help me do that?
Aug 03 14:22:31 <ttllkk> I am trying: PACKAGECONFIG_pn-networkmanager_remove = "modemmanager"
Aug 03 14:22:35 <ttllkk> but it is not working
Aug 03 14:29:38 <fray> I don't remember the processing order in this case...  You MIGHT have to reverse the override/remove fields
Aug 03 14:29:39 <yocti> New news from stackoverflow: How to use SSTATE_DUPWHITELIST variable in yocto <https://stackoverflow.com/questions/37369055/how-to-use-sstate-dupwhitelist-variable-in-yocto>
Aug 03 14:29:48 <fray> PACKAGECONFIG_remove_<override>
Aug 03 14:29:58 <fray> this will only do the 'remove' to PACKAGECONFIG, if the override is active at that time..
Aug 03 14:30:17 <fray> what you have right now says 'remove' from the variable PACKAGECONFIG_pn-networkmanager  which might not actually be defined anywhere
Aug 03 14:30:31 <fray> subtle difference, but I've had to do this in the past
Aug 03 14:33:08 <ttllkk> fray: hey, that worked! Thank you!
Aug 03 14:33:49 <fray> it's not obvious, but '_append', '_remove' are operators that affect the variable preceding them.. while other things following '_' are either part of the variable name or an override..
Aug 03 14:34:33 <fray> overrides are usually processed pretty late.. so you need to over the operations/overrides, so the operations match the declared variable, and the override only allos the operation when active..
Aug 03 14:34:46 <fray> like I said, subtle difference.. but one of the more advanced knowledge items to get right
Aug 03 15:07:37 <JPEW> armpit here?
Aug 03 15:59:08 <noway96> why was the modutils recipe removed from poky and replaced with modutils-initscripts recipe? I just want modinfo'
Aug 03 16:08:42 <yates> looking for hints on how to specify our own custom cpio.gz file to link to the kernel.
Aug 03 16:09:21 <rburton> noway96: that' in kmod
Aug 03 16:11:39 <noway96> rburton ty
Aug 03 16:11:43 <yates> is it as simple as setting INITRAMFS_IMAGE and INITRAMFS_FSTYPES?
Aug 03 16:12:33 <yates> and creating the recipe for generating cpio.gz?
Aug 03 16:17:18 <armpit> JPEW, yes
Aug 03 16:17:40 <armpit> RP, stable/sumo-next good to go
Aug 03 16:18:00 <JPEW> armpit: Actually, thats what I was going to comment about
Aug 03 16:18:17 <JPEW> armpit:  a6be839929 was reverted on master
Aug 03 16:19:10 <JPEW> It was reveted in 2869b56 in favor of 80443c42
Aug 03 16:22:23 <armpit> ah.. it was dropped by RP but I had it still
Aug 03 16:22:38 <armpit> thanks for the catch
Aug 03 16:23:16 <JPEW> np. There was someone on IRC just yesterday saying they had seen the problem, so it might still be worth backporting the correct fix
Aug 03 17:19:06 <khem> RP, rburton: Sent a RFT for glibc 2.28 see if you can accomodate an AB run
Aug 03 17:19:24 * khem feels like a troublemaker
Aug 03 17:33:01 <khem> there is branch kraj/glibc-2.28 on contrib repo too
Aug 03 17:58:05 <rburton> khem: did you see the patchtest reply
Aug 03 17:59:50 <khem> rburton: yes
Aug 03 17:59:52 <khem> fixing it
Aug 03 19:11:20 <armpit> khem, why fix it. Thought you where a troublemaker
Aug 03 20:12:07 <fancer> kergoth: great! Thanks, man. I'll check it out a bit later.
Aug 03 22:46:23 <khem> armpit: I sent a v2 :) which is better
Aug 03 22:46:36 <khem> armpit: yesterday night I was driving through your town
Aug 04 00:10:02 <kergoth> fancer: no worries, sorry for the delay. a combination of sorting out the big commit and just a lack of time for low priority tasks..
**** ENDING LOGGING AT Sat Aug 04 02:59:59 2018