DPDK patches and discussions
 help / color / mirror / Atom feed
From: Zoltan Kiss <zoltan.kiss@linaro.org>
To: bynes adam <adambynes@outlook.com>, Zoltan Kiss <zoltan.kiss@schaman.hu>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Matias Elo <matias.elo@nokia-bell-labs.com>,
	"sergio.gonzalez.monroy@intel.com"
	<sergio.gonzalez.monroy@intel.com>,
	"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
	"damarion@cisco.com" <damarion@cisco.com>,
	"thomas.monjalon@6wind.com" <thomas.monjalon@6wind.com>,
	Helin Zhang <helin.zhang@intel.com>,
	Jingjing Wu <jingjing.wu@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: remove weak symbols
Date: Tue, 26 Jul 2016 16:10:14 +0100	[thread overview]
Message-ID: <9f8f8e49-5e34-11f9-2b84-80b481478ad3@linaro.org> (raw)
In-Reply-To: <50e5bf41-5176-d419-404a-ff65d5b8f2f6@linaro.org>

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 <zoltan.kiss@schaman.hu>
>>> ---
>>>
>>> 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
>>

  reply	other threads:[~2016-07-26 15:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 14:35 [dpdk-dev] [RFC PATCH] i40: remove weak version of i40e_rx_vec_dev_conf_condition_check() Zoltan Kiss
2016-07-20 17:11 ` [dpdk-dev] [PATCH v2] net/i40e: remove weak symbols Zoltan Kiss
2016-07-21 18:58   ` bynes adam
2016-07-22 11:34     ` Zoltan Kiss
2016-07-26 15:10       ` Zoltan Kiss [this message]
2016-09-14 13:42   ` Ferruh Yigit
2016-09-27 13:27     ` Zoltan Kiss
2016-10-10 14:36   ` Wu, Jingjing

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9f8f8e49-5e34-11f9-2b84-80b481478ad3@linaro.org \
    --to=zoltan.kiss@linaro.org \
    --cc=adambynes@outlook.com \
    --cc=damarion@cisco.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=helin.zhang@intel.com \
    --cc=jingjing.wu@intel.com \
    --cc=matias.elo@nokia-bell-labs.com \
    --cc=sergio.gonzalez.monroy@intel.com \
    --cc=thomas.monjalon@6wind.com \
    --cc=zoltan.kiss@schaman.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).