[dpdk-dev] [PATCH 0/8] Improve build process
On 23/02/2015 13:52, Neil Horman wrote: > On Mon, Feb 23, 2015 at 10:25:01AM +, Gonzalez Monroy, Sergio wrote: >> On 22/02/2015 23:37, Neil Horman wrote: >>> On Fri, Feb 20, 2015 at 02:31:36PM +, Gonzalez Monroy, Sergio wrote: On 13/02/2015 12:51, Neil Horman wrote: > On Fri, Feb 13, 2015 at 11:08:02AM +, Gonzalez Monroy, Sergio wrote: >> On 13/02/2015 10:14, Panu Matilainen wrote: >>> On 02/12/2015 05:52 PM, Neil Horman wrote: On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > On 02/12/2015 02:23 PM, Neil Horman wrote: >>> [...snip...] > So I just realized that I was not having into account a possible > scenario, where > we have an app built with static dpdk libs then loading a dso > with -d > option. > > In such case, because the pmd would have DT_NEEDED entries, > dlopen will > fail. > So to enable such scenario we would need to build PMDs without > DT_NEEDED > entries. Hmm, for that to be a problem you'd need to have the PMD built against shared dpdk libs and while the application is built against static dpdk libs. I dont think that's a supportable scenario in any case. Or is there some other scenario that I'm not seeing? - Panu - >>> I agree with you. I suppose it comes down to, do we want to >>> support such >>> scenario? >>> >>> From what I can see, it seems that we do currently support such >>> scenario by >>> building dpdk apps against all static dpdk libs using >>> --whole-archive (all >>> libs and not only PMDs). >>> http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 >>> >>> >>> Am I misunderstanding this? >>> >> Shoot, you're right, I missed the static build aspect to this. Yes, >> if we do the following: >> >> 1) Build the DPDK as a static library >> 2) Link an application against (1) >> 3) Use the dlopen mechanism to load a PMD built as a DSO >> >> Then the DT_NEEDED entries in the DSO will go unsatisfied, because >> the shared >> objects on which it (the PMD) depends will not exist in the file >> system. > I think its even more twisty: > > 1) Build the DPDK as a static library > 2) Link an application against (1) > 3) Do another build of DPDK as a shared library > 4) In app 2), use the dlopen mechanism to load a PMD built as a part > of or > against 3) > > Somehow I doubt this would work very well. > Ideally it should, presuming the ABI is preserved between (1) and (3), though I agree, up until recently, that was an assumption that was unreliable. >>> Versioning is a big and important step towards reliability but there are >>> more issues to solve. This of course getting pretty far from the >>> original >>> topic, but at least one such issue is that there are some cases where a >>> config value affects what are apparently public structs (rte_mbuf wrt >>> RTE_MBUF_REFCNT for example), which really is a no-go. >>> >> Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. >> I'll look into it. >> >> I think the problem is a little bit orthogonal to the libdpdk_core >> problem you >> were initially addressing. That is to say, this problem of >> dlopen-ed PMD's >> exists regardless of weather you build the DPDK as part of a static >> or dynamic >> library. The problems just happen to intersect in their >> manipulation of the >> DT_NEEDED entries. >> >> Ok, so, given the above, I would say your approach is likely >> correct, just >> prevent DT_NEEDED entries from getting added to PMD's. Doing so will >> sidestep >> loading issue for libraries that may not exist in the filesystem, >> but thats ok, >> because by all rights, the symbols codified in those needed >> libraries should >> already be present in the running application (either made available >> by the >> application having statically linked them, or having the linker load >> them from >> the proper libraries at run time). > My 5c is that I'd much rather see the common case (all static or all > shared) > be simple and reliable, which in case of DSOs includes no lying > (whether by > omission or otherwise) about DT_NEEDED, ever. That way the issue is > dealt > once
[dpdk-dev] [PATCH 0/8] Improve build process
On Mon, Feb 23, 2015 at 02:58:30PM +, Gonzalez Monroy, Sergio wrote: > On 23/02/2015 13:52, Neil Horman wrote: > >On Mon, Feb 23, 2015 at 10:25:01AM +, Gonzalez Monroy, Sergio wrote: > >>On 22/02/2015 23:37, Neil Horman wrote: > >>>On Fri, Feb 20, 2015 at 02:31:36PM +, Gonzalez Monroy, Sergio wrote: > On 13/02/2015 12:51, Neil Horman wrote: > >On Fri, Feb 13, 2015 at 11:08:02AM +, Gonzalez Monroy, Sergio wrote: > >>On 13/02/2015 10:14, Panu Matilainen wrote: > >>>On 02/12/2015 05:52 PM, Neil Horman wrote: > On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > >On 02/12/2015 02:23 PM, Neil Horman wrote: > >>>[...snip...] > >So I just realized that I was not having into account a possible > >scenario, where > >we have an app built with static dpdk libs then loading a dso > >with -d > >option. > > > >In such case, because the pmd would have DT_NEEDED entries, > >dlopen will > >fail. > >So to enable such scenario we would need to build PMDs without > >DT_NEEDED > >entries. > Hmm, for that to be a problem you'd need to have the PMD built > against > shared dpdk libs and while the application is built against > static dpdk > libs. I dont think that's a supportable scenario in any case. > > Or is there some other scenario that I'm not seeing? > > - Panu - > > >>>I agree with you. I suppose it comes down to, do we want to > >>>support such > >>>scenario? > >>> > >>> From what I can see, it seems that we do currently support such > >>>scenario by > >>>building dpdk apps against all static dpdk libs using > >>>--whole-archive (all > >>>libs and not only PMDs). > >>>http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > >>> > >>> > >>>Am I misunderstanding this? > >>> > >>Shoot, you're right, I missed the static build aspect to this. Yes, > >>if we do the following: > >> > >>1) Build the DPDK as a static library > >>2) Link an application against (1) > >>3) Use the dlopen mechanism to load a PMD built as a DSO > >> > >>Then the DT_NEEDED entries in the DSO will go unsatisfied, because > >>the shared > >>objects on which it (the PMD) depends will not exist in the file > >>system. > >I think its even more twisty: > > > >1) Build the DPDK as a static library > >2) Link an application against (1) > >3) Do another build of DPDK as a shared library > >4) In app 2), use the dlopen mechanism to load a PMD built as a part > >of or > >against 3) > > > >Somehow I doubt this would work very well. > > > Ideally it should, presuming the ABI is preserved between (1) and (3), > though I > agree, up until recently, that was an assumption that was unreliable. > >>>Versioning is a big and important step towards reliability but there > >>>are > >>>more issues to solve. This of course getting pretty far from the > >>>original > >>>topic, but at least one such issue is that there are some cases where a > >>>config value affects what are apparently public structs (rte_mbuf wrt > >>>RTE_MBUF_REFCNT for example), which really is a no-go. > >>> > >>Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with > >>asap. > >>I'll look into it. > >> > >>I think the problem is a little bit orthogonal to the libdpdk_core > >>problem you > >>were initially addressing. That is to say, this problem of > >>dlopen-ed PMD's > >>exists regardless of weather you build the DPDK as part of a static > >>or dynamic > >>library. The problems just happen to intersect in their > >>manipulation of the > >>DT_NEEDED entries. > >> > >>Ok, so, given the above, I would say your approach is likely > >>correct, just > >>prevent DT_NEEDED entries from getting added to PMD's. Doing so will > >>sidestep > >>loading issue for libraries that may not exist in the filesystem, > >>but thats ok, > >>because by all rights, the symbols codified in those needed > >>libraries should > >>already be present in the running application (either made available > >>by the > >>application having statically linked them, or having the linker load > >>them from > >>the proper libraries at run time). > >My 5c is that I'd much rather see the common case (all static or all >
[dpdk-dev] [PATCH 0/8] Improve build process
On 22/02/2015 23:37, Neil Horman wrote: > On Fri, Feb 20, 2015 at 02:31:36PM +, Gonzalez Monroy, Sergio wrote: >> On 13/02/2015 12:51, Neil Horman wrote: >>> On Fri, Feb 13, 2015 at 11:08:02AM +, Gonzalez Monroy, Sergio wrote: On 13/02/2015 10:14, Panu Matilainen wrote: > On 02/12/2015 05:52 PM, Neil Horman wrote: >> On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: >>> On 02/12/2015 02:23 PM, Neil Horman wrote: > [...snip...] >>> So I just realized that I was not having into account a possible >>> scenario, where >>> we have an app built with static dpdk libs then loading a dso >>> with -d >>> option. >>> >>> In such case, because the pmd would have DT_NEEDED entries, >>> dlopen will >>> fail. >>> So to enable such scenario we would need to build PMDs without >>> DT_NEEDED >>> entries. >> Hmm, for that to be a problem you'd need to have the PMD built >> against >> shared dpdk libs and while the application is built against >> static dpdk >> libs. I dont think that's a supportable scenario in any case. >> >> Or is there some other scenario that I'm not seeing? >> >> - Panu - >> > I agree with you. I suppose it comes down to, do we want to > support such > scenario? > > From what I can see, it seems that we do currently support such > scenario by > building dpdk apps against all static dpdk libs using > --whole-archive (all > libs and not only PMDs). > http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > > > Am I misunderstanding this? > Shoot, you're right, I missed the static build aspect to this. Yes, if we do the following: 1) Build the DPDK as a static library 2) Link an application against (1) 3) Use the dlopen mechanism to load a PMD built as a DSO Then the DT_NEEDED entries in the DSO will go unsatisfied, because the shared objects on which it (the PMD) depends will not exist in the file system. >>> I think its even more twisty: >>> >>> 1) Build the DPDK as a static library >>> 2) Link an application against (1) >>> 3) Do another build of DPDK as a shared library >>> 4) In app 2), use the dlopen mechanism to load a PMD built as a part >>> of or >>> against 3) >>> >>> Somehow I doubt this would work very well. >>> >> Ideally it should, presuming the ABI is preserved between (1) and (3), >> though I >> agree, up until recently, that was an assumption that was unreliable. > Versioning is a big and important step towards reliability but there are > more issues to solve. This of course getting pretty far from the original > topic, but at least one such issue is that there are some cases where a > config value affects what are apparently public structs (rte_mbuf wrt > RTE_MBUF_REFCNT for example), which really is a no-go. > Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. I'll look into it. I think the problem is a little bit orthogonal to the libdpdk_core problem you were initially addressing. That is to say, this problem of dlopen-ed PMD's exists regardless of weather you build the DPDK as part of a static or dynamic library. The problems just happen to intersect in their manipulation of the DT_NEEDED entries. Ok, so, given the above, I would say your approach is likely correct, just prevent DT_NEEDED entries from getting added to PMD's. Doing so will sidestep loading issue for libraries that may not exist in the filesystem, but thats ok, because by all rights, the symbols codified in those needed libraries should already be present in the running application (either made available by the application having statically linked them, or having the linker load them from the proper libraries at run time). >>> My 5c is that I'd much rather see the common case (all static or all >>> shared) >>> be simple and reliable, which in case of DSOs includes no lying >>> (whether by >>> omission or otherwise) about DT_NEEDED, ever. That way the issue is >>> dealt >>> once where it belongs. If somebody wants to go down the rabbit hole of >>> mixed >>> shared + static linkage, let them dig the hole by themselves :) >>> >> This is a fair point. Can DT_NEEDED sections be stripped via tools like >> objcopy >> after the build is complete? If so, end users can hack this corner case >> to
[dpdk-dev] [PATCH 0/8] Improve build process
On Mon, Feb 23, 2015 at 10:25:01AM +, Gonzalez Monroy, Sergio wrote: > On 22/02/2015 23:37, Neil Horman wrote: > >On Fri, Feb 20, 2015 at 02:31:36PM +, Gonzalez Monroy, Sergio wrote: > >>On 13/02/2015 12:51, Neil Horman wrote: > >>>On Fri, Feb 13, 2015 at 11:08:02AM +, Gonzalez Monroy, Sergio wrote: > On 13/02/2015 10:14, Panu Matilainen wrote: > >On 02/12/2015 05:52 PM, Neil Horman wrote: > >>On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > >>>On 02/12/2015 02:23 PM, Neil Horman wrote: > >[...snip...] > >>>So I just realized that I was not having into account a possible > >>>scenario, where > >>>we have an app built with static dpdk libs then loading a dso > >>>with -d > >>>option. > >>> > >>>In such case, because the pmd would have DT_NEEDED entries, > >>>dlopen will > >>>fail. > >>>So to enable such scenario we would need to build PMDs without > >>>DT_NEEDED > >>>entries. > >>Hmm, for that to be a problem you'd need to have the PMD built > >>against > >>shared dpdk libs and while the application is built against > >>static dpdk > >>libs. I dont think that's a supportable scenario in any case. > >> > >>Or is there some other scenario that I'm not seeing? > >> > >>- Panu - > >> > >I agree with you. I suppose it comes down to, do we want to > >support such > >scenario? > > > > From what I can see, it seems that we do currently support such > >scenario by > >building dpdk apps against all static dpdk libs using > >--whole-archive (all > >libs and not only PMDs). > >http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > > > > > >Am I misunderstanding this? > > > Shoot, you're right, I missed the static build aspect to this. Yes, > if we do the following: > > 1) Build the DPDK as a static library > 2) Link an application against (1) > 3) Use the dlopen mechanism to load a PMD built as a DSO > > Then the DT_NEEDED entries in the DSO will go unsatisfied, because > the shared > objects on which it (the PMD) depends will not exist in the file > system. > >>>I think its even more twisty: > >>> > >>>1) Build the DPDK as a static library > >>>2) Link an application against (1) > >>>3) Do another build of DPDK as a shared library > >>>4) In app 2), use the dlopen mechanism to load a PMD built as a part > >>>of or > >>>against 3) > >>> > >>>Somehow I doubt this would work very well. > >>> > >>Ideally it should, presuming the ABI is preserved between (1) and (3), > >>though I > >>agree, up until recently, that was an assumption that was unreliable. > >Versioning is a big and important step towards reliability but there are > >more issues to solve. This of course getting pretty far from the original > >topic, but at least one such issue is that there are some cases where a > >config value affects what are apparently public structs (rte_mbuf wrt > >RTE_MBUF_REFCNT for example), which really is a no-go. > > > Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. > I'll look into it. > > I think the problem is a little bit orthogonal to the libdpdk_core > problem you > were initially addressing. That is to say, this problem of > dlopen-ed PMD's > exists regardless of weather you build the DPDK as part of a static > or dynamic > library. The problems just happen to intersect in their > manipulation of the > DT_NEEDED entries. > > Ok, so, given the above, I would say your approach is likely > correct, just > prevent DT_NEEDED entries from getting added to PMD's. Doing so will > sidestep > loading issue for libraries that may not exist in the filesystem, > but thats ok, > because by all rights, the symbols codified in those needed > libraries should > already be present in the running application (either made available > by the > application having statically linked them, or having the linker load > them from > the proper libraries at run time). > >>>My 5c is that I'd much rather see the common case (all static or all > >>>shared) > >>>be simple and reliable, which in case of DSOs includes no lying > >>>(whether by > >>>omission or otherwise) about DT_NEEDED, ever. That way the issue is > >>>dealt > >>>once where it belongs. If somebody wants to go down the rabbit hole of > >>>mixed > >>>shared + static linkage, let them dig the hole by
[dpdk-dev] [PATCH 0/8] Improve build process
On Fri, Feb 20, 2015 at 02:31:36PM +, Gonzalez Monroy, Sergio wrote: > On 13/02/2015 12:51, Neil Horman wrote: > >On Fri, Feb 13, 2015 at 11:08:02AM +, Gonzalez Monroy, Sergio wrote: > >>On 13/02/2015 10:14, Panu Matilainen wrote: > >>>On 02/12/2015 05:52 PM, Neil Horman wrote: > On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > >On 02/12/2015 02:23 PM, Neil Horman wrote: > >>>[...snip...] > >So I just realized that I was not having into account a possible > >scenario, where > >we have an app built with static dpdk libs then loading a dso > >with -d > >option. > > > >In such case, because the pmd would have DT_NEEDED entries, > >dlopen will > >fail. > >So to enable such scenario we would need to build PMDs without > >DT_NEEDED > >entries. > Hmm, for that to be a problem you'd need to have the PMD built > against > shared dpdk libs and while the application is built against > static dpdk > libs. I dont think that's a supportable scenario in any case. > > Or is there some other scenario that I'm not seeing? > > - Panu - > > >>>I agree with you. I suppose it comes down to, do we want to > >>>support such > >>>scenario? > >>> > >>> From what I can see, it seems that we do currently support such > >>>scenario by > >>>building dpdk apps against all static dpdk libs using > >>>--whole-archive (all > >>>libs and not only PMDs). > >>>http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > >>> > >>> > >>>Am I misunderstanding this? > >>> > >>Shoot, you're right, I missed the static build aspect to this. Yes, > >>if we do the following: > >> > >>1) Build the DPDK as a static library > >>2) Link an application against (1) > >>3) Use the dlopen mechanism to load a PMD built as a DSO > >> > >>Then the DT_NEEDED entries in the DSO will go unsatisfied, because > >>the shared > >>objects on which it (the PMD) depends will not exist in the file > >>system. > >I think its even more twisty: > > > >1) Build the DPDK as a static library > >2) Link an application against (1) > >3) Do another build of DPDK as a shared library > >4) In app 2), use the dlopen mechanism to load a PMD built as a part > >of or > >against 3) > > > >Somehow I doubt this would work very well. > > > Ideally it should, presuming the ABI is preserved between (1) and (3), > though I > agree, up until recently, that was an assumption that was unreliable. > >>>Versioning is a big and important step towards reliability but there are > >>>more issues to solve. This of course getting pretty far from the original > >>>topic, but at least one such issue is that there are some cases where a > >>>config value affects what are apparently public structs (rte_mbuf wrt > >>>RTE_MBUF_REFCNT for example), which really is a no-go. > >>> > >>Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. > >>I'll look into it. > >> > >>I think the problem is a little bit orthogonal to the libdpdk_core > >>problem you > >>were initially addressing. That is to say, this problem of > >>dlopen-ed PMD's > >>exists regardless of weather you build the DPDK as part of a static > >>or dynamic > >>library. The problems just happen to intersect in their > >>manipulation of the > >>DT_NEEDED entries. > >> > >>Ok, so, given the above, I would say your approach is likely > >>correct, just > >>prevent DT_NEEDED entries from getting added to PMD's. Doing so will > >>sidestep > >>loading issue for libraries that may not exist in the filesystem, > >>but thats ok, > >>because by all rights, the symbols codified in those needed > >>libraries should > >>already be present in the running application (either made available > >>by the > >>application having statically linked them, or having the linker load > >>them from > >>the proper libraries at run time). > >My 5c is that I'd much rather see the common case (all static or all > >shared) > >be simple and reliable, which in case of DSOs includes no lying > >(whether by > >omission or otherwise) about DT_NEEDED, ever. That way the issue is > >dealt > >once where it belongs. If somebody wants to go down the rabbit hole of > >mixed > >shared + static linkage, let them dig the hole by themselves :) > > > This is a fair point. Can DT_NEEDED sections be stripped via tools like > objcopy > after the build is complete? If so, end users can hack this corner case > to work > as needed. > >>>Patchelf (http://nixos.org/patchelf.html) appears to support that, but > >>>given that source is available it'd
[dpdk-dev] [PATCH 0/8] Improve build process
On 13/02/2015 12:51, Neil Horman wrote: > On Fri, Feb 13, 2015 at 11:08:02AM +, Gonzalez Monroy, Sergio wrote: >> On 13/02/2015 10:14, Panu Matilainen wrote: >>> On 02/12/2015 05:52 PM, Neil Horman wrote: On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > On 02/12/2015 02:23 PM, Neil Horman wrote: >>> [...snip...] > So I just realized that I was not having into account a possible > scenario, where > we have an app built with static dpdk libs then loading a dso > with -d > option. > > In such case, because the pmd would have DT_NEEDED entries, > dlopen will > fail. > So to enable such scenario we would need to build PMDs without > DT_NEEDED > entries. Hmm, for that to be a problem you'd need to have the PMD built against shared dpdk libs and while the application is built against static dpdk libs. I dont think that's a supportable scenario in any case. Or is there some other scenario that I'm not seeing? - Panu - >>> I agree with you. I suppose it comes down to, do we want to >>> support such >>> scenario? >>> >>> From what I can see, it seems that we do currently support such >>> scenario by >>> building dpdk apps against all static dpdk libs using >>> --whole-archive (all >>> libs and not only PMDs). >>> http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 >>> >>> >>> Am I misunderstanding this? >>> >> Shoot, you're right, I missed the static build aspect to this. Yes, >> if we do the following: >> >> 1) Build the DPDK as a static library >> 2) Link an application against (1) >> 3) Use the dlopen mechanism to load a PMD built as a DSO >> >> Then the DT_NEEDED entries in the DSO will go unsatisfied, because >> the shared >> objects on which it (the PMD) depends will not exist in the file >> system. > I think its even more twisty: > > 1) Build the DPDK as a static library > 2) Link an application against (1) > 3) Do another build of DPDK as a shared library > 4) In app 2), use the dlopen mechanism to load a PMD built as a part > of or > against 3) > > Somehow I doubt this would work very well. > Ideally it should, presuming the ABI is preserved between (1) and (3), though I agree, up until recently, that was an assumption that was unreliable. >>> Versioning is a big and important step towards reliability but there are >>> more issues to solve. This of course getting pretty far from the original >>> topic, but at least one such issue is that there are some cases where a >>> config value affects what are apparently public structs (rte_mbuf wrt >>> RTE_MBUF_REFCNT for example), which really is a no-go. >>> >> Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. >> I'll look into it. >> >> I think the problem is a little bit orthogonal to the libdpdk_core >> problem you >> were initially addressing. That is to say, this problem of >> dlopen-ed PMD's >> exists regardless of weather you build the DPDK as part of a static >> or dynamic >> library. The problems just happen to intersect in their >> manipulation of the >> DT_NEEDED entries. >> >> Ok, so, given the above, I would say your approach is likely >> correct, just >> prevent DT_NEEDED entries from getting added to PMD's. Doing so will >> sidestep >> loading issue for libraries that may not exist in the filesystem, >> but thats ok, >> because by all rights, the symbols codified in those needed >> libraries should >> already be present in the running application (either made available >> by the >> application having statically linked them, or having the linker load >> them from >> the proper libraries at run time). > My 5c is that I'd much rather see the common case (all static or all > shared) > be simple and reliable, which in case of DSOs includes no lying > (whether by > omission or otherwise) about DT_NEEDED, ever. That way the issue is > dealt > once where it belongs. If somebody wants to go down the rabbit hole of > mixed > shared + static linkage, let them dig the hole by themselves :) > This is a fair point. Can DT_NEEDED sections be stripped via tools like objcopy after the build is complete? If so, end users can hack this corner case to work as needed. >>> Patchelf (http://nixos.org/patchelf.html) appears to support that, but >>> given that source is available it'd be easier to just modify the makefiles >>> if that's really needed. >>> >> I think we agree on the issue. >> >> So I'll be sending a patch to add DT_NEEDED entries to all libraries and >> PMDs. The only
[dpdk-dev] [PATCH 0/8] Improve build process
On 02/12/2015 05:52 PM, Neil Horman wrote: > On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: >> On 02/12/2015 02:23 PM, Neil Horman wrote: [...snip...] >>> >> So I just realized that I was not having into account a possible >> scenario, where >> we have an app built with static dpdk libs then loading a dso with -d >> option. >> >> In such case, because the pmd would have DT_NEEDED entries, dlopen will >> fail. >> So to enable such scenario we would need to build PMDs without DT_NEEDED >> entries. > > Hmm, for that to be a problem you'd need to have the PMD built against > shared dpdk libs and while the application is built against static dpdk > libs. I dont think that's a supportable scenario in any case. > > Or is there some other scenario that I'm not seeing? > > - Panu - > I agree with you. I suppose it comes down to, do we want to support such scenario? From what I can see, it seems that we do currently support such scenario by building dpdk apps against all static dpdk libs using --whole-archive (all libs and not only PMDs). http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 Am I misunderstanding this? >>> Shoot, you're right, I missed the static build aspect to this. Yes, if we >>> do the following: >>> >>> 1) Build the DPDK as a static library >>> 2) Link an application against (1) >>> 3) Use the dlopen mechanism to load a PMD built as a DSO >>> >>> Then the DT_NEEDED entries in the DSO will go unsatisfied, because the >>> shared >>> objects on which it (the PMD) depends will not exist in the file system. >> >> I think its even more twisty: >> >> 1) Build the DPDK as a static library >> 2) Link an application against (1) >> 3) Do another build of DPDK as a shared library >> 4) In app 2), use the dlopen mechanism to load a PMD built as a part of or >> against 3) >> >> Somehow I doubt this would work very well. >> > Ideally it should, presuming the ABI is preserved between (1) and (3), though > I > agree, up until recently, that was an assumption that was unreliable. Versioning is a big and important step towards reliability but there are more issues to solve. This of course getting pretty far from the original topic, but at least one such issue is that there are some cases where a config value affects what are apparently public structs (rte_mbuf wrt RTE_MBUF_REFCNT for example), which really is a no-go. >>> >>> I think the problem is a little bit orthogonal to the libdpdk_core problem >>> you >>> were initially addressing. That is to say, this problem of dlopen-ed PMD's >>> exists regardless of weather you build the DPDK as part of a static or >>> dynamic >>> library. The problems just happen to intersect in their manipulation of the >>> DT_NEEDED entries. >>> >>> Ok, so, given the above, I would say your approach is likely correct, just >>> prevent DT_NEEDED entries from getting added to PMD's. Doing so will >>> sidestep >>> loading issue for libraries that may not exist in the filesystem, but thats >>> ok, >>> because by all rights, the symbols codified in those needed libraries should >>> already be present in the running application (either made available by the >>> application having statically linked them, or having the linker load them >>> from >>> the proper libraries at run time). >> >> My 5c is that I'd much rather see the common case (all static or all shared) >> be simple and reliable, which in case of DSOs includes no lying (whether by >> omission or otherwise) about DT_NEEDED, ever. That way the issue is dealt >> once where it belongs. If somebody wants to go down the rabbit hole of mixed >> shared + static linkage, let them dig the hole by themselves :) >> > This is a fair point. Can DT_NEEDED sections be stripped via tools like > objcopy > after the build is complete? If so, end users can hack this corner case to > work > as needed. Patchelf (http://nixos.org/patchelf.html) appears to support that, but given that source is available it'd be easier to just modify the makefiles if that's really needed. - Panu -
[dpdk-dev] [PATCH 0/8] Improve build process
On 13/02/2015 10:14, Panu Matilainen wrote: > On 02/12/2015 05:52 PM, Neil Horman wrote: >> On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: >>> On 02/12/2015 02:23 PM, Neil Horman wrote: > [...snip...] >>> So I just realized that I was not having into account a possible >>> scenario, where >>> we have an app built with static dpdk libs then loading a dso >>> with -d >>> option. >>> >>> In such case, because the pmd would have DT_NEEDED entries, >>> dlopen will >>> fail. >>> So to enable such scenario we would need to build PMDs without >>> DT_NEEDED >>> entries. >> >> Hmm, for that to be a problem you'd need to have the PMD built >> against >> shared dpdk libs and while the application is built against >> static dpdk >> libs. I dont think that's a supportable scenario in any case. >> >> Or is there some other scenario that I'm not seeing? >> >> - Panu - >> > I agree with you. I suppose it comes down to, do we want to > support such > scenario? > > From what I can see, it seems that we do currently support such > scenario by > building dpdk apps against all static dpdk libs using > --whole-archive (all > libs and not only PMDs). > http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > > > > Am I misunderstanding this? > Shoot, you're right, I missed the static build aspect to this. Yes, if we do the following: 1) Build the DPDK as a static library 2) Link an application against (1) 3) Use the dlopen mechanism to load a PMD built as a DSO Then the DT_NEEDED entries in the DSO will go unsatisfied, because the shared objects on which it (the PMD) depends will not exist in the file system. >>> >>> I think its even more twisty: >>> >>> 1) Build the DPDK as a static library >>> 2) Link an application against (1) >>> 3) Do another build of DPDK as a shared library >>> 4) In app 2), use the dlopen mechanism to load a PMD built as a part >>> of or >>> against 3) >>> >>> Somehow I doubt this would work very well. >>> >> Ideally it should, presuming the ABI is preserved between (1) and >> (3), though I >> agree, up until recently, that was an assumption that was unreliable. > > Versioning is a big and important step towards reliability but there > are more issues to solve. This of course getting pretty far from the > original topic, but at least one such issue is that there are some > cases where a config value affects what are apparently public structs > (rte_mbuf wrt RTE_MBUF_REFCNT for example), which really is a no-go. > Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. I'll look into it. I think the problem is a little bit orthogonal to the libdpdk_core problem you were initially addressing. That is to say, this problem of dlopen-ed PMD's exists regardless of weather you build the DPDK as part of a static or dynamic library. The problems just happen to intersect in their manipulation of the DT_NEEDED entries. Ok, so, given the above, I would say your approach is likely correct, just prevent DT_NEEDED entries from getting added to PMD's. Doing so will sidestep loading issue for libraries that may not exist in the filesystem, but thats ok, because by all rights, the symbols codified in those needed libraries should already be present in the running application (either made available by the application having statically linked them, or having the linker load them from the proper libraries at run time). >>> >>> My 5c is that I'd much rather see the common case (all static or all >>> shared) >>> be simple and reliable, which in case of DSOs includes no lying >>> (whether by >>> omission or otherwise) about DT_NEEDED, ever. That way the issue is >>> dealt >>> once where it belongs. If somebody wants to go down the rabbit hole >>> of mixed >>> shared + static linkage, let them dig the hole by themselves :) >>> >> This is a fair point. Can DT_NEEDED sections be stripped via tools >> like objcopy >> after the build is complete? If so, end users can hack this corner >> case to work >> as needed. > > Patchelf (http://nixos.org/patchelf.html) appears to support that, but > given that source is available it'd be easier to just modify the > makefiles if that's really needed. > I think we agree on the issue. So I'll be sending a patch to add DT_NEEDED entries to all libraries and PMDs. The only exception would be librte_eal, which would not have proper NEEDED entries. Do we bother adding a linker script for librte_eal that would include dependent libraries? Sergio
[dpdk-dev] [PATCH 0/8] Improve build process
On Fri, Feb 13, 2015 at 11:08:02AM +, Gonzalez Monroy, Sergio wrote: > On 13/02/2015 10:14, Panu Matilainen wrote: > >On 02/12/2015 05:52 PM, Neil Horman wrote: > >>On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > >>>On 02/12/2015 02:23 PM, Neil Horman wrote: > >[...snip...] > > >>>So I just realized that I was not having into account a possible > >>>scenario, where > >>>we have an app built with static dpdk libs then loading a dso > >>>with -d > >>>option. > >>> > >>>In such case, because the pmd would have DT_NEEDED entries, > >>>dlopen will > >>>fail. > >>>So to enable such scenario we would need to build PMDs without > >>>DT_NEEDED > >>>entries. > >> > >>Hmm, for that to be a problem you'd need to have the PMD built > >>against > >>shared dpdk libs and while the application is built against > >>static dpdk > >>libs. I dont think that's a supportable scenario in any case. > >> > >>Or is there some other scenario that I'm not seeing? > >> > >>- Panu - > >> > >I agree with you. I suppose it comes down to, do we want to > >support such > >scenario? > > > > From what I can see, it seems that we do currently support such > >scenario by > >building dpdk apps against all static dpdk libs using > >--whole-archive (all > >libs and not only PMDs). > >http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 > > > > > >Am I misunderstanding this? > > > Shoot, you're right, I missed the static build aspect to this. Yes, > if we do the following: > > 1) Build the DPDK as a static library > 2) Link an application against (1) > 3) Use the dlopen mechanism to load a PMD built as a DSO > > Then the DT_NEEDED entries in the DSO will go unsatisfied, because > the shared > objects on which it (the PMD) depends will not exist in the file > system. > >>> > >>>I think its even more twisty: > >>> > >>>1) Build the DPDK as a static library > >>>2) Link an application against (1) > >>>3) Do another build of DPDK as a shared library > >>>4) In app 2), use the dlopen mechanism to load a PMD built as a part > >>>of or > >>>against 3) > >>> > >>>Somehow I doubt this would work very well. > >>> > >>Ideally it should, presuming the ABI is preserved between (1) and (3), > >>though I > >>agree, up until recently, that was an assumption that was unreliable. > > > >Versioning is a big and important step towards reliability but there are > >more issues to solve. This of course getting pretty far from the original > >topic, but at least one such issue is that there are some cases where a > >config value affects what are apparently public structs (rte_mbuf wrt > >RTE_MBUF_REFCNT for example), which really is a no-go. > > > Agree, the RTE_MBUF_REFCNT is something that needs to be dealt with asap. > I'll look into it. > > > I think the problem is a little bit orthogonal to the libdpdk_core > problem you > were initially addressing. That is to say, this problem of > dlopen-ed PMD's > exists regardless of weather you build the DPDK as part of a static > or dynamic > library. The problems just happen to intersect in their > manipulation of the > DT_NEEDED entries. > > Ok, so, given the above, I would say your approach is likely > correct, just > prevent DT_NEEDED entries from getting added to PMD's. Doing so will > sidestep > loading issue for libraries that may not exist in the filesystem, > but thats ok, > because by all rights, the symbols codified in those needed > libraries should > already be present in the running application (either made available > by the > application having statically linked them, or having the linker load > them from > the proper libraries at run time). > >>> > >>>My 5c is that I'd much rather see the common case (all static or all > >>>shared) > >>>be simple and reliable, which in case of DSOs includes no lying > >>>(whether by > >>>omission or otherwise) about DT_NEEDED, ever. That way the issue is > >>>dealt > >>>once where it belongs. If somebody wants to go down the rabbit hole of > >>>mixed > >>>shared + static linkage, let them dig the hole by themselves :) > >>> > >>This is a fair point. Can DT_NEEDED sections be stripped via tools like > >>objcopy > >>after the build is complete? If so, end users can hack this corner case > >>to work > >>as needed. > > > >Patchelf (http://nixos.org/patchelf.html) appears to support that, but > >given that source is available it'd be easier to just modify the makefiles > >if that's really needed. > > > I think we agree on the issue. > > So I'll be sending a patch to add DT_NEEDED entries to all libraries and > PMDs. The only exception would be librte_eal, which would not have proper > NEEDED entries. > Do we bother adding a
[dpdk-dev] [PATCH 0/8] Improve build process
On 02/12/2015 02:23 PM, Neil Horman wrote: > On Thu, Feb 12, 2015 at 10:03:51AM +, Gonzalez Monroy, Sergio wrote: >> On 12/02/2015 09:22, Panu Matilainen wrote: >>> On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote: >>>>> From: Neil Horman [mailto:nhorman at tuxdriver.com] >>>>> Sent: Friday, January 30, 2015 6:13 PM >>>>> To: Gonzalez Monroy, Sergio >>>>> Cc: Thomas Monjalon; dev at dpdk.org >>>>> Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process >>>>> >>>>> On Fri, Jan 30, 2015 at 05:38:49PM +, Gonzalez Monroy, Sergio >>>>> wrote: >>>> >>>> [snip] >>>> >>>>>> >>>>>> So would it be reasonable to add DT_NEEDED entries to all DPDK >>>>>> libraries >>>>> but EAL? >>>>>> If I understood what you were saying right, we could enforce the >>>>>> 'dependency' in the linker script with something like this: >>>>>> $ cat librte_eal.so >>>>>> INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such >>>>>> linker script for librte_eal.so instead of the soft link once >>>>>> versioning is in place. >>>>>> >>>>> Correct. >>>>> >>>>>> Things that would be missing versus the proposed patch: >>>>>> - As I have mention in previous post, ldd info for EAL library >>>>>> would not >>>>> reflect >>>>>> its dependency to other DPDK libs. >>>>> librte_eal.so would no show those dependencies, as far as I know >>>>> (though I >>>>> haven't explicitly checked). The subordunate libraries included in >>>>> the input >>>>> line, may or may not show dependencies among themselves, depending on >>>>> your build setup (and the use of --no-as-needed and -l when linking the >>>>> individual .so libraries. >>>>> >>>>>> - I was enforcing resolving all references when building the >>>>>> libraries (-z >>>>> defs), so >>>>>> we either remove it altogether or skip eal. >>>>> I think thats correct, yes. >>>>> >>>>>> - All apps would show DT_NEEDED entries for a set of DPDK >>>>>> libraries that >>>>>> in most cases are required (eal, mempool, malloc, mbuf, ring VS >>>>>> dpdk_core) >>>>>> >>>>> I think apps linked to libdpdk_core would have DT_NEEDED entries for >>>>> libdpdk_core, not the subordonate libraries (though check me on that >>>>> to be >>>>> sure). >>>>> >>>> Just checked on this and they do link against the subordinate libraries, >>>> although >>>> It does not really matter as we are dropping the 'core' library approach >>>> anyway. >>>> >>>>>> I think that the linker script approach is reasonable if we prefer to >>>>>> go that way instead of creating a core library. >>>>>> >>>>> I think it would make sense from a build environment point of view, in >>>>> that it >>>>> allows library specific flags to be incorporated properly. I think >>>>> the only >>>>> downside is that the individual libraries still need to be carried >>>>> around >>>>> (though they can be ignored from an application build/run standpoint). >>>>> You're question should probably be asked of people using COMBINED_LIBS >>>>> currently to make sure that meets their needs, though I think it will. >>>>> >>>>> Neil >>>>> >>>> So I just realized that I was not having into account a possible >>>> scenario, where >>>> we have an app built with static dpdk libs then loading a dso with -d >>>> option. >>>> >>>> In such case, because the pmd would have DT_NEEDED entries, dlopen will >>>> fail. >>>> So to enable such scenario we would need to build PMDs without DT_NEEDED >>>> entries. >>> >>> Hmm, for that to be a problem you'd need to have the PMD built against >>> shared dpdk libs and while the application is built against static dpdk >>> libs. I dont think that's a supportable scenario in any case. >>> >>> Or is th
[dpdk-dev] [PATCH 0/8] Improve build process
On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote: >> From: Neil Horman [mailto:nhorman at tuxdriver.com] >> Sent: Friday, January 30, 2015 6:13 PM >> To: Gonzalez Monroy, Sergio >> Cc: Thomas Monjalon; dev at dpdk.org >> Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process >> >> On Fri, Jan 30, 2015 at 05:38:49PM +, Gonzalez Monroy, Sergio wrote: > > [snip] > >>> >>> So would it be reasonable to add DT_NEEDED entries to all DPDK libraries >> but EAL? >>> If I understood what you were saying right, we could enforce the >>> 'dependency' in the linker script with something like this: >>> $ cat librte_eal.so >>> INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such >>> linker script for librte_eal.so instead of the soft link once >>> versioning is in place. >>> >> Correct. >> >>> Things that would be missing versus the proposed patch: >>> - As I have mention in previous post, ldd info for EAL library would not >> reflect >>> its dependency to other DPDK libs. >> librte_eal.so would no show those dependencies, as far as I know (though I >> haven't explicitly checked). The subordunate libraries included in the input >> line, may or may not show dependencies among themselves, depending on >> your build setup (and the use of --no-as-needed and -l when linking the >> individual .so libraries. >> >>> - I was enforcing resolving all references when building the libraries (-z >> defs), so >>> we either remove it altogether or skip eal. >> I think thats correct, yes. >> >>> - All apps would show DT_NEEDED entries for a set of DPDK libraries that >>> in most cases are required (eal, mempool, malloc, mbuf, ring VS >>> dpdk_core) >>> >> I think apps linked to libdpdk_core would have DT_NEEDED entries for >> libdpdk_core, not the subordonate libraries (though check me on that to be >> sure). >> > Just checked on this and they do link against the subordinate libraries, > although > It does not really matter as we are dropping the 'core' library approach > anyway. > >>> I think that the linker script approach is reasonable if we prefer to >>> go that way instead of creating a core library. >>> >> I think it would make sense from a build environment point of view, in that >> it >> allows library specific flags to be incorporated properly. I think the only >> downside is that the individual libraries still need to be carried around >> (though they can be ignored from an application build/run standpoint). >> You're question should probably be asked of people using COMBINED_LIBS >> currently to make sure that meets their needs, though I think it will. >> >> Neil >> > So I just realized that I was not having into account a possible scenario, > where > we have an app built with static dpdk libs then loading a dso with -d option. > > In such case, because the pmd would have DT_NEEDED entries, dlopen will fail. > So to enable such scenario we would need to build PMDs without DT_NEEDED > entries. Hmm, for that to be a problem you'd need to have the PMD built against shared dpdk libs and while the application is built against static dpdk libs. I dont think that's a supportable scenario in any case. Or is there some other scenario that I'm not seeing? - Panu -
[dpdk-dev] [PATCH 0/8] Improve build process
On Thu, Feb 12, 2015 at 04:07:50PM +0200, Panu Matilainen wrote: > On 02/12/2015 02:23 PM, Neil Horman wrote: > >On Thu, Feb 12, 2015 at 10:03:51AM +, Gonzalez Monroy, Sergio wrote: > >>On 12/02/2015 09:22, Panu Matilainen wrote: > >>>On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote: > >>>>>From: Neil Horman [mailto:nhorman at tuxdriver.com] > >>>>>Sent: Friday, January 30, 2015 6:13 PM > >>>>>To: Gonzalez Monroy, Sergio > >>>>>Cc: Thomas Monjalon; dev at dpdk.org > >>>>>Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > >>>>> > >>>>>On Fri, Jan 30, 2015 at 05:38:49PM +, Gonzalez Monroy, Sergio > >>>>>wrote: > >>>> > >>>>[snip] > >>>> > >>>>>> > >>>>>>So would it be reasonable to add DT_NEEDED entries to all DPDK > >>>>>>libraries > >>>>>but EAL? > >>>>>>If I understood what you were saying right, we could enforce the > >>>>>>'dependency' in the linker script with something like this: > >>>>>>$ cat librte_eal.so > >>>>>>INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such > >>>>>>linker script for librte_eal.so instead of the soft link once > >>>>>>versioning is in place. > >>>>>> > >>>>>Correct. > >>>>> > >>>>>>Things that would be missing versus the proposed patch: > >>>>>> - As I have mention in previous post, ldd info for EAL library > >>>>>>would not > >>>>>reflect > >>>>>>its dependency to other DPDK libs. > >>>>>librte_eal.so would no show those dependencies, as far as I know > >>>>>(though I > >>>>>haven't explicitly checked). The subordunate libraries included in > >>>>>the input > >>>>>line, may or may not show dependencies among themselves, depending on > >>>>>your build setup (and the use of --no-as-needed and -l when linking the > >>>>>individual .so libraries. > >>>>> > >>>>>> - I was enforcing resolving all references when building the > >>>>>>libraries (-z > >>>>>defs), so > >>>>>>we either remove it altogether or skip eal. > >>>>>I think thats correct, yes. > >>>>> > >>>>>> - All apps would show DT_NEEDED entries for a set of DPDK > >>>>>>libraries that > >>>>>>in most cases are required (eal, mempool, malloc, mbuf, ring VS > >>>>>>dpdk_core) > >>>>>> > >>>>>I think apps linked to libdpdk_core would have DT_NEEDED entries for > >>>>>libdpdk_core, not the subordonate libraries (though check me on that > >>>>>to be > >>>>>sure). > >>>>> > >>>>Just checked on this and they do link against the subordinate libraries, > >>>>although > >>>>It does not really matter as we are dropping the 'core' library approach > >>>>anyway. > >>>> > >>>>>>I think that the linker script approach is reasonable if we prefer to > >>>>>>go that way instead of creating a core library. > >>>>>> > >>>>>I think it would make sense from a build environment point of view, in > >>>>>that it > >>>>>allows library specific flags to be incorporated properly. I think > >>>>>the only > >>>>>downside is that the individual libraries still need to be carried > >>>>>around > >>>>>(though they can be ignored from an application build/run standpoint). > >>>>>You're question should probably be asked of people using COMBINED_LIBS > >>>>>currently to make sure that meets their needs, though I think it will. > >>>>> > >>>>>Neil > >>>>> > >>>>So I just realized that I was not having into account a possible > >>>>scenario, where > >>>>we have an app built with static dpdk libs then loading a dso with -d > >>>>option. > >>>> > >>>>In such case, because the pmd would have DT_NEEDED entries, dlopen will > >>>>fail
[dpdk-dev] [PATCH 0/8] Improve build process
On 12/02/2015 09:22, Panu Matilainen wrote: > On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote: >>> From: Neil Horman [mailto:nhorman at tuxdriver.com] >>> Sent: Friday, January 30, 2015 6:13 PM >>> To: Gonzalez Monroy, Sergio >>> Cc: Thomas Monjalon; dev at dpdk.org >>> Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process >>> >>> On Fri, Jan 30, 2015 at 05:38:49PM +, Gonzalez Monroy, Sergio >>> wrote: >> >> [snip] >> >>>> >>>> So would it be reasonable to add DT_NEEDED entries to all DPDK >>>> libraries >>> but EAL? >>>> If I understood what you were saying right, we could enforce the >>>> 'dependency' in the linker script with something like this: >>>> $ cat librte_eal.so >>>> INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such >>>> linker script for librte_eal.so instead of the soft link once >>>> versioning is in place. >>>> >>> Correct. >>> >>>> Things that would be missing versus the proposed patch: >>>> - As I have mention in previous post, ldd info for EAL library >>>> would not >>> reflect >>>> its dependency to other DPDK libs. >>> librte_eal.so would no show those dependencies, as far as I know >>> (though I >>> haven't explicitly checked). The subordunate libraries included in >>> the input >>> line, may or may not show dependencies among themselves, depending on >>> your build setup (and the use of --no-as-needed and -l when linking the >>> individual .so libraries. >>> >>>> - I was enforcing resolving all references when building the >>>> libraries (-z >>> defs), so >>>> we either remove it altogether or skip eal. >>> I think thats correct, yes. >>> >>>> - All apps would show DT_NEEDED entries for a set of DPDK >>>> libraries that >>>> in most cases are required (eal, mempool, malloc, mbuf, ring VS >>>> dpdk_core) >>>> >>> I think apps linked to libdpdk_core would have DT_NEEDED entries for >>> libdpdk_core, not the subordonate libraries (though check me on that >>> to be >>> sure). >>> >> Just checked on this and they do link against the subordinate >> libraries, although >> It does not really matter as we are dropping the 'core' library >> approach anyway. >> >>>> I think that the linker script approach is reasonable if we prefer to >>>> go that way instead of creating a core library. >>>> >>> I think it would make sense from a build environment point of view, >>> in that it >>> allows library specific flags to be incorporated properly. I think >>> the only >>> downside is that the individual libraries still need to be carried >>> around >>> (though they can be ignored from an application build/run standpoint). >>> You're question should probably be asked of people using COMBINED_LIBS >>> currently to make sure that meets their needs, though I think it will. >>> >>> Neil >>> >> So I just realized that I was not having into account a possible >> scenario, where >> we have an app built with static dpdk libs then loading a dso with >> -d option. >> >> In such case, because the pmd would have DT_NEEDED entries, dlopen >> will fail. >> So to enable such scenario we would need to build PMDs without DT_NEEDED >> entries. > > Hmm, for that to be a problem you'd need to have the PMD built against > shared dpdk libs and while the application is built against static > dpdk libs. I dont think that's a supportable scenario in any case. > > Or is there some other scenario that I'm not seeing? > > - Panu - > I agree with you. I suppose it comes down to, do we want to support such scenario? From what I can see, it seems that we do currently support such scenario by building dpdk apps against all static dpdk libs using --whole-archive (all libs and not only PMDs). http://dpdk.org/browse/dpdk/commit/?id=20afd76a504155e947c770783ef5023e87136ad8 Am I misunderstanding this? Regards, Sergio
[dpdk-dev] [PATCH 0/8] Improve build process
On 12/02/2015 05:41, Neil Horman wrote: > On Wed, Feb 11, 2015 at 11:11:13AM +, Gonzalez Monroy, Sergio wrote: >>> From: Neil Horman [mailto:nhorman at tuxdriver.com] >>> Sent: Friday, January 30, 2015 6:13 PM >>> To: Gonzalez Monroy, Sergio >>> Cc: Thomas Monjalon; dev at dpdk.org >>> Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process >>> >>> On Fri, Jan 30, 2015 at 05:38:49PM +, Gonzalez Monroy, Sergio wrote: >> [snip] >> >>>> So would it be reasonable to add DT_NEEDED entries to all DPDK libraries >>> but EAL? >>>> If I understood what you were saying right, we could enforce the >>>> 'dependency' in the linker script with something like this: >>>> $ cat librte_eal.so >>>> INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such >>>> linker script for librte_eal.so instead of the soft link once >>>> versioning is in place. >>>> >>> Correct. >>> >>>> Things that would be missing versus the proposed patch: >>>> - As I have mention in previous post, ldd info for EAL library would not >>> reflect >>>> its dependency to other DPDK libs. >>> librte_eal.so would no show those dependencies, as far as I know (though I >>> haven't explicitly checked). The subordunate libraries included in the >>> input >>> line, may or may not show dependencies among themselves, depending on >>> your build setup (and the use of --no-as-needed and -l when linking the >>> individual .so libraries. >>> >>>> - I was enforcing resolving all references when building the libraries >>>> (-z >>> defs), so >>>> we either remove it altogether or skip eal. >>> I think thats correct, yes. >>> >>>> - All apps would show DT_NEEDED entries for a set of DPDK libraries that >>>> in most cases are required (eal, mempool, malloc, mbuf, ring VS >>>> dpdk_core) >>>> >>> I think apps linked to libdpdk_core would have DT_NEEDED entries for >>> libdpdk_core, not the subordonate libraries (though check me on that to be >>> sure). >>> >> Just checked on this and they do link against the subordinate libraries, >> although >> It does not really matter as we are dropping the 'core' library approach >> anyway. >> > ok, understood. > >>>> I think that the linker script approach is reasonable if we prefer to >>>> go that way instead of creating a core library. >>>> >>> I think it would make sense from a build environment point of view, in that >>> it >>> allows library specific flags to be incorporated properly. I think the only >>> downside is that the individual libraries still need to be carried around >>> (though they can be ignored from an application build/run standpoint). >>> You're question should probably be asked of people using COMBINED_LIBS >>> currently to make sure that meets their needs, though I think it will. >>> >>> Neil >>> >> So I just realized that I was not having into account a possible scenario, >> where >> we have an app built with static dpdk libs then loading a dso with -d >> option. >> > This is very true, but I was under the impression that the only things that > were > dlopen-able were PMD's, which would not be part of the core library. Was I > mistaken? As far as I know you are right that only PMDs are being dlopen. The proposed patch though, added DT_NEEDED entries for PMDs too, so they would need to be left empty for them to work in such scenario. Is that reasonable? Regards, Sergio >> In such case, because the pmd would have DT_NEEDED entries, dlopen will fail. >> So to enable such scenario we would need to build PMDs without DT_NEEDED >> entries. >> >> Thoughts? >> > As I mentioned above I thought the only thing that would typically be > referenced > via dlopen would be libraries that were not part of the unified core library. > if thats not the case, then yes, we need a little more thought here > Neil > >> Regards, >> Sergio >>
[dpdk-dev] [PATCH 0/8] Improve build process
On Thu, Feb 12, 2015 at 10:03:51AM +, Gonzalez Monroy, Sergio wrote: > On 12/02/2015 09:22, Panu Matilainen wrote: > >On 02/11/2015 01:11 PM, Gonzalez Monroy, Sergio wrote: > >>>From: Neil Horman [mailto:nhorman at tuxdriver.com] > >>>Sent: Friday, January 30, 2015 6:13 PM > >>>To: Gonzalez Monroy, Sergio > >>>Cc: Thomas Monjalon; dev at dpdk.org > >>>Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > >>> > >>>On Fri, Jan 30, 2015 at 05:38:49PM +, Gonzalez Monroy, Sergio > >>>wrote: > >> > >>[snip] > >> > >>>> > >>>>So would it be reasonable to add DT_NEEDED entries to all DPDK > >>>>libraries > >>>but EAL? > >>>>If I understood what you were saying right, we could enforce the > >>>>'dependency' in the linker script with something like this: > >>>>$ cat librte_eal.so > >>>>INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such > >>>>linker script for librte_eal.so instead of the soft link once > >>>>versioning is in place. > >>>> > >>>Correct. > >>> > >>>>Things that would be missing versus the proposed patch: > >>>> - As I have mention in previous post, ldd info for EAL library > >>>>would not > >>>reflect > >>>>its dependency to other DPDK libs. > >>>librte_eal.so would no show those dependencies, as far as I know > >>>(though I > >>>haven't explicitly checked). The subordunate libraries included in > >>>the input > >>>line, may or may not show dependencies among themselves, depending on > >>>your build setup (and the use of --no-as-needed and -l when linking the > >>>individual .so libraries. > >>> > >>>> - I was enforcing resolving all references when building the > >>>>libraries (-z > >>>defs), so > >>>>we either remove it altogether or skip eal. > >>>I think thats correct, yes. > >>> > >>>> - All apps would show DT_NEEDED entries for a set of DPDK > >>>>libraries that > >>>>in most cases are required (eal, mempool, malloc, mbuf, ring VS > >>>>dpdk_core) > >>>> > >>>I think apps linked to libdpdk_core would have DT_NEEDED entries for > >>>libdpdk_core, not the subordonate libraries (though check me on that > >>>to be > >>>sure). > >>> > >>Just checked on this and they do link against the subordinate libraries, > >>although > >>It does not really matter as we are dropping the 'core' library approach > >>anyway. > >> > >>>>I think that the linker script approach is reasonable if we prefer to > >>>>go that way instead of creating a core library. > >>>> > >>>I think it would make sense from a build environment point of view, in > >>>that it > >>>allows library specific flags to be incorporated properly. I think > >>>the only > >>>downside is that the individual libraries still need to be carried > >>>around > >>>(though they can be ignored from an application build/run standpoint). > >>>You're question should probably be asked of people using COMBINED_LIBS > >>>currently to make sure that meets their needs, though I think it will. > >>> > >>>Neil > >>> > >>So I just realized that I was not having into account a possible > >>scenario, where > >>we have an app built with static dpdk libs then loading a dso with -d > >>option. > >> > >>In such case, because the pmd would have DT_NEEDED entries, dlopen will > >>fail. > >>So to enable such scenario we would need to build PMDs without DT_NEEDED > >>entries. > > > >Hmm, for that to be a problem you'd need to have the PMD built against > >shared dpdk libs and while the application is built against static dpdk > >libs. I dont think that's a supportable scenario in any case. > > > >Or is there some other scenario that I'm not seeing? > > > >- Panu - > > > I agree with you. I suppose it comes down to, do we want to support such > scenario? > > From what I can see, it seems that we do currently support such scenario by > building dpdk apps against all static dpdk libs using --whole-archive (all > libs and not only PMDs). > http://dpd
[dpdk-dev] [PATCH 0/8] Improve build process
On Thu, Feb 12, 2015 at 09:17:39AM +, Gonzalez Monroy, Sergio wrote: > On 12/02/2015 05:41, Neil Horman wrote: > >On Wed, Feb 11, 2015 at 11:11:13AM +, Gonzalez Monroy, Sergio wrote: > >>>From: Neil Horman [mailto:nhorman at tuxdriver.com] > >>>Sent: Friday, January 30, 2015 6:13 PM > >>>To: Gonzalez Monroy, Sergio > >>>Cc: Thomas Monjalon; dev at dpdk.org > >>>Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > >>> > >>>On Fri, Jan 30, 2015 at 05:38:49PM +, Gonzalez Monroy, Sergio wrote: > >>[snip] > >> > >>>>So would it be reasonable to add DT_NEEDED entries to all DPDK libraries > >>>but EAL? > >>>>If I understood what you were saying right, we could enforce the > >>>>'dependency' in the linker script with something like this: > >>>>$ cat librte_eal.so > >>>>INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such > >>>>linker script for librte_eal.so instead of the soft link once > >>>>versioning is in place. > >>>> > >>>Correct. > >>> > >>>>Things that would be missing versus the proposed patch: > >>>> - As I have mention in previous post, ldd info for EAL library would not > >>>reflect > >>>>its dependency to other DPDK libs. > >>>librte_eal.so would no show those dependencies, as far as I know (though I > >>>haven't explicitly checked). The subordunate libraries included in the > >>>input > >>>line, may or may not show dependencies among themselves, depending on > >>>your build setup (and the use of --no-as-needed and -l when linking the > >>>individual .so libraries. > >>> > >>>> - I was enforcing resolving all references when building the libraries > >>>> (-z > >>>defs), so > >>>>we either remove it altogether or skip eal. > >>>I think thats correct, yes. > >>> > >>>> - All apps would show DT_NEEDED entries for a set of DPDK libraries that > >>>>in most cases are required (eal, mempool, malloc, mbuf, ring VS > >>>>dpdk_core) > >>>> > >>>I think apps linked to libdpdk_core would have DT_NEEDED entries for > >>>libdpdk_core, not the subordonate libraries (though check me on that to be > >>>sure). > >>> > >>Just checked on this and they do link against the subordinate libraries, > >>although > >>It does not really matter as we are dropping the 'core' library approach > >>anyway. > >> > >ok, understood. > > > >>>>I think that the linker script approach is reasonable if we prefer to > >>>>go that way instead of creating a core library. > >>>> > >>>I think it would make sense from a build environment point of view, in > >>>that it > >>>allows library specific flags to be incorporated properly. I think the > >>>only > >>>downside is that the individual libraries still need to be carried around > >>>(though they can be ignored from an application build/run standpoint). > >>>You're question should probably be asked of people using COMBINED_LIBS > >>>currently to make sure that meets their needs, though I think it will. > >>> > >>>Neil > >>> > >>So I just realized that I was not having into account a possible scenario, > >>where > >>we have an app built with static dpdk libs then loading a dso with -d > >>option. > >> > >This is very true, but I was under the impression that the only things that > >were > >dlopen-able were PMD's, which would not be part of the core library. Was I > >mistaken? > As far as I know you are right that only PMDs are being dlopen. > The proposed patch though, added DT_NEEDED entries for PMDs too, so they > would need to be > left empty for them to work in such scenario. > > Is that reasonable? > Ah, I see now. What you're saying is that, in our proposed scenario, a PMD that requires, say librte_ether, will have a DT_NEEDED entry explicitly for that library, as opposed to libdpdk_core, is that correct? If it is, I think thats ok. We will still need to have the librte_ether library around, because the libdpdk_core DSO will reference it on its INPUT line, and in fact it should already be loaded because of that, rendering the DT_NEEDED entry moot. That is to say, and requirements from a PMD codified in a DT
[dpdk-dev] [PATCH 0/8] Improve build process
On Wed, Feb 11, 2015 at 11:11:13AM +, Gonzalez Monroy, Sergio wrote: > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > Sent: Friday, January 30, 2015 6:13 PM > > To: Gonzalez Monroy, Sergio > > Cc: Thomas Monjalon; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > On Fri, Jan 30, 2015 at 05:38:49PM +, Gonzalez Monroy, Sergio wrote: > > [snip] > > > > > > > So would it be reasonable to add DT_NEEDED entries to all DPDK libraries > > but EAL? > > > If I understood what you were saying right, we could enforce the > > > 'dependency' in the linker script with something like this: > > > $ cat librte_eal.so > > > INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such > > > linker script for librte_eal.so instead of the soft link once > > > versioning is in place. > > > > > Correct. > > > > > Things that would be missing versus the proposed patch: > > > - As I have mention in previous post, ldd info for EAL library would not > > reflect > > >its dependency to other DPDK libs. > > librte_eal.so would no show those dependencies, as far as I know (though I > > haven't explicitly checked). The subordunate libraries included in the > > input > > line, may or may not show dependencies among themselves, depending on > > your build setup (and the use of --no-as-needed and -l when linking the > > individual .so libraries. > > > > > - I was enforcing resolving all references when building the libraries > > > (-z > > defs), so > > >we either remove it altogether or skip eal. > > I think thats correct, yes. > > > > > - All apps would show DT_NEEDED entries for a set of DPDK libraries that > > >in most cases are required (eal, mempool, malloc, mbuf, ring VS > > > dpdk_core) > > > > > I think apps linked to libdpdk_core would have DT_NEEDED entries for > > libdpdk_core, not the subordonate libraries (though check me on that to be > > sure). > > > Just checked on this and they do link against the subordinate libraries, > although > It does not really matter as we are dropping the 'core' library approach > anyway. > ok, understood. > > > I think that the linker script approach is reasonable if we prefer to > > > go that way instead of creating a core library. > > > > > I think it would make sense from a build environment point of view, in that > > it > > allows library specific flags to be incorporated properly. I think the only > > downside is that the individual libraries still need to be carried around > > (though they can be ignored from an application build/run standpoint). > > You're question should probably be asked of people using COMBINED_LIBS > > currently to make sure that meets their needs, though I think it will. > > > > Neil > > > So I just realized that I was not having into account a possible scenario, > where > we have an app built with static dpdk libs then loading a dso with -d option. > This is very true, but I was under the impression that the only things that were dlopen-able were PMD's, which would not be part of the core library. Was I mistaken? > In such case, because the pmd would have DT_NEEDED entries, dlopen will fail. > So to enable such scenario we would need to build PMDs without DT_NEEDED > entries. > > Thoughts? > As I mentioned above I thought the only thing that would typically be referenced via dlopen would be libraries that were not part of the unified core library. if thats not the case, then yes, we need a little more thought here Neil > Regards, > Sergio >
[dpdk-dev] [PATCH 0/8] Improve build process
> From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Thursday, January 29, 2015 7:46 PM > To: Gonzalez Monroy, Sergio > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > On Thu, Jan 29, 2015 at 05:04:20PM +, Gonzalez Monroy, Sergio wrote: > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > Sent: Thursday, January 29, 2015 4:39 PM > > > To: Gonzalez Monroy, Sergio > > > Cc: dev at dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > > > On Thu, Jan 29, 2015 at 03:20:03PM +, Sergio Gonzalez Monroy > wrote: > > > > This patch series improves the DPDK build system mostly for shared > > > > libraries (and a few nits for static libraries) with the following > > > > goals: > > > > - Create a library containing core DPDK libraries (librte_eal, > > > >librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > > >The idea of core libraries is to group those libraries that are > > > >always required (and have interdependencies) for any DPDK > application. > > > > - Remove config option to build a combined library. > > > > - For shared libraries, explicitly link against dependant > > > >libraries (adding entries to DT_NEEDED). > > > > - Update app linking flags for static/shared DPDK libs. > > > > > > > > Sergio Gonzalez Monroy (8): > > > > mk: remove combined library and related options > > > > core: create new librte_core > > > > mk: new corelib makefile > > > > lib: update DEPDIRS variable > > > > lib: set LDLIBS for each library > > > > mk: use LDLIBS when linking shared libraries > > > > mk: update LDLIBS for app building > > > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > > > > > config/common_bsdapp| 6 -- > > > > config/common_linuxapp | 6 -- > > > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > > > lib/Makefile| 1 - > > > > lib/librte_acl/Makefile | 5 +- > > > > lib/librte_cfgfile/Makefile | 4 +- > > > > lib/librte_cmdline/Makefile | 6 +- > > > > lib/librte_core/Makefile| 45 + > > > > lib/librte_distributor/Makefile | 5 +- > > > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > > > lib/librte_eal/linuxapp/eal/Makefile| 3 +- > > > > lib/librte_ether/Makefile | 4 +- > > > > lib/librte_hash/Makefile| 4 +- > > > > lib/librte_ip_frag/Makefile | 6 +- > > > > lib/librte_ivshmem/Makefile | 4 +- > > > > lib/librte_kni/Makefile | 6 +- > > > > lib/librte_kvargs/Makefile | 6 +- > > > > lib/librte_lpm/Makefile | 6 +- > > > > lib/librte_malloc/Makefile | 2 +- > > > > lib/librte_mbuf/Makefile| 2 +- > > > > lib/librte_mempool/Makefile | 2 +- > > > > lib/librte_meter/Makefile | 4 +- > > > > lib/librte_pipeline/Makefile| 3 + > > > > lib/librte_pmd_af_packet/Makefile | 5 +- > > > > lib/librte_pmd_bond/Makefile| 7 +- > > > > lib/librte_pmd_e1000/Makefile | 8 ++- > > > > lib/librte_pmd_enic/Makefile| 8 ++- > > > > lib/librte_pmd_i40e/Makefile| 8 ++- > > > > lib/librte_pmd_ixgbe/Makefile | 8 ++- > > > > lib/librte_pmd_pcap/Makefile| 5 +- > > > > lib/librte_pmd_ring/Makefile| 6 +- > > > > lib/librte_pmd_virtio/Makefile | 7 +- > > > > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > > > > lib/librte_pmd_xenvirt/Makefile | 8 ++- > > > > lib/librte_port/Makefile| 8 +-- > > > > lib/librte_power/Makefile | 4 +- > > > > lib/librte_ring/Makefile| 2 +- > > > > lib/librte_sched/Makefile | 7 +- > > > > lib/librte_table/Makefile | 8 +-- &g
[dpdk-dev] [PATCH 0/8] Improve build process
On Fri, Jan 30, 2015 at 05:38:49PM +, Gonzalez Monroy, Sergio wrote: > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > Sent: Friday, January 30, 2015 2:05 PM > > To: Gonzalez Monroy, Sergio > > Cc: Thomas Monjalon; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > On Fri, Jan 30, 2015 at 01:39:28PM +, Gonzalez Monroy, Sergio wrote: > > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > > Sent: Thursday, January 29, 2015 7:46 PM > > > > To: Gonzalez Monroy, Sergio > > > > Cc: dev at dpdk.org > > > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > > > > > On Thu, Jan 29, 2015 at 05:04:20PM +, Gonzalez Monroy, Sergio > > wrote: > > > > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > > > > Sent: Thursday, January 29, 2015 4:39 PM > > > > > > To: Gonzalez Monroy, Sergio > > > > > > Cc: dev at dpdk.org > > > > > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > > > > > > > > > On Thu, Jan 29, 2015 at 03:20:03PM +, Sergio Gonzalez Monroy > > > > wrote: > > > > > > > This patch series improves the DPDK build system mostly for > > > > > > > shared libraries (and a few nits for static libraries) with the > > > > > > > following > > goals: > > > > > > > - Create a library containing core DPDK libraries (librte_eal, > > > > > > >librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > > > > > >The idea of core libraries is to group those libraries that are > > > > > > >always required (and have interdependencies) for any DPDK > > > > application. > > > > > > > - Remove config option to build a combined library. > > > > > > > - For shared libraries, explicitly link against dependant > > > > > > >libraries (adding entries to DT_NEEDED). > > > > > > > - Update app linking flags for static/shared DPDK libs. > > > > > > > > > > > > > > Sergio Gonzalez Monroy (8): > > > > > > > mk: remove combined library and related options > > > > > > > core: create new librte_core > > > > > > > mk: new corelib makefile > > > > > > > lib: update DEPDIRS variable > > > > > > > lib: set LDLIBS for each library > > > > > > > mk: use LDLIBS when linking shared libraries > > > > > > > mk: update LDLIBS for app building > > > > > > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > > > > > > > > > > > config/common_bsdapp| 6 -- > > > > > > > config/common_linuxapp | 6 -- > > > > > > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > > > > > > lib/Makefile| 1 - > > > > > > > lib/librte_acl/Makefile | 5 +- > > > > > > > lib/librte_cfgfile/Makefile | 4 +- > > > > > > > lib/librte_cmdline/Makefile | 6 +- > > > > > > > lib/librte_core/Makefile| 45 + > > > > > > > lib/librte_distributor/Makefile | 5 +- > > > > > > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > > > > > > lib/librte_eal/linuxapp/eal/Makefile| 3 +- > > > > > > > lib/librte_ether/Makefile | 4 +- > > > > > > > lib/librte_hash/Makefile| 4 +- > > > > > > > lib/librte_ip_frag/Makefile | 6 +- > > > > > > > lib/librte_ivshmem/Makefile | 4 +- > > > > > > > lib/librte_kni/Makefile | 6 +- > > > > > > > lib/librte_kvargs/Makefile | 6 +- > > > > > > > lib/librte_lpm/Makefile | 6 +- > > > > > > > lib/librte_malloc/Makefile | 2 +- > > > > > > > lib/librte_mbuf/Makefile| 2 +- > > > > > > > lib/librte_mempool/Makefile | 2 +- &g
[dpdk-dev] [PATCH 0/8] Improve build process
On Fri, Jan 30, 2015 at 01:39:28PM +, Gonzalez Monroy, Sergio wrote: > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > Sent: Thursday, January 29, 2015 7:46 PM > > To: Gonzalez Monroy, Sergio > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > On Thu, Jan 29, 2015 at 05:04:20PM +, Gonzalez Monroy, Sergio wrote: > > > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > > > Sent: Thursday, January 29, 2015 4:39 PM > > > > To: Gonzalez Monroy, Sergio > > > > Cc: dev at dpdk.org > > > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > > > > > On Thu, Jan 29, 2015 at 03:20:03PM +, Sergio Gonzalez Monroy > > wrote: > > > > > This patch series improves the DPDK build system mostly for shared > > > > > libraries (and a few nits for static libraries) with the following > > > > > goals: > > > > > - Create a library containing core DPDK libraries (librte_eal, > > > > >librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > > > >The idea of core libraries is to group those libraries that are > > > > >always required (and have interdependencies) for any DPDK > > application. > > > > > - Remove config option to build a combined library. > > > > > - For shared libraries, explicitly link against dependant > > > > >libraries (adding entries to DT_NEEDED). > > > > > - Update app linking flags for static/shared DPDK libs. > > > > > > > > > > Sergio Gonzalez Monroy (8): > > > > > mk: remove combined library and related options > > > > > core: create new librte_core > > > > > mk: new corelib makefile > > > > > lib: update DEPDIRS variable > > > > > lib: set LDLIBS for each library > > > > > mk: use LDLIBS when linking shared libraries > > > > > mk: update LDLIBS for app building > > > > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > > > > > > > config/common_bsdapp| 6 -- > > > > > config/common_linuxapp | 6 -- > > > > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > > > > lib/Makefile| 1 - > > > > > lib/librte_acl/Makefile | 5 +- > > > > > lib/librte_cfgfile/Makefile | 4 +- > > > > > lib/librte_cmdline/Makefile | 6 +- > > > > > lib/librte_core/Makefile| 45 + > > > > > lib/librte_distributor/Makefile | 5 +- > > > > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > > > > lib/librte_eal/linuxapp/eal/Makefile| 3 +- > > > > > lib/librte_ether/Makefile | 4 +- > > > > > lib/librte_hash/Makefile| 4 +- > > > > > lib/librte_ip_frag/Makefile | 6 +- > > > > > lib/librte_ivshmem/Makefile | 4 +- > > > > > lib/librte_kni/Makefile | 6 +- > > > > > lib/librte_kvargs/Makefile | 6 +- > > > > > lib/librte_lpm/Makefile | 6 +- > > > > > lib/librte_malloc/Makefile | 2 +- > > > > > lib/librte_mbuf/Makefile| 2 +- > > > > > lib/librte_mempool/Makefile | 2 +- > > > > > lib/librte_meter/Makefile | 4 +- > > > > > lib/librte_pipeline/Makefile| 3 + > > > > > lib/librte_pmd_af_packet/Makefile | 5 +- > > > > > lib/librte_pmd_bond/Makefile| 7 +- > > > > > lib/librte_pmd_e1000/Makefile | 8 ++- > > > > > lib/librte_pmd_enic/Makefile| 8 ++- > > > > > lib/librte_pmd_i40e/Makefile| 8 ++- > > > > > lib/librte_pmd_ixgbe/Makefile | 8 ++- > > > > > lib/librte_pmd_pcap/Makefile| 5 +- > > > > > lib/librte_pmd_ring/Makefile| 6 +- > > > > > lib/librte_pmd_virtio/Makefile | 7 +- > > > > > lib/librte_pmd_vmxnet3/Makefile
[dpdk-dev] [PATCH 0/8] Improve build process
2015-01-29 11:38, Neil Horman: > On Thu, Jan 29, 2015 at 03:20:03PM +, Sergio Gonzalez Monroy wrote: > > This patch series improves the DPDK build system mostly for shared > > libraries (and a few nits for static libraries) with the following goals: > > - Create a library containing core DPDK libraries (librte_eal, > >librte_malloc, librte_mempool, librte_mbuf and librte_ring). > >The idea of core libraries is to group those libraries that are > >always required (and have interdependencies) for any DPDK application. > > - Remove config option to build a combined library. > > - For shared libraries, explicitly link against dependant > >libraries (adding entries to DT_NEEDED). > > - Update app linking flags for static/shared DPDK libs. > > > > Sergio Gonzalez Monroy (8): > > mk: remove combined library and related options > > core: create new librte_core > > mk: new corelib makefile > > lib: update DEPDIRS variable > > lib: set LDLIBS for each library > > mk: use LDLIBS when linking shared libraries > > mk: update LDLIBS for app building > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > Something occured to me thinking about this patch set. I noticed recently > that > different rules are used to build the shared combined lib from the individual > shared objects. The implication here is that linker options specified in > individual make files (like the LIBABIVER and EXPORT_MAP options in my ABI > versioning script) get ignored, which is bad. Any other file specific linker > options (like _LDFLAGS specified in individual library makefiles are > getting dropped for the combined lib. > > It seems like it would be better if the combined libs were manufactured as > linker scripts themselves (textfiles that used linker directives to include > individual libraries under the covers (see /lib64/libc.so for an example). > > The disadvantage of such an approach are fairly minimal. With such a combined > library, you still need to install individual libraries, but for applications > that wish to link and run against a single dpdk library will still work just > as > they currently do, you can link to just a single library. > > The advantage is clear however. By following a linker script aproach, objects > build as separate libraries are built exactly the same way, using the same > rules > with the same options. It reduces the dpdk build environment size and > complexity, and reduces the opportunity for bugs to creep in from forgetting > to > add build options to multiple locations. It also provides a more granular > approach for grouping files. Creating a dpdk core library becomes a matter of > creating a one line linker script named libdpdk_core.so, rather than > re-arraning > sections of the build system. > > Thoughts? Neil, it seems to be a good idea. I like the idea of making things simpler ;) -- Thomas
[dpdk-dev] [PATCH 0/8] Improve build process
> From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Thursday, January 29, 2015 4:39 PM > To: Gonzalez Monroy, Sergio > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > On Thu, Jan 29, 2015 at 03:20:03PM +, Sergio Gonzalez Monroy wrote: > > This patch series improves the DPDK build system mostly for shared > > libraries (and a few nits for static libraries) with the following goals: > > - Create a library containing core DPDK libraries (librte_eal, > >librte_malloc, librte_mempool, librte_mbuf and librte_ring). > >The idea of core libraries is to group those libraries that are > >always required (and have interdependencies) for any DPDK application. > > - Remove config option to build a combined library. > > - For shared libraries, explicitly link against dependant > >libraries (adding entries to DT_NEEDED). > > - Update app linking flags for static/shared DPDK libs. > > > > Sergio Gonzalez Monroy (8): > > mk: remove combined library and related options > > core: create new librte_core > > mk: new corelib makefile > > lib: update DEPDIRS variable > > lib: set LDLIBS for each library > > mk: use LDLIBS when linking shared libraries > > mk: update LDLIBS for app building > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > config/common_bsdapp| 6 -- > > config/common_linuxapp | 6 -- > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > lib/Makefile| 1 - > > lib/librte_acl/Makefile | 5 +- > > lib/librte_cfgfile/Makefile | 4 +- > > lib/librte_cmdline/Makefile | 6 +- > > lib/librte_core/Makefile| 45 + > > lib/librte_distributor/Makefile | 5 +- > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > lib/librte_eal/linuxapp/eal/Makefile| 3 +- > > lib/librte_ether/Makefile | 4 +- > > lib/librte_hash/Makefile| 4 +- > > lib/librte_ip_frag/Makefile | 6 +- > > lib/librte_ivshmem/Makefile | 4 +- > > lib/librte_kni/Makefile | 6 +- > > lib/librte_kvargs/Makefile | 6 +- > > lib/librte_lpm/Makefile | 6 +- > > lib/librte_malloc/Makefile | 2 +- > > lib/librte_mbuf/Makefile| 2 +- > > lib/librte_mempool/Makefile | 2 +- > > lib/librte_meter/Makefile | 4 +- > > lib/librte_pipeline/Makefile| 3 + > > lib/librte_pmd_af_packet/Makefile | 5 +- > > lib/librte_pmd_bond/Makefile| 7 +- > > lib/librte_pmd_e1000/Makefile | 8 ++- > > lib/librte_pmd_enic/Makefile| 8 ++- > > lib/librte_pmd_i40e/Makefile| 8 ++- > > lib/librte_pmd_ixgbe/Makefile | 8 ++- > > lib/librte_pmd_pcap/Makefile| 5 +- > > lib/librte_pmd_ring/Makefile| 6 +- > > lib/librte_pmd_virtio/Makefile | 7 +- > > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > > lib/librte_pmd_xenvirt/Makefile | 8 ++- > > lib/librte_port/Makefile| 8 +-- > > lib/librte_power/Makefile | 4 +- > > lib/librte_ring/Makefile| 2 +- > > lib/librte_sched/Makefile | 7 +- > > lib/librte_table/Makefile | 8 +-- > > lib/librte_timer/Makefile | 6 +- > > lib/librte_vhost/Makefile | 9 +-- > > mk/exec-env/linuxapp/rte.vars.mk| 2 + > > mk/rte.app.mk | 53 --- > > mk/rte.corelib.mk | 84 +++ > > mk/rte.lib.mk | 49 +++--- > > mk/rte.sdkbuild.mk | 3 - > > mk/rte.sharelib.mk | 101 > > > > mk/rte.vars.mk | 9 --- > > 48 files changed, 276 insertions(+), 282 deletions(-) create mode > > 100644 lib/librte_core/Makefile create mode 100644 mk/rte.corelib.mk > > delete mode 100644 mk/rte.sharelib.mk > > > > -- > > 1.9.3 > > > > > Something occured to me thinking about this patch set. I noticed recently > t
[dpdk-dev] [PATCH 0/8] Improve build process
This patch series improves the DPDK build system mostly for shared libraries (and a few nits for static libraries) with the following goals: - Create a library containing core DPDK libraries (librte_eal, librte_malloc, librte_mempool, librte_mbuf and librte_ring). The idea of core libraries is to group those libraries that are always required (and have interdependencies) for any DPDK application. - Remove config option to build a combined library. - For shared libraries, explicitly link against dependant libraries (adding entries to DT_NEEDED). - Update app linking flags for static/shared DPDK libs. Sergio Gonzalez Monroy (8): mk: remove combined library and related options core: create new librte_core mk: new corelib makefile lib: update DEPDIRS variable lib: set LDLIBS for each library mk: use LDLIBS when linking shared libraries mk: update LDLIBS for app building mk: add -lpthread to linuxapp EXECENV_LDLIBS config/common_bsdapp| 6 -- config/common_linuxapp | 6 -- config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - lib/Makefile| 1 - lib/librte_acl/Makefile | 5 +- lib/librte_cfgfile/Makefile | 4 +- lib/librte_cmdline/Makefile | 6 +- lib/librte_core/Makefile| 45 + lib/librte_distributor/Makefile | 5 +- lib/librte_eal/bsdapp/eal/Makefile | 3 +- lib/librte_eal/linuxapp/eal/Makefile| 3 +- lib/librte_ether/Makefile | 4 +- lib/librte_hash/Makefile| 4 +- lib/librte_ip_frag/Makefile | 6 +- lib/librte_ivshmem/Makefile | 4 +- lib/librte_kni/Makefile | 6 +- lib/librte_kvargs/Makefile | 6 +- lib/librte_lpm/Makefile | 6 +- lib/librte_malloc/Makefile | 2 +- lib/librte_mbuf/Makefile| 2 +- lib/librte_mempool/Makefile | 2 +- lib/librte_meter/Makefile | 4 +- lib/librte_pipeline/Makefile| 3 + lib/librte_pmd_af_packet/Makefile | 5 +- lib/librte_pmd_bond/Makefile| 7 +- lib/librte_pmd_e1000/Makefile | 8 ++- lib/librte_pmd_enic/Makefile| 8 ++- lib/librte_pmd_i40e/Makefile| 8 ++- lib/librte_pmd_ixgbe/Makefile | 8 ++- lib/librte_pmd_pcap/Makefile| 5 +- lib/librte_pmd_ring/Makefile| 6 +- lib/librte_pmd_virtio/Makefile | 7 +- lib/librte_pmd_vmxnet3/Makefile | 8 ++- lib/librte_pmd_xenvirt/Makefile | 8 ++- lib/librte_port/Makefile| 8 +-- lib/librte_power/Makefile | 4 +- lib/librte_ring/Makefile| 2 +- lib/librte_sched/Makefile | 7 +- lib/librte_table/Makefile | 8 +-- lib/librte_timer/Makefile | 6 +- lib/librte_vhost/Makefile | 9 +-- mk/exec-env/linuxapp/rte.vars.mk| 2 + mk/rte.app.mk | 53 --- mk/rte.corelib.mk | 84 +++ mk/rte.lib.mk | 49 +++--- mk/rte.sdkbuild.mk | 3 - mk/rte.sharelib.mk | 101 mk/rte.vars.mk | 9 --- 48 files changed, 276 insertions(+), 282 deletions(-) create mode 100644 lib/librte_core/Makefile create mode 100644 mk/rte.corelib.mk delete mode 100644 mk/rte.sharelib.mk -- 1.9.3
[dpdk-dev] [PATCH 0/8] Improve build process
On Thu, Jan 29, 2015 at 05:04:20PM +, Gonzalez Monroy, Sergio wrote: > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > Sent: Thursday, January 29, 2015 4:39 PM > > To: Gonzalez Monroy, Sergio > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process > > > > On Thu, Jan 29, 2015 at 03:20:03PM +, Sergio Gonzalez Monroy wrote: > > > This patch series improves the DPDK build system mostly for shared > > > libraries (and a few nits for static libraries) with the following goals: > > > - Create a library containing core DPDK libraries (librte_eal, > > >librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > >The idea of core libraries is to group those libraries that are > > >always required (and have interdependencies) for any DPDK application. > > > - Remove config option to build a combined library. > > > - For shared libraries, explicitly link against dependant > > >libraries (adding entries to DT_NEEDED). > > > - Update app linking flags for static/shared DPDK libs. > > > > > > Sergio Gonzalez Monroy (8): > > > mk: remove combined library and related options > > > core: create new librte_core > > > mk: new corelib makefile > > > lib: update DEPDIRS variable > > > lib: set LDLIBS for each library > > > mk: use LDLIBS when linking shared libraries > > > mk: update LDLIBS for app building > > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > > > config/common_bsdapp| 6 -- > > > config/common_linuxapp | 6 -- > > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > > lib/Makefile| 1 - > > > lib/librte_acl/Makefile | 5 +- > > > lib/librte_cfgfile/Makefile | 4 +- > > > lib/librte_cmdline/Makefile | 6 +- > > > lib/librte_core/Makefile| 45 + > > > lib/librte_distributor/Makefile | 5 +- > > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > > lib/librte_eal/linuxapp/eal/Makefile| 3 +- > > > lib/librte_ether/Makefile | 4 +- > > > lib/librte_hash/Makefile| 4 +- > > > lib/librte_ip_frag/Makefile | 6 +- > > > lib/librte_ivshmem/Makefile | 4 +- > > > lib/librte_kni/Makefile | 6 +- > > > lib/librte_kvargs/Makefile | 6 +- > > > lib/librte_lpm/Makefile | 6 +- > > > lib/librte_malloc/Makefile | 2 +- > > > lib/librte_mbuf/Makefile| 2 +- > > > lib/librte_mempool/Makefile | 2 +- > > > lib/librte_meter/Makefile | 4 +- > > > lib/librte_pipeline/Makefile| 3 + > > > lib/librte_pmd_af_packet/Makefile | 5 +- > > > lib/librte_pmd_bond/Makefile| 7 +- > > > lib/librte_pmd_e1000/Makefile | 8 ++- > > > lib/librte_pmd_enic/Makefile| 8 ++- > > > lib/librte_pmd_i40e/Makefile| 8 ++- > > > lib/librte_pmd_ixgbe/Makefile | 8 ++- > > > lib/librte_pmd_pcap/Makefile| 5 +- > > > lib/librte_pmd_ring/Makefile| 6 +- > > > lib/librte_pmd_virtio/Makefile | 7 +- > > > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > > > lib/librte_pmd_xenvirt/Makefile | 8 ++- > > > lib/librte_port/Makefile| 8 +-- > > > lib/librte_power/Makefile | 4 +- > > > lib/librte_ring/Makefile| 2 +- > > > lib/librte_sched/Makefile | 7 +- > > > lib/librte_table/Makefile | 8 +-- > > > lib/librte_timer/Makefile | 6 +- > > > lib/librte_vhost/Makefile | 9 +-- > > > mk/exec-env/linuxapp/rte.vars.mk| 2 + > > > mk/rte.app.mk | 53 --- > > > mk/rte.corelib.mk | 84 +++ > > > mk/rte.lib.mk | 49 +++--- > > > mk/rte.sdkbuild.mk | 3 - > > > mk/rte.sharelib.mk | 101 > &
[dpdk-dev] [PATCH 0/8] Improve build process
On Thu, Jan 29, 2015 at 03:20:03PM +, Sergio Gonzalez Monroy wrote: > This patch series improves the DPDK build system mostly for shared > libraries (and a few nits for static libraries) with the following goals: > - Create a library containing core DPDK libraries (librte_eal, >librte_malloc, librte_mempool, librte_mbuf and librte_ring). >The idea of core libraries is to group those libraries that are >always required (and have interdependencies) for any DPDK application. > - Remove config option to build a combined library. > - For shared libraries, explicitly link against dependant >libraries (adding entries to DT_NEEDED). > - Update app linking flags for static/shared DPDK libs. > > Sergio Gonzalez Monroy (8): > mk: remove combined library and related options > core: create new librte_core > mk: new corelib makefile > lib: update DEPDIRS variable > lib: set LDLIBS for each library > mk: use LDLIBS when linking shared libraries > mk: update LDLIBS for app building > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > config/common_bsdapp| 6 -- > config/common_linuxapp | 6 -- > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > lib/Makefile| 1 - > lib/librte_acl/Makefile | 5 +- > lib/librte_cfgfile/Makefile | 4 +- > lib/librte_cmdline/Makefile | 6 +- > lib/librte_core/Makefile| 45 + > lib/librte_distributor/Makefile | 5 +- > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > lib/librte_eal/linuxapp/eal/Makefile| 3 +- > lib/librte_ether/Makefile | 4 +- > lib/librte_hash/Makefile| 4 +- > lib/librte_ip_frag/Makefile | 6 +- > lib/librte_ivshmem/Makefile | 4 +- > lib/librte_kni/Makefile | 6 +- > lib/librte_kvargs/Makefile | 6 +- > lib/librte_lpm/Makefile | 6 +- > lib/librte_malloc/Makefile | 2 +- > lib/librte_mbuf/Makefile| 2 +- > lib/librte_mempool/Makefile | 2 +- > lib/librte_meter/Makefile | 4 +- > lib/librte_pipeline/Makefile| 3 + > lib/librte_pmd_af_packet/Makefile | 5 +- > lib/librte_pmd_bond/Makefile| 7 +- > lib/librte_pmd_e1000/Makefile | 8 ++- > lib/librte_pmd_enic/Makefile| 8 ++- > lib/librte_pmd_i40e/Makefile| 8 ++- > lib/librte_pmd_ixgbe/Makefile | 8 ++- > lib/librte_pmd_pcap/Makefile| 5 +- > lib/librte_pmd_ring/Makefile| 6 +- > lib/librte_pmd_virtio/Makefile | 7 +- > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > lib/librte_pmd_xenvirt/Makefile | 8 ++- > lib/librte_port/Makefile| 8 +-- > lib/librte_power/Makefile | 4 +- > lib/librte_ring/Makefile| 2 +- > lib/librte_sched/Makefile | 7 +- > lib/librte_table/Makefile | 8 +-- > lib/librte_timer/Makefile | 6 +- > lib/librte_vhost/Makefile | 9 +-- > mk/exec-env/linuxapp/rte.vars.mk| 2 + > mk/rte.app.mk | 53 --- > mk/rte.corelib.mk | 84 +++ > mk/rte.lib.mk | 49 +++--- > mk/rte.sdkbuild.mk | 3 - > mk/rte.sharelib.mk | 101 > > mk/rte.vars.mk | 9 --- > 48 files changed, 276 insertions(+), 282 deletions(-) > create mode 100644 lib/librte_core/Makefile > create mode 100644 mk/rte.corelib.mk > delete mode 100644 mk/rte.sharelib.mk > > -- > 1.9.3 > > Something occured to me thinking about this patch set. I noticed recently that different rules are used to build the shared combined lib from the individual shared objects. The implication here is that linker options specified in individual make files (like the LIBABIVER and EXPORT_MAP options in my ABI versioning script) get ignored, which is bad. Any other file specific linker options (like _LDFLAGS specified in individual library makefiles are getting dropped for the combined lib. It seems like it would be better if the combined libs were manufactured as linker scripts themselves (textfiles that used linker directives to include individual libraries under the covers (see /lib64/libc.so for an example). The disadvantage of such an approach are fairly minimal. With such a combined library, you still need to install individual libraries, but for applications that wish to link and run against a single dpdk library will
