From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7531AA0350; Mon, 29 Jun 2020 09:42:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B62FB1B5E1; Mon, 29 Jun 2020 09:42:43 +0200 (CEST) Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by dpdk.org (Postfix) with ESMTP id 85688E07 for <dev@dpdk.org>; Mon, 29 Jun 2020 09:42:42 +0200 (CEST) Received: by mail-lf1-f68.google.com with SMTP id g2so8534129lfb.0 for <dev@dpdk.org>; Mon, 29 Jun 2020 00:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ZV1W6bTs6UWXH0MkP+jkwB0Ydk6ZG1pepCyAUVgS5h4=; b=Zk/V5OAzl74bABcapqpRFISSGUw7d9SFZRGy06Fs+lyEbDon3+G2nlWR/eJE6aBkOm BerGdxNBmOu16zaOm6e3AsOBrpZb/bgSNmCv6V5DPXZHRwnGrnVL6aYEu9sKUKmjnVKa UEtyk4TZaoerFpcPEK8Xgqhm94gpjJRd8G3HF1u/NZfZFQyjo/220+swlQaWlWHqzeuf L1asoXB8t4jDJo7WMOLuf+0ECqGN4DjbEcu5doEecdUcdQdVzSnrWlKMKDxY3tw/riOQ uAJtZOpnQUEo477/J0eQYx5HAnRA5KZgKgra2WgIMoxZuZWR147udzLbFG2kM3UHJX/k DHOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ZV1W6bTs6UWXH0MkP+jkwB0Ydk6ZG1pepCyAUVgS5h4=; b=ilShcT+suJmFkoaZu1L6gr5BkwC2RdEfHqsjBCUA0eSbaAMGjckQXxMafbvLpU1BUs LRp30/VSWTsBKjHR1o2WqUAgOFyUBJh92FG90MjbQ6dt8uJ5RjPYLl06Urclw6BoOMia +nBYboxl7RagiSpL0WwXLwxCJyjOFmkiBksG8mWlWH38aWTvCEjqmqvugOB6GxZo2fNx N2+OouQN6MzxplsNUb2pBUwzw2BKYSw7R48rNP171YgMVZHPGqjnSZ+FLAk7m5IyVRzG /RukNSqzeSHGkFBEhv652mSTNua3d007t4ZvlijfntGrQWxlJN8ioCVSokogjwhbgHWX yVgQ== X-Gm-Message-State: AOAM530z0NwONig/6WbOoY2G73s5rt3T42YzhQz6ZadNfn57h/GeU3Bd w9qJRHgWRadvmCPpPdcgD5w= X-Google-Smtp-Source: ABdhPJx5AFkoMWd7ca5s1G4sTe4EKfPpx6I/168qmInk1TjF8lr7Yi4K9XJ01W9oNEtzePmO1FniYg== X-Received: by 2002:a05:6512:3049:: with SMTP id b9mr8481961lfb.44.1593416561910; Mon, 29 Jun 2020 00:42:41 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id t13sm7315876ljg.78.2020.06.29.00.42.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2020 00:42:41 -0700 (PDT) Date: Mon, 29 Jun 2020 10:42:39 +0300 From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> To: Ranjit Menon <ranjit.menon@intel.com> Cc: Fady Bader <fady@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>, Dmitry Malloy <dmitrym@microsoft.com>, Narcisa Ana Maria Vasile <Narcisa.Vasile@microsoft.com>, Tal Shnaiderman <talshn@mellanox.com>, Thomas Monjalon <thomas@monjalon.net>, Olivier Matz <olivier.matz@6wind.com> Message-ID: <20200629104239.7c0d3d68@sovereign> In-Reply-To: <8b908479-d64c-495d-3a69-de561f2608e8@intel.com> References: <20200620210511.13134-1-dmitry.kozliuk@gmail.com> <20200620210511.13134-7-dmitry.kozliuk@gmail.com> <VI1PR05MB5872166540572031222B60E5BF910@VI1PR05MB5872.eurprd05.prod.outlook.com> <8b908479-d64c-495d-3a69-de561f2608e8@intel.com> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 6/7] cmdline: support Windows X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Sun, 28 Jun 2020 23:23:11 -0700, Ranjit Menon wrote: > On 6/28/2020 7:20 AM, Fady Bader wrote: > > Hi Dmitry, > > I'm trying to run test-pmd on Windows and I ran into this error with cmdline. > > > > The error log message is : > > In file included from ../app/test-pmd/cmdline_flow.c:23: > > ..\lib\librte_cmdline/cmdline_parse_num.h:24:2: error: 'INT64' redeclared as different kind of symbol > > INT64 > > > > In file included from C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/winnt.h:150, > > from C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163, > > from C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/windef.h:8, > > from C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/windows.h:69, > > from ..\lib/librte_eal/windows/include/rte_windows.h:22, > > from ..\lib/librte_eal/windows/include/pthread.h:20, > > from ..\lib/librte_eal/include/rte_per_lcore.h:25, > > from ..\lib/librte_eal/include/rte_errno.h:18, > > from ..\lib\librte_ethdev/rte_ethdev.h:156, > > from ../app/test-pmd/cmdline_flow.c:18: > > C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/basetsd.h:32:44: note: previous declaration of 'INT64' was here > > __MINGW_EXTENSION typedef signed __int64 INT64,*PINT64; > > > > The same error is for the other types defined in cmdline_numtype. > > > > This problem with windows.h is popping in many places and some of them are > > cmdline and test-pmd and librte_net. > > We should find a way to exclude windows.h from the unneeded places, is there any > > suggestions on how it can be done ? > > We ran into this same issue when working with the code that is on the > draft repo. > > The issue is that UINT8, UINT16, INT32, INT64 etc. are reserved types in > Windows headers for integer types. We found that it is easier to change > the enum in cmdline_parse_num.h than try to play with the include order > of headers. AFAIK, the enums were only used to determine the type in a > series of switch() statements in librte_cmdline, so we simply renamed > the enums. Not sure, if that will be acceptable here. +1 for renaming enum values. It's not a problem of librte_cmdline itself but a problem of its consumption on Windows, however renaming enum values doesn't break ABI and winn make librte_cmdline API "namespaced". I don't see a clean way not to expose windows.h, because pthread.h depends on it, and if we hide implementation, librte_eal would have to export pthread symbols on Windows, which is a hack (or is it?). -- Dmitry Kozlyuk