[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h

Matthew Hall mhall at mhcomputing.net
Fri Jul 25 16:44:37 CEST 2014


If the bare metal mode is getting yanked, then I think we can go with Antti's advice and just yank the conflicting symbols and use the system versions.
-- 
Sent from my mobile device.

On July 25, 2014 7:40:02 AM PDT, Antti Kantee <pooka at fixup.fi> 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 
>environment.  Especially in that case you do not want definitions based
>
>on hackish assumptions of some particular version of some particular 
>host implementation.  However, I'm not trying to argue if DPDK should
>or 
>shouldn't be that, just that you should either dramatically improve the
>
>current implementation or nuke it.



More information about the dev mailing list