-----Original Message----- From: Burakov, Anatoly [mailto:anatoly.bura...@intel.com] Sent: Tuesday, November 13, 2018 1:39 AM To: Thomas Monjalon; Burdick, Cliff Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs
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://github.com/lagopus/vsw 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.
