From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8B5B2A04B5; Sat, 21 Nov 2020 21:47:33 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 481C9F90; Sat, 21 Nov 2020 21:47:31 +0100 (CET) Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by dpdk.org (Postfix) with ESMTP id EE5833B5 for ; Sat, 21 Nov 2020 21:47:28 +0100 (CET) Received: by mail-lf1-f65.google.com with SMTP id r24so2262708lfm.8 for ; Sat, 21 Nov 2020 12:47:28 -0800 (PST) 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=lnjd1EunUCidB9GsJ+7W0iQTMspu6ivyFznh4JIKEGY=; b=jzAyoJs+1q0ulxnt+0fG9eFPTi/TXjuw30TU+view964LQIf8Focu46ZZgLlXa/BJM j//h4cR6nVifZa4Ps1+GIlzqTK1nFa74f0u5nzhTQGBIlbYCKUFA6ciH+aROh4yW6i2e A70ShitJfp+zQO1Bi7LvLyuRADl6QYcnMS+byIdDCHY281jeYNZFQEEtP3KKVTNChYh6 GPYCwf51MmyUDuaiq6weuuBsZPSpqu2XhmaitPljmRpeGGKgdtKRTZYsFp50fw9MepIk T1bih1bRcDOPvMZsJVEyF/Umk87ukInRk90tTqxzqjfaXbKJukqo4GkedSEB8K3xId0Q ZPOQ== 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=lnjd1EunUCidB9GsJ+7W0iQTMspu6ivyFznh4JIKEGY=; b=aHorGJ8PgskQ+Oj5kJIJiW2MJn0skr9ZbyFLR1O3SzsODNws5QZ+m9SX+HkBiM82Qg ypD5kA0AcW1D9HtV+NaEU0AZ8h1kZj7HUP9scsqGxCa6P3sGtdsu8dbFAnBel1cU/gZ1 VxofdaWXh4ooqd3su/+qOTmDvXSVlBKXsHkGUaCleYS48bqcCDXxc9w9Q6KUgfxvVJha QBrdhKCa2+uaq3MM0p74ldY3IqG30Fd08Gyu4AgMZmF3YlEnFhQke+H1ZriEnFdgyALB 2Ciol1lgMRItEuEq4JBJ6iY8kaoB0OXEFZn8pqmaLCVwugWzidvTRZOlo4ZhmTifrRGQ T0bQ== X-Gm-Message-State: AOAM532gQXgga6PmNK5Sp9ZctN60R+MsgTs6lOBLydfpDW6NI8MCuqW0 INtSfvqZ4V4DWtTJs9ahXf0= X-Google-Smtp-Source: ABdhPJxnYDrgmuQ5AgLIWYOvmX+AZOEITZP6rY55hZiUNPQqnH7ios2KJBaXVjiYq79YHZKYfov9PA== X-Received: by 2002:a19:857:: with SMTP id 84mr9867453lfi.235.1605991647431; Sat, 21 Nov 2020 12:47:27 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id o3sm822370lfo.217.2020.11.21.12.47.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 Nov 2020 12:47:26 -0800 (PST) Date: Sat, 21 Nov 2020 23:47:25 +0300 From: Dmitry Kozlyuk To: Nick Connolly Cc: Tal Shnaiderman , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam , Tal Shnaiderman , "dev@dpdk.org" Message-ID: <20201121234725.6b9c823d@sovereign> In-Reply-To: References: <20201120211255.24803-1-nick.connolly@mayadata.io> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] eal/windows: fix link error with MinGW X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Hi Nick, Thanks for detailed explanation. It can be reproduced even without DPDK: #include #include int main(int argc, char **argv) { return (int)&GUID_DEVCLASS_NET; } This links with clang, but not with MinGW-w64. AFAIK, it should not link, because INITGUID is not defined. @DmitryM, @Naty, correct me if I'm wrong. So I agree your fix is needed. > Sure - latest MinGW-w64 (v8.0.0 I believe, but the versioning isn't too=20 > clear to me!). This is correct, MinGW-w64 version is different from GCC version, so it's MinGW-w64 8.0.0 with GCC 8.1.0. >=C2=A0[...] Arguably, it would perhaps be better to define=20 > INITGUID in the source files that use the guids instead of in a shared=20 > header, but I think this can safely be left until after 20.11 is=20 > finalized - if there's any impact on the code produced it will be=20 > negligible. I disagree. Just because we have rte_windows.h to properly plug Windows SDK in, other DPDK code doesn't need to care about these details. Unused GUIDs = do take some space in static libraries, but IMO it's a fair trade for ease of development. They shouldn't have any impact on resulting binaries.