From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by dpdk.org (Postfix) with ESMTP id 07D575A52 for ; Thu, 9 Apr 2015 19:00:29 +0200 (CEST) Received: by wiaa2 with SMTP id a2so106286700wia.0 for ; Thu, 09 Apr 2015 10:00:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NcrgXktkfZZsBH3Gd0LzGEddQJZP7ne5D1s61xwwPoE=; b=IJs1Z5k/u1ixufCvHzmY7PlxYN0hUrbgZhHfwTG1cWwYEI2kmCTNMF7DkxvhI80vO9 v+AWIv3gxiqFQIeqhLc1XjsJDIbxLoJ8P99QcdUyILW15rnz0Zvz9P9DNcv1PzfnE2iI Fzw/C2N2yP0tVo9Ucu2WYoHg0GpI23iOam96L7FNKVP6GyINOtBZP2ovFz13lvg9Otkj XJKIOH9tVI6JcfbtU4H/qTeAn35DbGLEH13hcUN/PaUTPfdN6PVDkVuQcI0zWybQv5+B SRQFw+rIJiKQwQST/C7Bxp9u/fhEtxaeduIZdUp0Q+6ku8+/jOF+sPksZ48u4/P4XO52 bHNQ== X-Gm-Message-State: ALoCoQnJ0zzFV3IWBt8WLoPzQqsk11b08rPUxEexQog7iGnMSlWxvP6LdaEjLBwdZArdGce57dkV X-Received: by 10.194.5.74 with SMTP id q10mr20522659wjq.27.1428598828886; Thu, 09 Apr 2015 10:00:28 -0700 (PDT) Received: from [10.0.0.4] ([109.66.151.167]) by mx.google.com with ESMTPSA id g5sm20896972wjr.19.2015.04.09.10.00.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 10:00:27 -0700 (PDT) Message-ID: <5526B02A.70700@cloudius-systems.com> Date: Thu, 09 Apr 2015 20:00:26 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Neil Horman References: <1428505645-5578-1-git-send-email-sergio.gonzalez.monroy@intel.com> <1428505645-5578-2-git-send-email-sergio.gonzalez.monroy@intel.com> <20150408112619.14596b65@urahara> <55263955.1070707@intel.com> <55264127.2020604@cloudius-systems.com> <20150409111943.GA26201@hmsreliant.think-freely.org> In-Reply-To: <20150409111943.GA26201@hmsreliant.think-freely.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options 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: Thu, 09 Apr 2015 17:00:29 -0000 On 04/09/2015 02:19 PM, Neil Horman wrote: > On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote: >> >> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote: >>> On 08/04/2015 19:26, Stephen Hemminger wrote: >>>> On Wed, 8 Apr 2015 16:07:21 +0100 >>>> Sergio Gonzalez Monroy wrote: >>>> >>>>> Currently, the target/rules to build combined libraries is different >>>>> than the one to build individual libraries. >>>>> >>>>> By removing the combined library option as a build configuration option >>>>> we simplify the build pocess by having a single point for >>>>> linking/archiving >>>>> libraries in DPDK. >>>>> >>>>> This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and >>>>> removes the makefiles associated with building a combined library. >>>>> >>>>> The CONFIG_RTE_LIBNAME config option is kept as it will be use to >>>>> always generate a linker script that acts as a single combined library. >>>>> >>>>> Signed-off-by: Sergio Gonzalez Monroy >>>>> >>>> No. We use combined library and it greatly simplfies the application >>>> linking process. >>>> >>> After all the opposition this patch had in v2, I did explain the current >>> issues >>> (see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was >>> the agreed solution. >>> >>> As I mention in the cover letter (also see patch 2/5), building DPDK >>> (after applying this patch series) will always generate a very simple >>> linker script that behaves as a combined library. >>> I encourage you to apply this patch series and try to build your app >>> (which links against combined lib). >>> Your app should build without problem unless I messed up somewhere and it >>> needs fixing. >> Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of >> the setting needed to compile and link with dpdk? That will greatly >> simplify usage. >> >> A linker script is just too esoteric. >> > Why esoteric? We're not talking about a linker script in the sense of a binary > layout file, we're talking about a prewritten/generated libdpdk_core.so that > contains linker directives to include the appropriate libraries. You link it > just like you do any other library, but it lets you ignore how they are broken > up. You mean DT_NEEDED? That's great, but it shouldn't be called a linker script. > We could certainly do a pkg-config file, but I don't think thats any more > adventageous than this solution. It solves more problems -- cflags etc. Of course having the right DT_NEEDED is a good thing regardless.