From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 959385580 for ; Fri, 22 Jul 2016 13:35:00 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id i5so62334678wmg.0 for ; Fri, 22 Jul 2016 04:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=NzVtW1R96A+RW27f2BzRwIswZLOHrshoohkIU3mRk4M=; b=CnrsUnZSbgqcCkNvJccsxMwo3jYW01YtYgpNsq4T7S7JmePJJFQMxk1AoW3ndY8GHk j7a6jF7TcnxrXsRGiNhresIrNIlfGplJJYyuq/VlnCxohEV13UvnL3moRPKP/nlZLQSx I83VFoH5Q+iDLTZ3JyslmdnvI3hseaiAOMDAc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NzVtW1R96A+RW27f2BzRwIswZLOHrshoohkIU3mRk4M=; b=QkUZjrBa2eBcEpm5FB0CHRbp/G6Qr8+aD+VAbMPVWWiMTYyv5/5fEC/+1LroyPWsNE T0RS9Oqw4sgQ3XCHkkwRrFCvuSprh5Yy0tO2lRBQeK0RSrP6OqZN1PGt2zy2afu8OZ4x imuKHDxFauy0AHC8jCRV72WDmLKJcNuk4pumn9dRDkTwVDcZQBOYu3QauDGkwAVGeiyx Kv5FSv8NiqknnnCdLQLJ5Cm8krxBKS6j5ppubdG0hnx6xNZcR5gOpJYxSVMJOPmEp8Zo y7+J9+dO+jN9Ky844Ny6lKKMVCu9cRZ7XHneensrPOXhJCe0GebWt7cAT2u5pp09gvBd Jd0Q== X-Gm-Message-State: AEkoout6LoLgU2RGBu8b7KdTA5xvvNNiUZp0WsysuYTcnJGneEdDLrRfy63K8AM/XpILUTW0 X-Received: by 10.28.193.8 with SMTP id r8mr4556092wmf.13.1469187300402; Fri, 22 Jul 2016 04:35:00 -0700 (PDT) Received: from [172.18.45.108] ([195.11.233.227]) by smtp.googlemail.com with ESMTPSA id r127sm12099110wmf.23.2016.07.22.04.34.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jul 2016 04:34:59 -0700 (PDT) To: bynes adam , Zoltan Kiss References: <1468938920-19679-1-git-send-email-zoltan.kiss@schaman.hu> <1469034676-2424-1-git-send-email-zoltan.kiss@schaman.hu> Cc: "dev@dpdk.org" , Matias Elo , "sergio.gonzalez.monroy@intel.com" , "ferruh.yigit@intel.com" , "damarion@cisco.com" , "thomas.monjalon@6wind.com" From: Zoltan Kiss Message-ID: <50e5bf41-5176-d419-404a-ff65d5b8f2f6@linaro.org> Date: Fri, 22 Jul 2016 12:34:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: remove weak symbols X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 11:35:00 -0000 On 21/07/16 19:58, bynes adam wrote: > On Wed, Jul 20, 2016 at 06:11:16PM +0100, Zoltan Kiss wrote: > Hi, Kiss >> Using weak symbols have a few issues with static linking: >> >> - normally the linker searches the .o files already linked, if your weak >> one is there, it won't check if there is a strong version >> - unless the symbol is directly referred, but it's not the right thing to >> rely on >> - or --whole-archive specified in the command line, which pulls in a lot >> of unwanted stuff > --whole-archive on the other hand can ensure all the object files are linked, > and the strong symbol will take precedence over weak symbol. So we don't need to > take care of the sequence of the object files in the ar or between ar. --whole-archive is primarily for shared libraries, just as weak symbols. When people do static linking, their reason is often to avoid carrying around a big library while they only use a fraction of it. >> - whole-archive also makes libtool dropping the library from the command >> line, which is what should happen with dynamic linking, but not with >> static (observed on Ubuntu 14.04). This is an important bug if you >> build a static library depending on DPDK > you mean the libtool bug for --whole-archive? > if it does, you shouldn't using the libtool, GNU libtool is a quite common tool for building libraries, it's a bit painful sometimes, but it works. What else do you recommend? I mean, something which is proven to be better? > BTW what's the circumstance you must use the libtool. using you own makefile for > the library or APP. Building libraries which depend on DPDK >> >> This patch merges the two version and make the behaviour rely on the >> config. >> >> If we can agree in the concept, I can send a series to fix this for the >> other weak functions. >> >> Signed-off-by: Zoltan Kiss >> --- >> >> Notes: >> v2: fix commit message >> >> drivers/net/i40e/i40e_rxtx.c | 36 +++++++++++++++++++++++++++++++++++- >> drivers/net/i40e/i40e_rxtx_vec.c | 36 ------------------------------------ >> 2 files changed, 35 insertions(+), 37 deletions(-) >> > From the original design, we follow the rule, we don't want the Macro in the file > to seperate the different Rx/Tx path for disabled/enabled vector configuration. And why is it better to compile two versions of the same function when you already know at the time of compilation which one do you want to use? > Adam Bynes >