From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 011191DB1 for ; Tue, 1 Dec 2015 13:21:05 +0100 (CET) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 3690AC07565C; Tue, 1 Dec 2015 12:21:05 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-6-72.ams2.redhat.com [10.36.6.72]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB1CL29m013460; Tue, 1 Dec 2015 07:21:02 -0500 To: Stephen Hemminger , Neil Horman References: <079fa1cfc3550c8147ea8b137fa1bc0f34d051dc.1448375477.git.pmatilai@redhat.com> <20151124144638.0b659e7d@xeon-e3> <56557398.3020600@redhat.com> <20151125080837.68e24a2d@xeon-e3> <20151130150343.GA9434@hmsreliant.think-freely.org> <20151130084102.3f386b50@xeon-e3> From: Panu Matilainen Message-ID: <565D90AD.1070206@redhat.com> Date: Tue, 1 Dec 2015 14:21:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151130084102.3f386b50@xeon-e3> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script 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, 01 Dec 2015 12:21:06 -0000 On 11/30/2015 06:41 PM, Stephen Hemminger wrote: > On Mon, 30 Nov 2015 10:03:43 -0500 > Neil Horman wrote: > >> On Wed, Nov 25, 2015 at 08:08:37AM -0800, Stephen Hemminger wrote: >>> On Wed, 25 Nov 2015 10:38:48 +0200 >>> Panu Matilainen wrote: >>> >>>> On 11/25/2015 12:46 AM, Stephen Hemminger wrote: >>>>> On Tue, 24 Nov 2015 16:31:17 +0200 >>>>> Panu Matilainen wrote: >>>>> >>>>>> The physically linked-together combined library has been an increasing >>>>>> source of problems, as was predicted when library and symbol versioning >>>>>> was introduced. Replace the complex and fragile construction with a >>>>>> simple linker script which achieves the same without all the problems, >>>>>> remove the related kludges from eg mlx drivers. >>>>>> >>>>>> Since creating the linker script is practically zero cost, remove the >>>>>> config option and just create it always. >>>>>> >>>>>> Based on a patch by Sergio Gonzales Monroy, linker script approach >>>>>> initially suggested by Neil Horman. >>>>>> >>>>>> Suggested-by: Sergio Gonzalez Monroy >>>>>> Suggested-by: Neil Horman >>>>>> Signed-off-by: Panu Matilainen >>>>> >>>>> But it now means distros have to ship 20 libraries which seems like >>>>> a step back. >>>> >>>> That's how Fedora and RHEL are shipping it already and nobody has so >>>> much as noticed anything strange, much less complained about it. 20 >>>> libraries is but a drop in the ocean on a average distro. But more to >>>> the point, distros will prefer 50 working libraries over one that doesn't. >>>> >>>> The combined library as it is simply is no longer a viable option. >>>> Besides just being broken (witness the strange hacks people are coming >>>> up with to work around issues in it) its ugly because it basically gives >>>> the middle finger to all the effort going into version compatibility, >>>> and its also big. Few projects will use every library in DPDK, but with >>>> the combined library they're forced to lug the 800 pound gorilla along >>>> needlessly. >>>> >>>> - Panu - >>>> >>> >>> Fixing the combined library took less than an hour for us. >> How did you fix the versioning issue? >> >> Neil > > This is what I did. > Also decided to keep shared library version == major DPDK version > to avoid confusion. > > > mk: fix when building combined shared library > > The DPDK mk file does not set shared object name or version > information as required by Debian. > > Signed-off-by: Stephen Hemminger > > --- a/mk/rte.sharelib.mk > +++ b/mk/rte.sharelib.mk > @@ -51,10 +51,10 @@ ifeq ($(LINK_USING_CC),1) > # Override the definition of LD here, since we're linking with CC > LD := $(CC) $(CPU_CFLAGS) > O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \ > - -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) > + -shared $(OBJS) -Wl,-soname,$(LIB_ONE).$(RTE_LIBVERS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) > else > O_TO_S = $(LD) $(CPU_LDFLAGS) \ > - -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) > + -shared $(OBJS) -soname $(LIB_ONE).$(RTE_LIBVERS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) > endif > > O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight > --- a/mk/rte.vars.mk > +++ b/mk/rte.vars.mk > @@ -74,8 +74,10 @@ ifneq ($(BUILDING_RTE_SDK),) > endif > > RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) > +RTE_LIBVERS := $(CONFIG_RTE_LIBVERS:"%"=%) > ifeq ($(RTE_LIBNAME),) > RTE_LIBNAME := intel_dpdk > +RTE_LIBVERS := 2 > endif > > # RTE_TARGET is deducted from config when we are building the SDK. > Adding a soname and a semi-arbitrary version does not fix the fundamental problems: Since the library lumps together everything in DPDK, you'd have to bump its version whenever any of the individual libraries bumps its version to have the version mean anything. DPDK 2.0 and 2.1 are supposedly binary compatible but 2.2 certainly is not, and beyond that who knows. That in turn forces all apps to be rebuild whenever one of the libraries changes version, whether those apps use that particular library or not. The combined library doesn't have symbol versioning, so besides the better version compatibility tracking it loses other benefits like limited symbol visibility. Not to mention the extra complexity in makefiles to support it, the increasing amount of duct-tape required to hold it together. And still eg the MLX pmds declare the configuration not supported at all. - Panu -