All of lore.kernel.org
 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: [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 [RFC PATCH] i40: remove weak version of i40e_rx_vec_dev_conf_condition_check() Zoltan Kiss
2016-07-20 17:11 ` [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.