From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0369112049199843590==" MIME-Version: 1.0 From: Daniel Verkamp Subject: Re: [SPDK] DPDK Date: Wed, 02 Nov 2016 09:18:30 -0700 Message-ID: In-Reply-To: 87F08F71-DB4F-4118-8C17-DC184BC37F54@cloudsimple.com List-ID: To: spdk@lists.01.org --===============0369112049199843590== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 11/02/2016 04:47 AM, Kumaraparameshwaran Rathnavel wrote: > Hi All, > > I am writing an application similar to nvmf target in SPDK. I should not = use the Makefile format given for nvmf target. I am having my own cmake fil= e and I have included libraries and header files from DPDK and SPDK. My app= lication core dumps at rte_mempool_create. When I use the same code and the= format of the Makefile in nvmf target it doesn't. I can see that I am miss= ing some flags r something. Can any one help me? Is there an implementation= of Makefiles of nvmf target in SPDK with cmake > > Thanking you, > Param Hi Param, We would have to see a backtrace to be sure, but it is likely that your = build system is not linking the DPDK libraries correctly. If you are = using DPDK 16.07 or newer built as static libraries, you need to link = the rte_* libraries with the -Wl,--whole-archive linker option to ensure = none of the object files that contain only constructors get eliminated. = Some of the mempool functionality was made pluggable and moved to = initialization in constructors in DPDK 16.07, and if you fail to link = the libraries this way, you will end up with NULL function pointers. = Alternatively, you can just use a shared library build of DPDK. See commit 20c11032aecc9678b415dc1861607d5f46ec34ef in SPDK for how this = issue was fixed in our Makefile build system. Thanks, -- Daniel --===============0369112049199843590==--