From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8A38DA09E4; Fri, 29 Jan 2021 11:09:32 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6CA3724015F; Fri, 29 Jan 2021 11:09:32 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id 49E9E240134 for ; Fri, 29 Jan 2021 11:09:30 +0100 (CET) IronPort-SDR: kKBHzys0G9uPmZX2kIsvlExML8pwI+PCOb8HsSQRQ3Hs6wpnLcYjZXuSWjkAfFgnFuI8pkiPH8 gYUjkf7JfDRQ== X-IronPort-AV: E=McAfee;i="6000,8403,9878"; a="160170314" X-IronPort-AV: E=Sophos;i="5.79,385,1602572400"; d="scan'208";a="160170314" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jan 2021 02:09:29 -0800 IronPort-SDR: kROvhfYo7Y/FOEEQhPMremv2PfVT3iRF829zkyi78EfF09bS8dlIBixST7t3FHVDXTauqw3FYf trlD5buS7I5g== X-IronPort-AV: E=Sophos;i="5.79,385,1602572400"; d="scan'208";a="474470265" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.20.59]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 29 Jan 2021 02:09:26 -0800 Date: Fri, 29 Jan 2021 10:09:23 +0000 From: Bruce Richardson To: Juraj =?utf-8?Q?Linke=C5=A1?= Cc: Andrew Boyer , Honnappa Nagarahalli , "thomas@monjalon.net" , Ruifeng Wang , Phil Yang , "vcchunga@amazon.com" , Dharmik Thakkar , "jerinjacobk@gmail.com" , "hemant.agrawal@nxp.com" , "Ajit Khaparde (ajit.khaparde@broadcom.com)" , "ferruh.yigit@intel.com" , "dev@dpdk.org" , nd Message-ID: <20210129100923.GD929@bricha3-MOBL.ger.corp.intel.com> References: <1605874101-30893-1-git-send-email-juraj.linkes@pantheon.tech> <1608724059-8562-1-git-send-email-juraj.linkes@pantheon.tech> <36181A92-BE14-4E30-8F26-915AA109BB2F@pensando.io> <50293579.Yt1MtOie5U@thomas> <2B294ECB-F553-4E90-ADF3-A48692195390@pensando.io> <2250268882af4e26980359ad2334dcff@pantheon.tech> <0f7f5f1a0ab24efbadc99db4026e3d1c@pantheon.tech> <20210129094541.GA929@bricha3-MOBL.ger.corp.intel.com> <1c417dfcded6499fb76bef6128a67918@pantheon.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1c417dfcded6499fb76bef6128a67918@pantheon.tech> Subject: Re: [dpdk-dev] [PATCH v14 00/12] Arm build options rework X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jan 29, 2021 at 10:07:30AM +0000, Juraj Linkeš wrote: > > > > -----Original Message----- > > From: Bruce Richardson > > Sent: Friday, January 29, 2021 10:46 AM > > To: Juraj Linkeš > > Cc: Andrew Boyer ; Honnappa Nagarahalli > > ; thomas@monjalon.net; Ruifeng Wang > > ; Phil Yang ; > > vcchunga@amazon.com; Dharmik Thakkar ; > > jerinjacobk@gmail.com; hemant.agrawal@nxp.com; Ajit Khaparde > > (ajit.khaparde@broadcom.com) ; > > ferruh.yigit@intel.com; dev@dpdk.org; nd > > Subject: Re: [dpdk-dev] [PATCH v14 00/12] Arm build options rework > > > > On Fri, Jan 29, 2021 at 08:41:45AM +0000, Juraj Linkeš wrote: > > > > > 3) We need to build kni against the aarch64 kernel headers, but it > > > > > fails. It appears that kernel/linux/kni/meson.build doesn’t pass > > > > > any cross-compile flags in the make command it creates. The diff > > > > > below shows how I hardcoded it to get it to work for now. Thoughts > > > > > on how to do this right? meson has the path (in $PATH) and the > > > > > binary prefixs (in ‘[binaries]’ in the cross file). It must know > > > > > the arch, too. > > > > > > > > > > --- a/kernel/linux/kni/meson.build +++ > > > > > b/kernel/linux/kni/meson.build @@ -14,6 +14,8 @@ > > > > > custom_target('rte_kni', input: kni_sources, > > > > > output: 'rte_kni.ko', command: ['make', '-j4', '-C', kernel_dir + > > > > > '/build', + + > > > > > 'CROSS_COMPILE=/tool/toolchain/aarch64-1.1/bin/aarch64-linux- > > > > > gnu-', > > > > > + 'ARCH=aarch64', 'M=' + meson.current_build_dir(), > > > > > 'src=' + meson.current_source_dir(), 'MODULE_CFLAGS=-include ' + > > > > > meson.source_root() + '/config/rte_config.h' + > > > > > > > > > > > > > Yes, Meson should know these. I'll submit this separately (in a new > > > > series), as this series is getting pretty big and this fix is > > > > actually unrelated. > > > > > > > > > > I tried to figure out how to implement this and I've ran into a brick > > > wall - there's no way to figure out the full name of the cross-compiler. > > > I found only one way to get the cross compiler: > > > meson.get_compiler('c', > > > native:false).get_id() > > > > > > But that only retuns 'gcc', not the full binary name (c = > > > 'aarch64-linux-gnu-gcc' in cross file). > > > > > > Bruce, any ideas on how to get the full name? If I understand the > > > sources right, we aren't able to access arbitrary object attributes, > > > just those, which are specifically exposed. > > > > > > Maybe we could do a workaround? Either if cross compiling and the > > > compiler is gcc, use the 'aarch64-linux-gnu-' prefix or just put the > > > prefix into the cross file as an additional property? > > > > > According to the cross-file/native-file documentation[1], the files in the binaries > > section can be queried using the "find_program()" call. That then returns an > > external program object rather than a compiler one, so the full path can be got. > > Unfortunately, find_program('c') doesn't seem to work for the non-cross- > > compiled case, so it will need to be conditional on cross-compilation. > > > > Thanks, this is great, I'll use this. > We don't need it for native builds. But it's strange that it doesn't work for those - the docs say it does. > If probably works if a native-file rather than a cross-file is passed. Without a native file, meson is probably looking for a program called "c" on the OS, rather than recognising that it's the C compiler being looked for. /Bruce