13/11/2018 17:38, Burdick, Cliff:
> 
> -----Original Message-----
> From: Thomas Monjalon [mailto:tho...@monjalon.net] 
> Sent: Tuesday, November 13, 2018 8:07 AM
> To: Burdick, Cliff
> Cc: Burakov, Anatoly; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is 
> missing tailqs
> 
> 13/11/2018 16:45, Burdick, Cliff:
> > From: Burakov, Anatoly [mailto:anatoly.bura...@intel.com]
> > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > 13/11/2018 00:33, Burdick, Cliff:
> > > >> This patch was submitted by Jean Tourrilhes over two years ago, 
> > > >> but didn't receive any responses. I hit the same issue recently 
> > > >> when trying to use cgo (Golang) as a primary process linked to 
> > > >> libdpdk.a against a C++ application linked against the same 
> > > >> library.> > >
> > > > 
> > > > The question is to know why you don't have the same constructors 
> > > > in primary and seconday?
> > > 
> > > I've hit similar things in the past. I believe it was caused by our build 
> > > system stripping out unused libraries (such as rte_hash) from the binary 
> > > and thus not calling the constructor in the primary, but doing so in the 
> > > secondary (or something to that effect).
> > > In any case, this is caused by linking different number of libraries to 
> > > primary and secondary, and should probably be fixed in the build system, 
> > > not in the tailqs code (unless we specifically support having different 
> > > linked libraries to primary and secondary?).
> > 
> > Right, I think the original author of the patch stated the reasons in the 
> > link I provided. The build system seems like the most appropriate place to 
> > fix it, but the patch got me going quickly. I think the question is whether 
> > you want DPDK to support these other ways of linking. I'm certainly not the 
> > first to use cgo, since there's a virtual switch project doing the same:
> > 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lagopu
> > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOG
> > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=hQqVCNwW7eoEzB_hLFK97i8idS8FIqX
> > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e=
> > 
> > They don't use primary/secondary processes, though, so the issue is never 
> > hit. I'm in a situation where using cgo seemed like the easiest path to 
> > accomplish what I'm doing since I needed specialized libraries for it that 
> > were not available in C/C++. At some point I bet someone would use Cython 
> > to start linking against DPDK as well, and we'd likely run into the same 
> > issue.
> 
> >For sure, we want to support using DPDK with cgo or cython.
> >But it is not clear what is the relation with not having the same 
> >compilation for primary and secondary. Please could you elaborate?
> 
> Hi Thomas, I think Jean explained it well here: 
> https://dev.dpdk.narkive.com/ZM3a7QD1/dpdk-dev-bug-static-constructors-considered-evil
> 
> "The build system of the application does not have all the
> subtelties of the DPDK build system, and ends up including *all* the
> constructors, wether they are used or not in the code. Moreover, they
> are included in a different order. Actually, by default the builds
> include no constructors at all (which is a big fail), so the library
> needs to be included with --whole-archive (see Snort DPDK
> instructions)."
> 
> I will get to the bottom of my exact case to understand what's happening, but 
> my primary application is a cgo application that I'm linking to by using 
> almost exactly the same flags that are used in the DPDK build system to build 
> examples. The DPDK libraries I'm linking against is a single location for 
> both primary and secondary; in other words, I don't build DPDK twice. 

OK I understand, thanks.

> You had alluded to a pkg-config for DPDK in the 2015 thread, which cgo can 
> use, but I don't know if that ever was implemented. Cgo can use pkg-config if 
> it's available, otherwise the only tools are specifying LDFLAGS and CFLAGS 
> into their build system.

Yes, the right answer is still pkg-config :)
The good news is that it is now implemented thanks to the meson build system:
        http://git.dpdk.org/dpdk/tree/doc/build-sdk-meson.txt#n182



Reply via email to