From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h Date: Fri, 25 Jul 2014 12:43:15 +0200 Message-ID: <1432797.FfhxlLyX1P@xps13> References: <20140724075918.GA21277@mhcomputing.net> <53D18EFF.8080804@fixup.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit To: dev-VfR2kkLFssw@public.gmane.org Return-path: In-Reply-To: <53D18EFF.8080804-jIVgJlTk8bs@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hi all, 2014-07-24 22:55, Antti Kantee: > On 24/07/14 07:59, Matthew Hall wrote: > > I ran into some weird symbol conflicts between system netinet/in.h and DPDK > > rte_ip.h. They have a lot of duplicated definitions for stuff like IPPROTO_IP > > and so on. This breaks when you want to use inet_pton from arpa/inet.h, > > because it includes netinet/in.h to define struct in_addr. [...] > Again, I recommend steering away from any tightrope approaches that > "know" which types are non-conflicting, or pick out half-and-half from > the host and IP stack. "Do, or do not, there is no half-and-half" The general problem here is that DPDK is conflicting with libc. So the obvious question would be: "why DPDK needs to redefine libc stuff"? I don't see any obvious answer since bare metal is planned to be removed. (see http://dpdk.org/ml/archives/dev/2014-June/003868.html) Objections? -- Thomas