From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 95CF54CE4 for ; Tue, 26 Jul 2016 17:10:16 +0200 (CEST) Received: by mail-wm0-f45.google.com with SMTP id o80so21550724wme.1 for ; Tue, 26 Jul 2016 08:10:16 -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=qnsnM3rTK/um8gjGUxyc5Xuf57mknreOWx/ylSX/4oI=; b=kPYa6eAzF+kOvAq9etp9MX8tVGY9+z6GTMrlWvI4rdsche8k2wb/PX/GLQ3lmWaNfQ KW2alzDsI6+KHOWsHdyUw/vVFycnIG/Wer8ZhPESYIAJyyPbpkj0Gl7J6tt0dO3fFRBk p5cXyjsFNB2DR0QL2Spfl9KWozLx3z7dgt3L0= 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=qnsnM3rTK/um8gjGUxyc5Xuf57mknreOWx/ylSX/4oI=; b=mu67nluBPsMV00hrE152b6ZS4bErRro6X09MSLeRK1UEhdshoa/kB2rNRQPhiWif3m pIKbLcxEsJae+VjRfQqmjz7hWgI5I6TPiCwdLHb39AFc6hsY0Cl0f2vu7l+wF/nMBQ/n fysQf4j45SIfh5RZObmODYek0J1TCoFseCkpu7d58up67F6ca9Y4PiEObHy+oazJYJP1 da1WeSQCbG5N5NNnPkbrhzB8Ek2I/3SdC1CczIykUI4unCK3JjDJb+OMmCXCV/TkpZtX mhlj2RkNSv4d9fn4JXwzTC2j45SgLiLHXFql5wIJFKpPTDvbc6vfETbNo+D1gsloFyqW 92RQ== X-Gm-Message-State: AEkoousBhHG0SZryWV9EoOdgUbmozRtXjQtZNLjk14VfqySvqYYhL6Duapci9YJfUzZ0Cuxy X-Received: by 10.194.31.68 with SMTP id y4mr16782074wjh.149.1469545816337; Tue, 26 Jul 2016 08:10:16 -0700 (PDT) Received: from [172.18.45.108] ([195.11.233.227]) by smtp.googlemail.com with ESMTPSA id d8sm2231365wmi.0.2016.07.26.08.10.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jul 2016 08:10:15 -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> <50e5bf41-5176-d419-404a-ff65d5b8f2f6@linaro.org> Cc: "dev@dpdk.org" , Matias Elo , "sergio.gonzalez.monroy@intel.com" , "ferruh.yigit@intel.com" , "damarion@cisco.com" , "thomas.monjalon@6wind.com" , Helin Zhang , Jingjing Wu From: Zoltan Kiss Message-ID: <9f8f8e49-5e34-11f9-2b84-80b481478ad3@linaro.org> Date: Tue, 26 Jul 2016 16:10:14 +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: <50e5bf41-5176-d419-404a-ff65d5b8f2f6@linaro.org> 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: Tue, 26 Jul 2016 15:10:16 -0000 Hi, I forgot to add the i40 maintainers as well. Would anyone like to weigh in? Regards, Zoltan On 22/07/16 12:34, Zoltan Kiss wrote: > > > 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 >>