[dpdk-dev] mk: fix the combined library problems by replacing it with a linker script
Commit Message
The physically linked-together combined library has been an increasing
source of problems, as was predicted when library and symbol versioning
was introduced. Replace the complex and fragile construction with a
simple linker script which achieves the same without all the problems,
remove the related kludges from eg mlx drivers.
Since creating the linker script is practically zero cost, remove the
config option and just create it always.
Based on a patch by Sergio Gonzales Monroy, linker script approach
initially suggested by Neil Horman.
Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Suggested-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
---
config/common_bsdapp | 5 ---
config/common_linuxapp | 5 ---
drivers/net/Makefile | 1 -
drivers/net/mlx4/Makefile | 6 ---
drivers/net/mlx5/Makefile | 6 ---
lib/Makefile | 1 -
mk/rte.app.mk | 10 -----
mk/rte.combinedlib.mk | 57 ++++++++++++++++++++++++++
mk/rte.lib.mk | 16 --------
mk/rte.sdkbuild.mk | 4 +-
mk/rte.sharelib.mk | 101 ----------------------------------------------
11 files changed, 59 insertions(+), 153 deletions(-)
create mode 100644 mk/rte.combinedlib.mk
delete mode 100644 mk/rte.sharelib.mk
Comments
On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
> The physically linked-together combined library has been an increasing
> source of problems, as was predicted when library and symbol versioning
> was introduced. Replace the complex and fragile construction with a
> simple linker script which achieves the same without all the problems,
> remove the related kludges from eg mlx drivers.
>
> Since creating the linker script is practically zero cost, remove the
> config option and just create it always.
>
> Based on a patch by Sergio Gonzales Monroy, linker script approach
> initially suggested by Neil Horman.
>
> Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> Suggested-by: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Nice work
Neil Horman <nhorman@tuxdriver.com> writes:
> On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
>> The physically linked-together combined library has been an increasing
>> source of problems, as was predicted when library and symbol versioning
>> was introduced. Replace the complex and fragile construction with a
>> simple linker script which achieves the same without all the problems,
>> remove the related kludges from eg mlx drivers.
>>
>> Since creating the linker script is practically zero cost, remove the
>> config option and just create it always.
>>
>> Based on a patch by Sergio Gonzales Monroy, linker script approach
>> initially suggested by Neil Horman.
>>
>> Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
>> Suggested-by: Neil Horman <nhorman@tuxdriver.com>
>> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
> Nice work
+1, and just for good measure:
Acked-by: Aaron Conole <aconole@redhat.com>
On Tue, 24 Nov 2015 16:31:17 +0200
Panu Matilainen <pmatilai@redhat.com> wrote:
> The physically linked-together combined library has been an increasing
> source of problems, as was predicted when library and symbol versioning
> was introduced. Replace the complex and fragile construction with a
> simple linker script which achieves the same without all the problems,
> remove the related kludges from eg mlx drivers.
>
> Since creating the linker script is practically zero cost, remove the
> config option and just create it always.
>
> Based on a patch by Sergio Gonzales Monroy, linker script approach
> initially suggested by Neil Horman.
>
> Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> Suggested-by: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
But it now means distros have to ship 20 libraries which seems like
a step back.
On 11/25/2015 12:46 AM, Stephen Hemminger wrote:
> On Tue, 24 Nov 2015 16:31:17 +0200
> Panu Matilainen <pmatilai@redhat.com> wrote:
>
>> The physically linked-together combined library has been an increasing
>> source of problems, as was predicted when library and symbol versioning
>> was introduced. Replace the complex and fragile construction with a
>> simple linker script which achieves the same without all the problems,
>> remove the related kludges from eg mlx drivers.
>>
>> Since creating the linker script is practically zero cost, remove the
>> config option and just create it always.
>>
>> Based on a patch by Sergio Gonzales Monroy, linker script approach
>> initially suggested by Neil Horman.
>>
>> Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
>> Suggested-by: Neil Horman <nhorman@tuxdriver.com>
>> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
>
> But it now means distros have to ship 20 libraries which seems like
> a step back.
That's how Fedora and RHEL are shipping it already and nobody has so
much as noticed anything strange, much less complained about it. 20
libraries is but a drop in the ocean on a average distro. But more to
the point, distros will prefer 50 working libraries over one that doesn't.
The combined library as it is simply is no longer a viable option.
Besides just being broken (witness the strange hacks people are coming
up with to work around issues in it) its ugly because it basically gives
the middle finger to all the effort going into version compatibility,
and its also big. Few projects will use every library in DPDK, but with
the combined library they're forced to lug the 800 pound gorilla along
needlessly.
- Panu -
On Wed, Nov 25, 2015 at 10:38:48AM +0200, Panu Matilainen wrote:
> On 11/25/2015 12:46 AM, Stephen Hemminger wrote:
> >On Tue, 24 Nov 2015 16:31:17 +0200
> >Panu Matilainen <pmatilai@redhat.com> wrote:
> >
> >>The physically linked-together combined library has been an increasing
> >>source of problems, as was predicted when library and symbol versioning
> >>was introduced. Replace the complex and fragile construction with a
> >>simple linker script which achieves the same without all the problems,
> >>remove the related kludges from eg mlx drivers.
> >>
> >>Since creating the linker script is practically zero cost, remove the
> >>config option and just create it always.
> >>
> >>Based on a patch by Sergio Gonzales Monroy, linker script approach
> >>initially suggested by Neil Horman.
> >>
> >>Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> >>Suggested-by: Neil Horman <nhorman@tuxdriver.com>
> >>Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> >
> >But it now means distros have to ship 20 libraries which seems like
> >a step back.
>
> That's how Fedora and RHEL are shipping it already and nobody has so much as
> noticed anything strange, much less complained about it. 20 libraries is but
> a drop in the ocean on a average distro. But more to the point, distros will
> prefer 50 working libraries over one that doesn't.
>
> The combined library as it is simply is no longer a viable option. Besides
> just being broken (witness the strange hacks people are coming up with to
> work around issues in it) its ugly because it basically gives the middle
> finger to all the effort going into version compatibility, and its also big.
> Few projects will use every library in DPDK, but with the combined library
> they're forced to lug the 800 pound gorilla along needlessly.
>
Agreed, This solves a ton of problems, and from a distro standpoint, no one
really cares how many libraries it is under the covers. Its all just one
rpm/deb package anyway.
Neil
On Wed, 25 Nov 2015 10:38:48 +0200
Panu Matilainen <pmatilai@redhat.com> wrote:
> On 11/25/2015 12:46 AM, Stephen Hemminger wrote:
> > On Tue, 24 Nov 2015 16:31:17 +0200
> > Panu Matilainen <pmatilai@redhat.com> wrote:
> >
> >> The physically linked-together combined library has been an increasing
> >> source of problems, as was predicted when library and symbol versioning
> >> was introduced. Replace the complex and fragile construction with a
> >> simple linker script which achieves the same without all the problems,
> >> remove the related kludges from eg mlx drivers.
> >>
> >> Since creating the linker script is practically zero cost, remove the
> >> config option and just create it always.
> >>
> >> Based on a patch by Sergio Gonzales Monroy, linker script approach
> >> initially suggested by Neil Horman.
> >>
> >> Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> >> Suggested-by: Neil Horman <nhorman@tuxdriver.com>
> >> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> >
> > But it now means distros have to ship 20 libraries which seems like
> > a step back.
>
> That's how Fedora and RHEL are shipping it already and nobody has so
> much as noticed anything strange, much less complained about it. 20
> libraries is but a drop in the ocean on a average distro. But more to
> the point, distros will prefer 50 working libraries over one that doesn't.
>
> The combined library as it is simply is no longer a viable option.
> Besides just being broken (witness the strange hacks people are coming
> up with to work around issues in it) its ugly because it basically gives
> the middle finger to all the effort going into version compatibility,
> and its also big. Few projects will use every library in DPDK, but with
> the combined library they're forced to lug the 800 pound gorilla along
> needlessly.
>
> - Panu -
>
Fixing the combined library took less than an hour for us.
On 11/25/2015 06:08 PM, Stephen Hemminger wrote:
> On Wed, 25 Nov 2015 10:38:48 +0200
> Panu Matilainen <pmatilai@redhat.com> wrote:
>
>> On 11/25/2015 12:46 AM, Stephen Hemminger wrote:
>>> On Tue, 24 Nov 2015 16:31:17 +0200
>>> Panu Matilainen <pmatilai@redhat.com> wrote:
>>>
>>>> The physically linked-together combined library has been an increasing
>>>> source of problems, as was predicted when library and symbol versioning
>>>> was introduced. Replace the complex and fragile construction with a
>>>> simple linker script which achieves the same without all the problems,
>>>> remove the related kludges from eg mlx drivers.
>>>>
>>>> Since creating the linker script is practically zero cost, remove the
>>>> config option and just create it always.
>>>>
>>>> Based on a patch by Sergio Gonzales Monroy, linker script approach
>>>> initially suggested by Neil Horman.
>>>>
>>>> Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
>>>> Suggested-by: Neil Horman <nhorman@tuxdriver.com>
>>>> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
>>>
>>> But it now means distros have to ship 20 libraries which seems like
>>> a step back.
>>
>> That's how Fedora and RHEL are shipping it already and nobody has so
>> much as noticed anything strange, much less complained about it. 20
>> libraries is but a drop in the ocean on a average distro. But more to
>> the point, distros will prefer 50 working libraries over one that doesn't.
>>
>> The combined library as it is simply is no longer a viable option.
>> Besides just being broken (witness the strange hacks people are coming
>> up with to work around issues in it) its ugly because it basically gives
>> the middle finger to all the effort going into version compatibility,
>> and its also big. Few projects will use every library in DPDK, but with
>> the combined library they're forced to lug the 800 pound gorilla along
>> needlessly.
>>
>> - Panu -
>>
>
> Fixing the combined library took less than an hour for us.
>
An hour (and many more in times to come) that I bet you could've used on
something more interesting than fighting that abomination.
- Panu -
On Wed, Nov 25, 2015 at 08:08:37AM -0800, Stephen Hemminger wrote:
> On Wed, 25 Nov 2015 10:38:48 +0200
> Panu Matilainen <pmatilai@redhat.com> wrote:
>
> > On 11/25/2015 12:46 AM, Stephen Hemminger wrote:
> > > On Tue, 24 Nov 2015 16:31:17 +0200
> > > Panu Matilainen <pmatilai@redhat.com> wrote:
> > >
> > >> The physically linked-together combined library has been an increasing
> > >> source of problems, as was predicted when library and symbol versioning
> > >> was introduced. Replace the complex and fragile construction with a
> > >> simple linker script which achieves the same without all the problems,
> > >> remove the related kludges from eg mlx drivers.
> > >>
> > >> Since creating the linker script is practically zero cost, remove the
> > >> config option and just create it always.
> > >>
> > >> Based on a patch by Sergio Gonzales Monroy, linker script approach
> > >> initially suggested by Neil Horman.
> > >>
> > >> Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> > >> Suggested-by: Neil Horman <nhorman@tuxdriver.com>
> > >> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> > >
> > > But it now means distros have to ship 20 libraries which seems like
> > > a step back.
> >
> > That's how Fedora and RHEL are shipping it already and nobody has so
> > much as noticed anything strange, much less complained about it. 20
> > libraries is but a drop in the ocean on a average distro. But more to
> > the point, distros will prefer 50 working libraries over one that doesn't.
> >
> > The combined library as it is simply is no longer a viable option.
> > Besides just being broken (witness the strange hacks people are coming
> > up with to work around issues in it) its ugly because it basically gives
> > the middle finger to all the effort going into version compatibility,
> > and its also big. Few projects will use every library in DPDK, but with
> > the combined library they're forced to lug the 800 pound gorilla along
> > needlessly.
> >
> > - Panu -
> >
>
> Fixing the combined library took less than an hour for us.
How did you fix the versioning issue?
Neil
Re-sending this unsigned since the ML rejected my signed email.
-1 from Ubuntu without further discussion since it will break us. Please
don't commit this patch yet.
I don't understand why we must have the complexity of so many shared
libraries. From a distribution packaging perspective, all I see is that
this multiplies potential work by twenty times and makes it awkward to
work with without special tooling (which then needs maintaining).
Before I go into details, it would be nice if someone could please
explain why DPDK has to be "special" in needing to do this? I don't
understand why DPDK must be different to every other userspace library
out there. If DPDK has a good need to be different then that's fair
enough. But I feel that if DPDK is deviating from the norm then we need
to frame the discussion from the perspective of "why DPDK must be
different", rather than having me trying to explain why the norm is the
right way to do it.
On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
> That's how Fedora and RHEL are shipping it already and nobody has so much
> as noticed anything strange, much less complained about it. 20 libraries
> is but a drop in the ocean on a average distro.
No, it is 20 times the work from the perspective of DPDK package
maintenance. Let me explain why.
In Debian and Ubuntu, we manage a library transition (an ABI bump in a
library together with all dependencies moving to use the new ABI) by
concurrently packaging both the old and new libraries at once. This
works well with the norm for libraries. We ship one binary package per
soname, with the major version as part of the package name. This allows
a system to have two (or more) ABIs installed simultaneously. For a
library transition, we just package the new version and then that can
land and work concurrently as we then individually update every
dependent (library-consuming) package.
This works because of conventions around sonames, which DPDK breaks
unless we treat it as twenty different libraries which changes our work
from easy to painful.
Usually a library transition is managed by hand by the package
maintainer. It's not taxing because it's straightforward and well
understood. Update and upload the new ABI source package, then find all
reverse dependencies and sort them out, recursively. But if the
maintainer must do it twenty times, then it becomes taxing and prone to
error. And if the reverse dependency tree differs depending on the split
library used by library consumers, then it gets far more complex to
follow.
Admittedly we could tool around this to make it easier, but that's extra
work (both initially and in maintenance) and prone to error (because
we'd only be doing it for DPDK).
Packaging a library is usually virtually a no-op in Debian and Ubuntu
nowadays. Our tooling does it all for us. But packaging DPDK is far from
this currently because of all this added complexity. From my perspective
this is unnecessary and makes no sense. We could do all kinds of things
to work around it (that's what packaging is about) but then we'd have to
maintain that specialness and I don't see why it must be awkward like
this instead of just doing it the same way as every other library.
> The combined library as it is simply is no longer a viable option.
> Besides just being broken (witness the strange hacks people are coming
> up with to work around issues in it) its ugly because it basically gives
> the middle finger to all the effort going into version compatibility,
> and its also big. Few projects will use every library in DPDK, but with
> the combined library they're forced to lug the 800 pound gorilla along
> needlessly.
It's broken because it's broken upstream, and that's what we should fix.
Why is it not viable? How does it give the middle finger to effort going
into version compatibility? Doing it the right way like every other
userspace library is what *gives us* version compatibility because then
distributions can straightforwardly install multiple ABI versions at
once.
Finally, I fail to see any "lug the 800 pound gorilla along" saving. We
(Ubuntu and Fedora) are both shipping all the libraries in one package,
whether split or combined, so they are all being lugged onto disk
anyway. Whether split or combined, there is no saving there. And memory
is hardly saved either because the kernel will just page in and out what
is needed in both cases. So how does this proposed change give us any
saving at all?
If distributions are expected to ship everything lumped together on one
package, then we don't get any benefit of having the library split up.
I did bring this up on this list[1] and my understanding of the outcome
then was that it would be fine for us to use the combined library, and
in time we could better define its ABI. Thus I'm not happy that you're
proposing to change tack on this, both because I'm far from convinced
it's a good idea for the project and wider ecosystem and also because it
creates more work for us.
I understand that in the embedded world you might want to build a subset
of the split libraries, and I'm not suggesting that we take away this
ability if there users who want it (though in that scenario I think
static builds probably make more sense). But in the distribution world,
for binaries we ship, I'd prefer to see things work the standard way
with standard tooling and nothing special going on when there is no need
for it.
Please can you explain why having a combined library is so much of a
problem?
Thanks,
Robie
[1] Message-ID: <20150902134900.GO467@mal.justgohome.co.uk>
Archive: http://dpdk.org/ml/archives/dev/2015-September/023180.html
On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote:
> Re-sending this unsigned since the ML rejected my signed email.
>
> -1 from Ubuntu without further discussion since it will break us. Please
> don't commit this patch yet.
>
> I don't understand why we must have the complexity of so many shared
> libraries. From a distribution packaging perspective, all I see is that
> this multiplies potential work by twenty times and makes it awkward to
> work with without special tooling (which then needs maintaining).
>
Theres nothing "complex" about the simple fact that a project builds lots of
libraries. Its extreemely common. Any graphic window manager has exactly the
same situation, as do any number of tools that have multiple hardware backends
impelmented in user space (v4l, sane, iptables, to name just a few).
> Before I go into details, it would be nice if someone could please
> explain why DPDK has to be "special" in needing to do this? I don't
Its not special, see above. Not saying the build environment cant be improved,
but the fact that there are multiple libraries is pretty straightforward.
> understand why DPDK must be different to every other userspace library
> out there. If DPDK has a good need to be different then that's fair
> enough. But I feel that if DPDK is deviating from the norm then we need
> to frame the discussion from the perspective of "why DPDK must be
> different", rather than having me trying to explain why the norm is the
> right way to do it.
>
> On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
> > That's how Fedora and RHEL are shipping it already and nobody has so much
> > as noticed anything strange, much less complained about it. 20 libraries
> > is but a drop in the ocean on a average distro.
>
> No, it is 20 times the work from the perspective of DPDK package
> maintenance. Let me explain why.
>
> In Debian and Ubuntu, we manage a library transition (an ABI bump in a
> library together with all dependencies moving to use the new ABI) by
> concurrently packaging both the old and new libraries at once. This
> works well with the norm for libraries. We ship one binary package per
> soname, with the major version as part of the package name. This allows
> a system to have two (or more) ABIs installed simultaneously. For a
> library transition, we just package the new version and then that can
> land and work concurrently as we then individually update every
> dependent (library-consuming) package.
So thats, a distribution choice, not an upstream problem. And it seems like a
problem you should have already solved (note the examples above). If you feel
like you need to package multiple ABI versions in the same library, you can,
just update the LIBABIVER of all the libraries, instead of the ones that truly
change, so that each library is guaranteed a newer so version, to make the
library file name unique. Yes you have to make a small change from upstream,
but thats part of the work that distribution maintainers do.
> This works because of conventions around sonames, which DPDK breaks
> unless we treat it as twenty different libraries which changes our work
> from easy to painful.
>
> Usually a library transition is managed by hand by the package
> maintainer. It's not taxing because it's straightforward and well
> understood. Update and upload the new ABI source package, then find all
> reverse dependencies and sort them out, recursively. But if the
> maintainer must do it twenty times, then it becomes taxing and prone to
> error. And if the reverse dependency tree differs depending on the split
> library used by library consumers, then it gets far more complex to
> follow.
>
> Admittedly we could tool around this to make it easier, but that's extra
> work (both initially and in maintenance) and prone to error (because
> we'd only be doing it for DPDK).
>
You must already have a solution to this, I can't imagine you package all the
libraries for kde or gnome (or even pam) separately)
> Packaging a library is usually virtually a no-op in Debian and Ubuntu
> nowadays. Our tooling does it all for us. But packaging DPDK is far from
> this currently because of all this added complexity. From my perspective
> this is unnecessary and makes no sense. We could do all kinds of things
> to work around it (that's what packaging is about) but then we'd have to
> maintain that specialness and I don't see why it must be awkward like
> this instead of just doing it the same way as every other library.
>
> > The combined library as it is simply is no longer a viable option.
> > Besides just being broken (witness the strange hacks people are coming
> > up with to work around issues in it) its ugly because it basically gives
> > the middle finger to all the effort going into version compatibility,
> > and its also big. Few projects will use every library in DPDK, but with
> > the combined library they're forced to lug the 800 pound gorilla along
> > needlessly.
>
> It's broken because it's broken upstream, and that's what we should fix.
> Why is it not viable? How does it give the middle finger to effort going
> into version compatibility?
Because each individual library has a version script that gets applied during
link to version symbols properly. Those scripts dont get applied when building
the combined library.
> Doing it the right way like every other
> userspace library is what *gives us* version compatibility because then
> distributions can straightforwardly install multiple ABI versions at
> once.
Again, Not at all uncommon. You're packaging methodology is the issue here,
not the fact that there are multiple libraries.
> Finally, I fail to see any "lug the 800 pound gorilla along" saving. We
> (Ubuntu and Fedora) are both shipping all the libraries in one package,
> whether split or combined, so they are all being lugged onto disk
> anyway. Whether split or combined, there is no saving there. And memory
> is hardly saved either because the kernel will just page in and out what
> is needed in both cases. So how does this proposed change give us any
> saving at all?
>
Not true, initalization constructors for PMD's at the very least mean that every
pmd will get paged in weather you want it or not using the combined library.
Individual libraries let you dynamically load them (via dlopen). I think the
same is true of several other facets of dpdk.
Neil
Hi Ferruh,
while not tackling the "soname for combined lib" which I felt to be
the center of all this discussion.
I like that with your patch the symbols in the combined lib are no
more anonymous, but versioned according to the maps the DPDK sub
libraries are maintaining anyway.
Some more technical feedback on your post.
I wonder if we would find a similar solution for the overall soname version.
Unfortunately all naive approaches that came to my mind so far
(summing up LIBABIVER, biggest of LIBABIVER, ...) all have all too
obvious faults.
And I didn't have time for a complex one yet.
I feel that - in favor of non-perfect, but simple solution - it might
be easier to carry one global LIBABIVER for the combined lib that is
increased on each DPDK release IF (very likely) one of the ABIs was
changed in the Release.
Something like a LIBABISUBVER could be increased on any release that
did change, but not break the old ABI.
Well, likely still too naive - I need more time to really get into all
that - like to better understand all the benefits and drawbacks of the
linker script approach.
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Thu, Dec 3, 2015 at 2:31 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote:
>> On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote:
>> > Re-sending this unsigned since the ML rejected my signed email.
>> >
>> > -1 from Ubuntu without further discussion since it will break us. Please
>> > don't commit this patch yet.
>> >
>> > I don't understand why we must have the complexity of so many shared
>> > libraries. From a distribution packaging perspective, all I see is that
>> > this multiplies potential work by twenty times and makes it awkward to
>> > work with without special tooling (which then needs maintaining).
>> >
>> Theres nothing "complex" about the simple fact that a project builds lots of
>> libraries. Its extreemely common. Any graphic window manager has exactly the
>> same situation, as do any number of tools that have multiple hardware backends
>> impelmented in user space (v4l, sane, iptables, to name just a few).
>>
>> > Before I go into details, it would be nice if someone could please
>> > explain why DPDK has to be "special" in needing to do this? I don't
>> Its not special, see above. Not saying the build environment cant be improved,
>> but the fact that there are multiple libraries is pretty straightforward.
>>
>> > understand why DPDK must be different to every other userspace library
>> > out there. If DPDK has a good need to be different then that's fair
>> > enough. But I feel that if DPDK is deviating from the norm then we need
>> > to frame the discussion from the perspective of "why DPDK must be
>> > different", rather than having me trying to explain why the norm is the
>> > right way to do it.
>> >
>> > On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
>> > > That's how Fedora and RHEL are shipping it already and nobody has so much
>> > > as noticed anything strange, much less complained about it. 20 libraries
>> > > is but a drop in the ocean on a average distro.
>> >
>> > No, it is 20 times the work from the perspective of DPDK package
>> > maintenance. Let me explain why.
>> >
>> > In Debian and Ubuntu, we manage a library transition (an ABI bump in a
>> > library together with all dependencies moving to use the new ABI) by
>> > concurrently packaging both the old and new libraries at once. This
>> > works well with the norm for libraries. We ship one binary package per
>> > soname, with the major version as part of the package name. This allows
>> > a system to have two (or more) ABIs installed simultaneously. For a
>> > library transition, we just package the new version and then that can
>> > land and work concurrently as we then individually update every
>> > dependent (library-consuming) package.
>> So thats, a distribution choice, not an upstream problem. And it seems like a
>> problem you should have already solved (note the examples above). If you feel
>> like you need to package multiple ABI versions in the same library, you can,
>> just update the LIBABIVER of all the libraries, instead of the ones that truly
>> change, so that each library is guaranteed a newer so version, to make the
>> library file name unique. Yes you have to make a small change from upstream,
>> but thats part of the work that distribution maintainers do.
>>
>>
>> > This works because of conventions around sonames, which DPDK breaks
>> > unless we treat it as twenty different libraries which changes our work
>> > from easy to painful.
>> >
>> > Usually a library transition is managed by hand by the package
>> > maintainer. It's not taxing because it's straightforward and well
>> > understood. Update and upload the new ABI source package, then find all
>> > reverse dependencies and sort them out, recursively. But if the
>> > maintainer must do it twenty times, then it becomes taxing and prone to
>> > error. And if the reverse dependency tree differs depending on the split
>> > library used by library consumers, then it gets far more complex to
>> > follow.
>> >
>> > Admittedly we could tool around this to make it easier, but that's extra
>> > work (both initially and in maintenance) and prone to error (because
>> > we'd only be doing it for DPDK).
>> >
>> You must already have a solution to this, I can't imagine you package all the
>> libraries for kde or gnome (or even pam) separately)
>>
>> > Packaging a library is usually virtually a no-op in Debian and Ubuntu
>> > nowadays. Our tooling does it all for us. But packaging DPDK is far from
>> > this currently because of all this added complexity. From my perspective
>> > this is unnecessary and makes no sense. We could do all kinds of things
>> > to work around it (that's what packaging is about) but then we'd have to
>> > maintain that specialness and I don't see why it must be awkward like
>> > this instead of just doing it the same way as every other library.
>> >
>> > > The combined library as it is simply is no longer a viable option.
>> > > Besides just being broken (witness the strange hacks people are coming
>> > > up with to work around issues in it) its ugly because it basically gives
>> > > the middle finger to all the effort going into version compatibility,
>> > > and its also big. Few projects will use every library in DPDK, but with
>> > > the combined library they're forced to lug the 800 pound gorilla along
>> > > needlessly.
>> >
>> > It's broken because it's broken upstream, and that's what we should fix.
>> > Why is it not viable? How does it give the middle finger to effort going
>> > into version compatibility?
>> Because each individual library has a version script that gets applied during
>> link to version symbols properly. Those scripts dont get applied when building
>> the combined library.
>>
>>
>> > Doing it the right way like every other
>> > userspace library is what *gives us* version compatibility because then
>> > distributions can straightforwardly install multiple ABI versions at
>> > once.
>> Again, Not at all uncommon. You're packaging methodology is the issue here,
>> not the fact that there are multiple libraries.
>>
>> > Finally, I fail to see any "lug the 800 pound gorilla along" saving. We
>> > (Ubuntu and Fedora) are both shipping all the libraries in one package,
>> > whether split or combined, so they are all being lugged onto disk
>> > anyway. Whether split or combined, there is no saving there. And memory
>> > is hardly saved either because the kernel will just page in and out what
>> > is needed in both cases. So how does this proposed change give us any
>> > saving at all?
>> >
>> Not true, initalization constructors for PMD's at the very least mean that every
>> pmd will get paged in weather you want it or not using the combined library.
>> Individual libraries let you dynamically load them (via dlopen). I think the
>> same is true of several other facets of dpdk.
>>
>> Neil
>>
> I just sent a patch that fixes versioning in combined library, can you please check it: http://dpdk.org/dev/patchwork/patch/9259/
>
> Thanks,
> ferruh
>
On Thu, Dec 03, 2015 at 01:31:33AM +0000, Ferruh Yigit wrote:
> On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote:
> > On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote:
> > > Re-sending this unsigned since the ML rejected my signed email.
> > >
> > > -1 from Ubuntu without further discussion since it will break us. Please
> > > don't commit this patch yet.
> > >
> > > I don't understand why we must have the complexity of so many shared
> > > libraries. From a distribution packaging perspective, all I see is that
> > > this multiplies potential work by twenty times and makes it awkward to
> > > work with without special tooling (which then needs maintaining).
> > >
> > Theres nothing "complex" about the simple fact that a project builds lots of
> > libraries. Its extreemely common. Any graphic window manager has exactly the
> > same situation, as do any number of tools that have multiple hardware backends
> > impelmented in user space (v4l, sane, iptables, to name just a few).
> >
> > > Before I go into details, it would be nice if someone could please
> > > explain why DPDK has to be "special" in needing to do this? I don't
> > Its not special, see above. Not saying the build environment cant be improved,
> > but the fact that there are multiple libraries is pretty straightforward.
> >
> > > understand why DPDK must be different to every other userspace library
> > > out there. If DPDK has a good need to be different then that's fair
> > > enough. But I feel that if DPDK is deviating from the norm then we need
> > > to frame the discussion from the perspective of "why DPDK must be
> > > different", rather than having me trying to explain why the norm is the
> > > right way to do it.
> > >
> > > On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote:
> > > > That's how Fedora and RHEL are shipping it already and nobody has so much
> > > > as noticed anything strange, much less complained about it. 20 libraries
> > > > is but a drop in the ocean on a average distro.
> > >
> > > No, it is 20 times the work from the perspective of DPDK package
> > > maintenance. Let me explain why.
> > >
> > > In Debian and Ubuntu, we manage a library transition (an ABI bump in a
> > > library together with all dependencies moving to use the new ABI) by
> > > concurrently packaging both the old and new libraries at once. This
> > > works well with the norm for libraries. We ship one binary package per
> > > soname, with the major version as part of the package name. This allows
> > > a system to have two (or more) ABIs installed simultaneously. For a
> > > library transition, we just package the new version and then that can
> > > land and work concurrently as we then individually update every
> > > dependent (library-consuming) package.
> > So thats, a distribution choice, not an upstream problem. And it seems like a
> > problem you should have already solved (note the examples above). If you feel
> > like you need to package multiple ABI versions in the same library, you can,
> > just update the LIBABIVER of all the libraries, instead of the ones that truly
> > change, so that each library is guaranteed a newer so version, to make the
> > library file name unique. Yes you have to make a small change from upstream,
> > but thats part of the work that distribution maintainers do.
> >
> >
> > > This works because of conventions around sonames, which DPDK breaks
> > > unless we treat it as twenty different libraries which changes our work
> > > from easy to painful.
> > >
> > > Usually a library transition is managed by hand by the package
> > > maintainer. It's not taxing because it's straightforward and well
> > > understood. Update and upload the new ABI source package, then find all
> > > reverse dependencies and sort them out, recursively. But if the
> > > maintainer must do it twenty times, then it becomes taxing and prone to
> > > error. And if the reverse dependency tree differs depending on the split
> > > library used by library consumers, then it gets far more complex to
> > > follow.
> > >
> > > Admittedly we could tool around this to make it easier, but that's extra
> > > work (both initially and in maintenance) and prone to error (because
> > > we'd only be doing it for DPDK).
> > >
> > You must already have a solution to this, I can't imagine you package all the
> > libraries for kde or gnome (or even pam) separately)
> >
> > > Packaging a library is usually virtually a no-op in Debian and Ubuntu
> > > nowadays. Our tooling does it all for us. But packaging DPDK is far from
> > > this currently because of all this added complexity. From my perspective
> > > this is unnecessary and makes no sense. We could do all kinds of things
> > > to work around it (that's what packaging is about) but then we'd have to
> > > maintain that specialness and I don't see why it must be awkward like
> > > this instead of just doing it the same way as every other library.
> > >
> > > > The combined library as it is simply is no longer a viable option.
> > > > Besides just being broken (witness the strange hacks people are coming
> > > > up with to work around issues in it) its ugly because it basically gives
> > > > the middle finger to all the effort going into version compatibility,
> > > > and its also big. Few projects will use every library in DPDK, but with
> > > > the combined library they're forced to lug the 800 pound gorilla along
> > > > needlessly.
> > >
> > > It's broken because it's broken upstream, and that's what we should fix.
> > > Why is it not viable? How does it give the middle finger to effort going
> > > into version compatibility?
> > Because each individual library has a version script that gets applied during
> > link to version symbols properly. Those scripts dont get applied when building
> > the combined library.
> >
> >
> > > Doing it the right way like every other
> > > userspace library is what *gives us* version compatibility because then
> > > distributions can straightforwardly install multiple ABI versions at
> > > once.
> > Again, Not at all uncommon. You're packaging methodology is the issue here,
> > not the fact that there are multiple libraries.
> >
> > > Finally, I fail to see any "lug the 800 pound gorilla along" saving. We
> > > (Ubuntu and Fedora) are both shipping all the libraries in one package,
> > > whether split or combined, so they are all being lugged onto disk
> > > anyway. Whether split or combined, there is no saving there. And memory
> > > is hardly saved either because the kernel will just page in and out what
> > > is needed in both cases. So how does this proposed change give us any
> > > saving at all?
> > >
> > Not true, initalization constructors for PMD's at the very least mean that every
> > pmd will get paged in weather you want it or not using the combined library.
> > Individual libraries let you dynamically load them (via dlopen). I think the
> > same is true of several other facets of dpdk.
> >
> > Neil
> >
> I just sent a patch that fixes versioning in combined library, can you please check it: http://dpdk.org/dev/patchwork/patch/9259/
>
> Thanks,
> ferruh
>
>
I've seen the patch, and I appreciate the effort, but it really seems to me like
more of the same. That is to say, its a good effort but it really creates
additional ifrastructure to allow a single library to be built, but the fact of
the matter is, a single library isn't needed. The build system is setup to
crate multiple libraries, and a linker scripts allows for the combined library
functionality, without adding additional clutter to the Makefiles. The argument
that its more work to support multiple libraries in some distributions simply
doesn't ring true with me, because that must be a problem which is already
solved for other popular projects which are architected in a simmilar fashion.
Regards
Neil
2015-11-24 16:31, Panu Matilainen:
> The physically linked-together combined library has been an increasing
> source of problems, as was predicted when library and symbol versioning
> was introduced. Replace the complex and fragile construction with a
> simple linker script which achieves the same without all the problems,
> remove the related kludges from eg mlx drivers.
>
> Since creating the linker script is practically zero cost, remove the
> config option and just create it always.
>
> Based on a patch by Sergio Gonzales Monroy, linker script approach
> initially suggested by Neil Horman.
>
> Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> Suggested-by: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
As it is a big change and discussion is not totally closed,
it is deferred to release 2.3.
The fix from Ferruh could be sufficient for 2.2.
Hi,
FYI I kind of "gave up" (not as bad as it sounds) and started looking into
shipping it as individual libraries + linker script as well.
To me it seemed what was more accepted in all the former discussions.
It will surely cause more work for me in the short term, but I hope after
the initial hill I have to climb to make it happen it will be not too much
in future releases.
So if "we" were the only one causing this to be deferred consider it for
2.2.
That way distributions would become more similar which might help consumers
of the DPDK libraries.
In the worst case I can reverse apply it for 2.2 to get some more time to
get it to work properly for us later on.
Looking at the great changes to "make install" by Thomas being in 2.2 -
getting the linker script "official" in 2.2 as well would also help to not
get a major overhaul to packaging every version :-)
have a great week,
Christian
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Fri, Dec 4, 2015 at 6:19 PM, Thomas Monjalon <thomas.monjalon@6wind.com>
wrote:
> 2015-11-24 16:31, Panu Matilainen:
> > The physically linked-together combined library has been an increasing
> > source of problems, as was predicted when library and symbol versioning
> > was introduced. Replace the complex and fragile construction with a
> > simple linker script which achieves the same without all the problems,
> > remove the related kludges from eg mlx drivers.
> >
> > Since creating the linker script is practically zero cost, remove the
> > config option and just create it always.
> >
> > Based on a patch by Sergio Gonzales Monroy, linker script approach
> > initially suggested by Neil Horman.
> >
> > Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
> > Suggested-by: Neil Horman <nhorman@tuxdriver.com>
> > Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
>
> As it is a big change and discussion is not totally closed,
> it is deferred to release 2.3.
> The fix from Ferruh could be sufficient for 2.2.
>
Hi Christian,
You can count on me to help testing DPDK for Ubuntu, I have plans for it!
I have some experience with Debian packaging too... I'm currently
maintaining few Ubuntu PPAs, for fun... =)
Also, I have hardware available, with 10G, 40G and 100G NIC cards and
traffic generators.
I would love to help! Specially when with DPDK on Xen (plans for in
on PVM, HVM, XenServer and Amazon EC2).
Just a curiosity, I'm the designer/maintainer of "Xen LiveCD v2.0"
and I would like to build a new version of it, that will be based on
Xenial with DPDK.
http://wiki.xenproject.org/wiki/Live_CD_(Xen_3.2_%2B_Debian_5.0)
https://github.com/tmartinx/xenlivecd
Hope to see DPDK compiling with Xen on 32-bit (it is broken now), so
we can enable it on Ubuntu!
Cheers!
Thiago
On 7 December 2015 at 06:27, Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
> Hi,
> FYI I kind of "gave up" (not as bad as it sounds) and started looking into
> shipping it as individual libraries + linker script as well.
> To me it seemed what was more accepted in all the former discussions.
>
> It will surely cause more work for me in the short term, but I hope after
> the initial hill I have to climb to make it happen it will be not too much
> in future releases.
>
> So if "we" were the only one causing this to be deferred consider it for
> 2.2.
> That way distributions would become more similar which might help consumers
> of the DPDK libraries.
> In the worst case I can reverse apply it for 2.2 to get some more time to
> get it to work properly for us later on.
>
> Looking at the great changes to "make install" by Thomas being in 2.2 -
> getting the linker script "official" in 2.2 as well would also help to not
> get a major overhaul to packaging every version :-)
>
> have a great week,
> Christian
>
>
>
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>
> On Fri, Dec 4, 2015 at 6:19 PM, Thomas Monjalon <thomas.monjalon@6wind.com>
> wrote:
>
>> 2015-11-24 16:31, Panu Matilainen:
>> > The physically linked-together combined library has been an increasing
>> > source of problems, as was predicted when library and symbol versioning
>> > was introduced. Replace the complex and fragile construction with a
>> > simple linker script which achieves the same without all the problems,
>> > remove the related kludges from eg mlx drivers.
>> >
>> > Since creating the linker script is practically zero cost, remove the
>> > config option and just create it always.
>> >
>> > Based on a patch by Sergio Gonzales Monroy, linker script approach
>> > initially suggested by Neil Horman.
>> >
>> > Suggested-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
>> > Suggested-by: Neil Horman <nhorman@tuxdriver.com>
>> > Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
>>
>> As it is a big change and discussion is not totally closed,
>> it is deferred to release 2.3.
>> The fix from Ferruh could be sufficient for 2.2.
>>
Hi,
I'm reviving this old thread.
My understanding is that everybody prefer the linker script
than the current combined library which had neither symbol versioning
nor library dependency informations.
Comments below:
2015-11-24 16:31, Panu Matilainen:
> The physically linked-together combined library has been an increasing
> source of problems, as was predicted when library and symbol versioning
> was introduced. Replace the complex and fragile construction with a
> simple linker script which achieves the same without all the problems,
> remove the related kludges from eg mlx drivers.
>
> Since creating the linker script is practically zero cost, remove the
> config option and just create it always.
[...]
> --- /dev/null
> +++ b/mk/rte.combinedlib.mk
> @@ -0,0 +1,57 @@
> +# BSD LICENSE
> +#
> +# Copyright(c) 2010-2015 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.
Why this header, Panu?
I think you should write your own copyright, and assume the linker script ;)
It needs to be rebased and some docs comments must be removed or updated.
I'll send a v2.
On 02/23/2016 10:07 PM, Thomas Monjalon wrote:
> Hi,
>
> I'm reviving this old thread.
Thanks.
> My understanding is that everybody prefer the linker script
> than the current combined library which had neither symbol versioning
> nor library dependency informations.
Yeah it seemed to me most (if not everybody) had converged on the side
of the linker script approach.
>
> Comments below:
>
> 2015-11-24 16:31, Panu Matilainen:
>> The physically linked-together combined library has been an increasing
>> source of problems, as was predicted when library and symbol versioning
>> was introduced. Replace the complex and fragile construction with a
>> simple linker script which achieves the same without all the problems,
>> remove the related kludges from eg mlx drivers.
>>
>> Since creating the linker script is practically zero cost, remove the
>> config option and just create it always.
> [...]
>> --- /dev/null
>> +++ b/mk/rte.combinedlib.mk
>> @@ -0,0 +1,57 @@
>> +# BSD LICENSE
>> +#
>> +# Copyright(c) 2010-2015 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.
>
> Why this header, Panu?
> I think you should write your own copyright, and assume the linker script ;)
Its just inherited from the original patch by Sergio. As he's the actual
author here, it didn't seem appropriate for me to remove it.
>
> It needs to be rebased and some docs comments must be removed or updated.
> I'll send a v2.
>
Thanks,
- Panu -
@@ -84,11 +84,6 @@ CONFIG_RTE_ARCH_STRICT_ALIGN=n
CONFIG_RTE_BUILD_SHARED_LIB=n
#
-# Combine to one single library
-#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
-
-#
# Use newest code breaking previous ABI
#
CONFIG_RTE_NEXT_ABI=y
@@ -84,11 +84,6 @@ CONFIG_RTE_ARCH_STRICT_ALIGN=n
CONFIG_RTE_BUILD_SHARED_LIB=n
#
-# Combine to one single library
-#
-CONFIG_RTE_BUILD_COMBINE_LIBS=n
-
-#
# Use newest code breaking previous ABI
#
CONFIG_RTE_NEXT_ABI=y
@@ -51,5 +51,4 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
-include $(RTE_SDK)/mk/rte.sharelib.mk
include $(RTE_SDK)/mk/rte.subdir.mk
@@ -31,12 +31,6 @@
include $(RTE_SDK)/mk/rte.vars.mk
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS)$(CONFIG_RTE_BUILD_SHARED_LIB),yy)
-all:
- @echo 'MLX4: Not supported in a combined shared library'
- @false
-endif
-
# Library name.
LIB = librte_pmd_mlx4.a
@@ -31,12 +31,6 @@
include $(RTE_SDK)/mk/rte.vars.mk
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS)$(CONFIG_RTE_BUILD_SHARED_LIB),yy)
-all:
- @echo 'MLX5: Not supported in a combined shared library'
- @false
-endif
-
# Library name.
LIB = librte_pmd_mlx5.a
@@ -62,5 +62,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
@@ -59,10 +59,6 @@ _LDLIBS-y += -L$(RTE_SDK_BIN)/lib
_LDLIBS-y += --whole-archive
-_LDLIBS-$(CONFIG_RTE_BUILD_COMBINE_LIBS) += -l$(RTE_LIBNAME)
-
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
_LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += -lrte_distributor
_LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER) += -lrte_reorder
@@ -88,8 +84,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt
_LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += -lpcap
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += -lsze2
@@ -114,8 +108,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += -lz
_LDLIBS-y += --start-group
-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
-
_LDLIBS-$(CONFIG_RTE_LIBRTE_KVARGS) += -lrte_kvargs
_LDLIBS-$(CONFIG_RTE_LIBRTE_MBUF) += -lrte_mbuf
_LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += -lrte_ip_frag
@@ -153,8 +145,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += -lrte_pmd_null
endif # ! $(CONFIG_RTE_BUILD_SHARED_LIB)
-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
-
_LDLIBS-y += $(EXECENV_LDLIBS)
_LDLIBS-y += --end-group
_LDLIBS-y += --no-whole-archive
new file mode 100644
@@ -0,0 +1,57 @@
+# BSD LICENSE
+#
+# Copyright(c) 2010-2015 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/rte.vars.mk
+
+default: all
+
+ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
+EXT:=.so
+else
+EXT:=.a
+endif
+
+COMBINEDLIB := lib$(RTE_LIBNAME)$(EXT)
+
+LIBS := $(notdir $(wildcard $(RTE_OUTPUT)/lib/*$(EXT)))
+
+all: FORCE
+ $(Q)echo "GROUP ( $(LIBS) )" > $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+#
+# Clean all generated files
+#
+.PHONY: clean
+clean:
+ $(Q)rm -f $(RTE_OUTPUT)/lib/$(COMBINEDLIB)
+
+.PHONY: FORCE
+FORCE:
@@ -134,14 +134,6 @@ endif
$(depfile_newer)),\
$(O_TO_S_DO))
-ifeq ($(CONFIG_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 $@)
@@ -157,14 +149,6 @@ $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
$(depfile_missing),\
$(depfile_newer)),\
$(O_TO_A_DO))
-ifeq ($(CONFIG_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,8 +93,8 @@ $(ROOTDIRS-y):
@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
@echo "== Build $@"
$(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
- @if [ $@ = drivers -a $(CONFIG_RTE_BUILD_COMBINE_LIBS) = y ]; then \
- $(MAKE) -f $(RTE_SDK)/lib/Makefile sharelib; \
+ @if [ $@ = drivers ]; then \
+ $(MAKE) -f $(RTE_SDK)/mk/rte.combinedlib.mk; \
fi
%_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 ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(CONFIG_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 ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
-ifeq ($(CONFIG_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: