From: Wang YanQing <udknight@gmail.com>
To: Yonghong Song <yhs@fb.com>
Cc: "ast@kernel.org" <ast@kernel.org>,
"daniel@iogearbox.net" <daniel@iogearbox.net>,
Martin Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
"shuah@kernel.org" <shuah@kernel.org>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] selftests/bpf: fix compile errors with older glibc
Date: Fri, 19 Apr 2019 02:00:49 +0800 [thread overview]
Message-ID: <20190418180049.GA4716@udknight> (raw)
In-Reply-To: <ecd56ebd-d19f-8834-9373-088ad7c9a725@fb.com>
On Thu, Apr 18, 2019 at 05:09:53AM +0000, Yonghong Song wrote:
>
>
> On 4/17/19 10:48 AM, Wang YanQing wrote:
> > The older glibc (for example, 2.23) doesn't handle __UAPI_DEF_*
> > in libc-compat.h properly, and it bring below compile errors:
>
> I have an even old glibc 2.17 and it still works. Not sure
> why it failed here. Could you explain more?
We will meet these errors with the combination of some versions of kernel headers and
some versions of glibc headers.
After some research on the git history of glibc and kernel, I find the reason behind
the scene is a little complex:
There are some same definitions between glibc's netinet/in.h and kernel's linux/in6.h,
IPPROTO_HOPOPTS, etc.
These same definitions willn't bring trouble when we include both of them if kernel and
glibc coordinates with each other well, but the reality is the coordination is poor and
unsynchronous in history.
Kernel and glibc uses guard macros to detect whether need to export their definitions,
linux/in6.h includes libc-compat.h which will check the guard macro, _NETINET_IN_H, and
netinet/in.h includes bits/in.h which will check the guard macro, _UAPI_LINUX_IN6_H
(glibc-2.19~821 6c82a2f8d7c8e21e39237225c819f182ae438db3 "Coordinate IPv6 definitions for Linux and glibc"),
the problem is in the installation process of kernel headers, the "_UAPI" in _UAPI_LINUX_IN6_H
in linux/in6.h will be stripped due to commit 56c176c9cac9
("UAPI: strip the _UAPI prefix from header guards during header installation").
The good news is the glibc fix this the trouble by checking the guard macro, _LINUX_IN6_H, too.
(glibc c9bd40daaee18cf1d9824e4a7ebaebe321e0a5a8 "Bug 20214: Fix linux/in6.h and netinet/in.h sync.").
My environment still have this trouble:
lsb_release -a:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial
dpkg -l | grep libc-dev:
ii libc-dev-bin 2.23-0ubuntu11 amd64 GNU C Library: Development binaries
ii linux-libc-dev:amd64 4.4.0-145.171 amd64 Linux Kernel Headers for development.
I will send out the v2 which I will change some words in changelog.
Thanks for review.
next prev parent reply other threads:[~2019-04-18 18:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 17:48 [PATCH] selftests/bpf: fix compile errors with older glibc Wang YanQing
2019-04-18 5:09 ` Yonghong Song
2019-04-18 17:11 ` Wang YanQing
2019-04-18 18:00 ` Wang YanQing [this message]
2019-04-18 20:33 ` Yonghong Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190418180049.GA4716@udknight \
--to=udknight@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kafai@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox