On 09/04/2015 21:34, Neil Horman wrote: > On Thu, Apr 09, 2015 at 08:00:26PM +0300, Avi Kivity wrote: >> 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 <sergio.gonzalez.monroy at intel.com> 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 >>>>>>> <sergio.gonzalez.monroy at intel.com> >>>>>> 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. >> > no, I don't mean DT_NEEDED, I mean a linker script, because thats what what > sergio wrote is. > >>> 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. >> > Thats a good point, pkgconfig doesn't provide that additionally. Perhaps > having > both is the best solution. As for the DT_NEEDED issues, the earlier threads > ennumerated all the problems that were being found with the way the libraries > were organized (circular dependencies). > > Neil I am not entirely sure of the conclusion of this thread.
Are we happy with the current linker script solution as a replacement of the combined lib? Do we want to provide pkg-config file in addition or instead of linker script? I think I will split the series as there seems to be no objections to the patches related to DT_NEEDED entries. I'll post a series for DT_NEEDED entries and another series for dealing with the combined lib (once we get to an agreement). Does it sound reasonable? Sergio
