From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id C6D838D85 for ; Tue, 1 Dec 2015 14:31:00 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1a3l17-0005D7-Ie; Tue, 01 Dec 2015 08:30:55 -0500 Date: Tue, 1 Dec 2015 08:30:43 -0500 From: Neil Horman To: Robie Basak Message-ID: <20151201133043.GB26189@hmsreliant.think-freely.org> 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> <565D90AD.1070206@redhat.com> <20151201123615.GI28475@mal.justgohome.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151201123615.GI28475@mal.justgohome.co.uk> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.0 (-) X-Spam-Status: No 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 13:31:01 -0000 On Tue, Dec 01, 2015 at 12:36:15PM +0000, Robie Basak wrote: > On Tue, Dec 01, 2015 at 02:21:02PM +0200, Panu Matilainen wrote: > > 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. > > If we bundle all the libraries together into one package, then in > distributions we have to rebuild anyway when any of the libraries > changes version since a dependent package can't just depend on any later > version, because we don't know in advance what ABI breaks might occur. > It's also trivial to do rebuilds in a distribution. I'd prefer to see > ABI versioning done right to avoid the pain that might occur there. > Rebuilding dependent packages is on the other hand straightforward. > > > The combined library doesn't have symbol versioning, so besides the better > > version compatibility tracking it loses other benefits like limited symbol > > visibility. > > The combined library *should* have symbol versioning, which I've brought > up before. This isn't a reason to not have a combined library; it is a > reason to fix the combined library. > Agreed, but using a linker script as the combined library gets you the proper symbol versioning. > Why is limited symbol visibility a benefit in this case? > Because it prevents an application from inadvertently using symbols that would otherwise appear in another library (i.e. if not using the combined library, you know you've used a symbol in another library because you are then forced to add that library to the build. > > 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. > > I'd argue that this is because the build system is unnecessarily complex > currently. A library consumer should just be able to #include > and link with -ldpdk. It should not have a build system or > custom flags imposed on it by one of the libraries it uses. > I don't disagree here, but again, modeling libdpdk.so as a linker script gets you to that point (or 99% of the way there at least). Neil > Robie >