From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Hall Subject: Re: symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h Date: Fri, 25 Jul 2014 07:44:37 -0700 Message-ID: <8d2a5eff-ea7c-4035-95ec-1e391c1cda38@email.android.com> References: <20140724075918.GA21277@mhcomputing.net> <53D18EFF.8080804@fixup.fi> <1432797.FfhxlLyX1P@xps13> <53D26C42.3060907@fixup.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To: Antti Kantee , Thomas Monjalon , dev-VfR2kkLFssw@public.gmane.org Return-path: In-Reply-To: <53D26C42.3060907-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" If the bare metal mode is getting yanked, then I think we can go with Ant= ti's advice and just yank the conflicting symbols and use the system vers= ions. --=20 Sent from my mobile device. On July 25, 2014 7:40:02 AM PDT, Antti Kantee wrote: >On 25/07/14 10:43, Thomas Monjalon wrote: >>> 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) > >One reason is if you want DPDK to be a portable network programming=20 >environment. Especially in that case you do not want definitions based > >on hackish assumptions of some particular version of some particular=20 >host implementation. However, I'm not trying to argue if DPDK should >or=20 >shouldn't be that, just that you should either dramatically improve the > >current implementation or nuke it.