From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 8AC21E00E55; Fri, 19 Jan 2018 04:38:38 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high * trust * [134.134.136.24 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 7D015E0085E for ; Fri, 19 Jan 2018 04:38:37 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jan 2018 04:38:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,381,1511856000"; d="scan'208";a="21043469" Received: from kanavin-desktop.fi.intel.com (HELO [10.237.68.161]) ([10.237.68.161]) by FMSMGA003.fm.intel.com with ESMTP; 19 Jan 2018 04:38:35 -0800 To: Andrea Galbusera References: <20d47e1b-c33b-d7f6-1b9e-f7a6f1e779a0@linux.intel.com> <24fffbce-1f44-dba6-aed2-913af75ba525@linux.intel.com> <28c69ac5-219a-8718-83f6-5f7f2b51bf10@linux.intel.com> From: Alexander Kanavin Message-ID: Date: Fri, 19 Jan 2018 14:32:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Cc: Mathias Rudnik , Yocto Project Subject: Re: Error do_compile libepoxy X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 12:38:38 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit > I'll try to recap a little bit but, please, forgive my ignorance in > graphics stacks and libraries. > Disclaimer: mostly working on headless systems... my bad! > This is what I think I understand here (remember I test building poky > + meta-raspberrypi): > * libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend > on virtual/X11 when this is available in DISTRO_FEATURE > * the latter is the case for poky which is the DISTRO I'm building > for. This gives i.e. a populated recipe-sysroot/usr/include/X11 > * upstream meson.build conditionally builds tests if X11 is > available... so we expect they should build fine in this case > * compile fails on test/egl_common.c which does not explicitly include > X11/Xlib.h by itself. Doing so moves things forward but, to me, does > not seem to be the right thing to do. > > Is this correct to assume that the upstream tested usecases are > probably getting the include otherwise, maybe conditionally as Alex > initially suggested. If so, where should we look for the missing > pieces? I'm similarly ignorant about this stuff (our resident graphics stack expert Jussi Kukkonen left a few months ago), but let's consider the build files: - the offending tests are wrapped in "if build_egl and build_x11_tests" - build_egl is controlled by a PACKAGECONFIG, and I guess you do have it available - "build_x11_tests = build_glx and x11_dep.found()" - build_glx is similarly controlled by a PACKAGECONFIG, and enabled if x11 is in DISTRO_FEATURES: PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11" PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl" This is where I think the configuration is not quite right. Instead of virtual/libx11, it should say virtual/libgl. And if that dependency cannot be satisfied, then the x11 option should be altogether disabled in the distro/local config (in poky mesa provides virtual/libgl). At least that's how it's configured in many other recipes throughout oe-core. Can you try: a) disabling x11 PACKAGECONFIG in your local config and see if things build? b) changing the dependency in that option to virtual/libgl and see what kind of error you get, if any. I guess this is the right fix after all. Alex