From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by dpdk.org (Postfix) with ESMTP id 4B9E58D3D for ; Tue, 1 Dec 2015 13:36:19 +0100 (CET) Received: from 1.general.rbasak.uk.vpn ([10.172.195.6] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1a3kAJ-0002xk-UK; Tue, 01 Dec 2015 12:36:15 +0000 Date: Tue, 1 Dec 2015 12:36:15 +0000 From: Robie Basak To: Panu Matilainen Message-ID: <20151201123615.GI28475@mal.justgohome.co.uk> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <565D90AD.1070206@redhat.com> 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:36:19 -0000 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. Why is limited symbol visibility a benefit in this case? > 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. Robie