[dpdk-dev,v3,1/5] mk: remove combined library and related options
Commit Message
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@intel.com>
---
config/common_bsdapp | 3 +-
config/common_linuxapp | 3 +-
lib/Makefile | 1 -
mk/rte.app.mk | 12 ------
mk/rte.lib.mk | 35 -----------------
mk/rte.sdkbuild.mk | 3 --
mk/rte.sharelib.mk | 101 -------------------------------------------------
mk/rte.vars.mk | 4 --
8 files changed, 2 insertions(+), 160 deletions(-)
delete mode 100644 mk/rte.sharelib.mk
Comments
On Wed, 8 Apr 2015 16:07:21 +0100
Sergio Gonzalez Monroy <sergio.gonzalez.monroy@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@intel.com>
No. We use combined library and it greatly simplfies the application
linking process.
On 08/04/2015 19:26, Stephen Hemminger wrote:
> On Wed, 8 Apr 2015 16:07:21 +0100
> Sergio Gonzalez Monroy <sergio.gonzalez.monroy@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@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.
Sergio
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@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@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.
On 09/04/2015 10:06, 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@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@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.
>
>
That sounds very interesting.
I would be in favor of dropping the linker script for this solution if
everybody is happy with it.
Sergio
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@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@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.
We could certainly do a pkg-config file, but I don't think thats any more
adventageous than this solution.
Neil
>
>
2015-04-09 07:19, Neil Horman:
> 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@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@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.
>
> We could certainly do a pkg-config file, but I don't think thats any more
> adventageous than this solution.
As already commented (http://dpdk.org/ml/archives/dev/2015-March/015367.html),
pkgconfig could be something useful in any case (single or multi-libraries).
Having a linker script to replace the single ("combined") library may be
convenient in some cases but do not replace pkgconfig.
On 09/04/2015 14:33, Thomas Monjalon wrote:
> 2015-04-09 07:19, Neil Horman:
>> 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@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@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.
>>
>> We could certainly do a pkg-config file, but I don't think thats any more
>> adventageous than this solution.
> As already commented (http://dpdk.org/ml/archives/dev/2015-March/015367.html),
I misunderstood the pkgconfig reference in your previous comment.
It seems even more trivial to generate the 'combined' linker script lib
having a pkg-config file.
We could simplify much of the rte.app.mk by using a pkg-config file.
Sergio
> pkgconfig could be something useful in any case (single or multi-libraries).
> Having a linker script to replace the single ("combined") library may be
> convenient in some cases but do not replace pkgconfig.
>
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@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@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.
> 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.
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@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@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
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@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@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
2015-04-13 10:52, Gonzalez Monroy, Sergio:
> 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@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@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?
Yes pkg-config should be an addition on top of shared/static split/combined
libraries (or linker script). It should be an alternative to mk/rte.app.mk.
> 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?
Yes good idea, thanks.
On Mon, Apr 13, 2015 at 01:04:52PM +0200, Thomas Monjalon wrote:
> 2015-04-13 10:52, Gonzalez Monroy, Sergio:
> > 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@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@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?
>
> Yes pkg-config should be an addition on top of shared/static split/combined
> libraries (or linker script). It should be an alternative to mk/rte.app.mk.
>
Adding a pkg-config file I think makes lots of sense.
> > 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?
>
yup
>
@@ -79,9 +79,8 @@ CONFIG_RTE_FORCE_INTRINSICS=n
CONFIG_RTE_BUILD_SHARED_LIB=n
#
-# Combine to one single library
+# Combined library name
#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
CONFIG_RTE_LIBNAME=intel_dpdk
#
@@ -79,9 +79,8 @@ CONFIG_RTE_FORCE_INTRINSICS=n
CONFIG_RTE_BUILD_SHARED_LIB=n
#
-# Combine to one single library
+# Combined library name
#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
CONFIG_RTE_LIBNAME="intel_dpdk"
#
@@ -77,5 +77,4 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
endif
-include $(RTE_SDK)/mk/rte.sharelib.mk
include $(RTE_SDK)/mk/rte.subdir.mk
@@ -61,12 +61,6 @@ ifeq ($(NO_AUTOLIBS),)
LDLIBS += --whole-archive
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
-LDLIBS += -l$(RTE_LIBNAME)
-endif
-
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y)
LDLIBS += -lrte_distributor
endif
@@ -137,8 +131,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y)
LDLIBS += -lrte_vhost
endif
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
LDLIBS += -lpcap
endif
@@ -153,8 +145,6 @@ endif
LDLIBS += --start-group
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y)
LDLIBS += -lrte_kvargs
endif
@@ -253,8 +243,6 @@ endif
endif # plugins
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
LDLIBS += $(EXECENV_LDLIBS)
LDLIBS += --end-group
@@ -87,24 +87,6 @@ O_TO_S_DO = @set -e; \
$(O_TO_S) && \
echo $(O_TO_S_CMD) > $(call exe2cmd,$(@))
-ifeq ($(RTE_BUILD_SHARED_LIB),n)
-O_TO_C = $(AR) crus $(LIB_ONE) $(OBJS-y)
-O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
-O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)"," AR_C $(@)")
-O_TO_C_DO = @set -e; \
- $(lib_dir) \
- $(copy_obj)
-else
-O_TO_C = $(LD) -shared $(OBJS-y) -o $(LIB_ONE)
-O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
-O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)"," LD_C $(@)")
-O_TO_C_DO = @set -e; \
- $(lib_dir) \
- $(copy_obj)
-endif
-
-copy_obj = cp -f $(OBJS-y) $(RTE_OUTPUT)/build/lib;
-lib_dir = [ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib;
-include .$(LIB).cmd
#
@@ -129,15 +111,6 @@ endif
$(depfile_missing),\
$(depfile_newer)),\
$(O_TO_S_DO))
-
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
- $(if $(or \
- $(file_missing),\
- $(call cmdline_changed,$(O_TO_C_STR)),\
- $(depfile_missing),\
- $(depfile_newer)),\
- $(O_TO_C_DO))
-endif
else
$(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
@[ -d $(dir $@) ] || mkdir -p $(dir $@)
@@ -153,14 +126,6 @@ $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
$(depfile_missing),\
$(depfile_newer)),\
$(O_TO_A_DO))
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
- $(if $(or \
- $(file_missing),\
- $(call cmdline_changed,$(O_TO_C_STR)),\
- $(depfile_missing),\
- $(depfile_newer)),\
- $(O_TO_C_DO))
-endif
endif
#
@@ -93,9 +93,6 @@ $(ROOTDIRS-y):
@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
- @if [ $@ = lib -a $(RTE_BUILD_COMBINE_LIBS) = y ]; then \
- $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
- fi
%_clean:
@echo "== Clean $*"
deleted file mode 100644
@@ -1,101 +0,0 @@
-# BSD LICENSE
-#
-# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-# All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions
-# are met:
-#
-# * Redistributions of source code must retain the above copyright
-# notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-# notice, this list of conditions and the following disclaimer in
-# the documentation and/or other materials provided with the
-# distribution.
-# * Neither the name of Intel Corporation nor the names of its
-# contributors may be used to endorse or promote products derived
-# from this software without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-include $(RTE_SDK)/mk/internal/rte.build-pre.mk
-
-# VPATH contains at least SRCDIR
-VPATH += $(SRCDIR)
-
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(RTE_BUILD_SHARED_LIB),y)
-LIB_ONE := lib$(RTE_LIBNAME).so
-else
-LIB_ONE := lib$(RTE_LIBNAME).a
-endif
-endif
-
-.PHONY:sharelib
-sharelib: $(LIB_ONE) FORCE
-
-OBJS = $(wildcard $(RTE_OUTPUT)/build/lib/*.o)
-
-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)
-else
-O_TO_S = $(LD) $(CPU_LDFLAGS) \
- -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE)
-endif
-
-O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight
-O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)"," LD $(@)")
-O_TO_S_CMD = "cmd_$@ = $(O_TO_S_STR)"
-O_TO_S_DO = @set -e; \
- echo $(O_TO_S_DISP); \
- $(O_TO_S)
-
-O_TO_A = $(AR) crus $(RTE_OUTPUT)/lib/$(LIB_ONE) $(OBJS)
-O_TO_A_STR = $(subst ','\'',$(O_TO_A)) #'# fix syntax highlight
-O_TO_A_DISP = $(if $(V),"$(O_TO_A_STR)"," LD $(@)")
-O_TO_A_CMD = "cmd_$@ = $(O_TO_A_STR)"
-O_TO_A_DO = @set -e; \
- echo $(O_TO_A_DISP); \
- $(O_TO_A)
-#
-# Archive objects to share library
-#
-
-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(RTE_BUILD_SHARED_LIB),y)
-$(LIB_ONE): FORCE
- @[ -d $(dir $@) ] || mkdir -p $(dir $@)
- $(O_TO_S_DO)
-else
-$(LIB_ONE): FORCE
- @[ -d $(dir $@) ] || mkdir -p $(dir $@)
- $(O_TO_A_DO)
-endif
-endif
-
-#
-# Clean all generated files
-#
-.PHONY: clean
-clean: _postclean
-
-.PHONY: doclean
-doclean:
- $(Q)rm -rf $(LIB_ONE)
-
-.PHONY: FORCE
-FORCE:
@@ -67,10 +67,6 @@ ifneq ($(BUILDING_RTE_SDK),)
ifeq ($(RTE_BUILD_SHARED_LIB),)
RTE_BUILD_SHARED_LIB := n
endif
- RTE_BUILD_COMBINE_LIBS := $(CONFIG_RTE_BUILD_COMBINE_LIBS:"%"=%)
- ifeq ($(RTE_BUILD_COMBINE_LIBS),)
- RTE_BUILD_COMBINE_LIBS := n
- endif
endif
RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)