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 at 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 >>
