[PATCH] include/features.h: add _DEFAULT_SOURCE macro
From: "Anthony G. Basile" <blueness@gentoo.org> man feature_test_macros(7) specifies that _BSD_SOURCE and _SVID_SOURCE have been deprecated in favor of _DEFAULT_SOURCE since libc 2.20. Specifying either of the former is now equivalent to specifying just the latter. We add this macro to conform to this standard, but do not add the compiler warning to maintain full backwards compatibility with earlier version of glibc and uclibc. Signed-off-by: Anthony G. Basile <blueness@gentoo.org> --- include/features.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/include/features.h b/include/features.h index f9820791b..362b811fd 100644 --- a/include/features.h +++ b/include/features.h @@ -40,6 +40,7 @@ _SVID_SOURCE ISO C, POSIX, and SVID things. _ATFILE_SOURCE Additional *at interfaces. _GNU_SOURCE All of the above, plus GNU extensions. + _DEFAULT_SOURCE Equivalent to defining _BSD_SOURCE and _SVID_SOURCE. _REENTRANT Select additionally reentrant object. _THREAD_SAFE Same as _REENTRANT, often used by other systems. _FORTIFY_SOURCE If set to numeric value > 0 additional security @@ -140,6 +141,19 @@ # define __GNUC_PREREQ(maj, min) 0 #endif +/* _DEFAULT_SOURCE is equivalent to defining _BSD_SOURCE and _SVID_SOURCE + * and vice versa. */ +#ifdef _DEFAULT_SOURCE +# undef _BSD_SOURCE +# define _BSD_SOURCE 1 +# undef _SVID_SOURCE +# define _SVID_SOURCE 1 +#endif + +#if defined _BSD_SOURCE || defined _SVID_SOURCE +# undef _DEFAULT_SOURCE +# define _DEFAULT_SOURCE 1 +#endif /* If _BSD_SOURCE was defined by the user, favor BSD over POSIX. */ #if defined _BSD_SOURCE && \ -- 2.13.0
Hello, On Wed, 31 May 2017 23:41:26 +0000, Anthony G. Basile wrote:
From: "Anthony G. Basile" <blueness@gentoo.org>
man feature_test_macros(7) specifies that _BSD_SOURCE and _SVID_SOURCE have been deprecated in favor of _DEFAULT_SOURCE since libc 2.20. Specifying either of the former is now equivalent to specifying just the latter. We add this macro to conform to this standard, but do not add the compiler warning to maintain full backwards compatibility with earlier version of glibc and uclibc.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
This patch breaks the build of the "knock" package in Buildroot: http://autobuild.buildroot.net/results/908/90863b5adb769a346acd3dc4bbe8d5fa4... src/knockd.c:1296:37: error: 'struct tcphdr' has no member named 'th_flags' The tcphdr structure is defined in uClibc in two different ways, depending on whether _FAVOR_BSD is defined or not. If _FAVOR_BSD is defined, then the structure does have this th_flags member, otherwise not. _FAVOR_BSD is defined as follows: #if defined _BSD_SOURCE && \ !(defined _POSIX_SOURCE || defined _POSIX_C_SOURCE || \ defined _XOPEN_SOURCE || defined _XOPEN_SOURCE_EXTENDED || \ defined _GNU_SOURCE || defined _SVID_SOURCE) # define __FAVOR_BSD 1 #endif When being built, the program passes both -D_BSD_SOURCE and -D_DEFAULT_SOURCE. However, this patch has the effect that defining _DEFAULT_SOURCE defines _SVID_SOURCE, which has the side effect of no longer defining _FAVOR_BSD. The definition of _DEFAULT_SOURCE is that it is equivalent to defining _BSD_SOURCE and _SVID_SOURCE. However, it turns out that in the context of uClibc, defining _SVID_SOURCE prevents __FAVOR_BSD from being defined. Where is the bug? In what the knock build system is doing, or in uClibc? Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Hi, Thomas Petazzoni wrote,
Hello,
On Wed, 31 May 2017 23:41:26 +0000, Anthony G. Basile wrote:
From: "Anthony G. Basile" <blueness@gentoo.org>
man feature_test_macros(7) specifies that _BSD_SOURCE and _SVID_SOURCE have been deprecated in favor of _DEFAULT_SOURCE since libc 2.20. Specifying either of the former is now equivalent to specifying just the latter. We add this macro to conform to this standard, but do not add the compiler warning to maintain full backwards compatibility with earlier version of glibc and uclibc.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
This patch breaks the build of the "knock" package in Buildroot:
http://autobuild.buildroot.net/results/908/90863b5adb769a346acd3dc4bbe8d5fa4...
src/knockd.c:1296:37: error: 'struct tcphdr' has no member named 'th_flags'
The tcphdr structure is defined in uClibc in two different ways, depending on whether _FAVOR_BSD is defined or not. If _FAVOR_BSD is defined, then the structure does have this th_flags member, otherwise not.
_FAVOR_BSD is defined as follows:
#if defined _BSD_SOURCE && \ !(defined _POSIX_SOURCE || defined _POSIX_C_SOURCE || \ defined _XOPEN_SOURCE || defined _XOPEN_SOURCE_EXTENDED || \ defined _GNU_SOURCE || defined _SVID_SOURCE) # define __FAVOR_BSD 1 #endif
When being built, the program passes both -D_BSD_SOURCE and -D_DEFAULT_SOURCE. However, this patch has the effect that defining _DEFAULT_SOURCE defines _SVID_SOURCE, which has the side effect of no longer defining _FAVOR_BSD.
The definition of _DEFAULT_SOURCE is that it is equivalent to defining _BSD_SOURCE and _SVID_SOURCE. However, it turns out that in the context of uClibc, defining _SVID_SOURCE prevents __FAVOR_BSD from being defined.
Where is the bug? In what the knock build system is doing, or in uClibc?
As it seems to compile fine for glibc based toolchain, it is a regression in uClibc-ng. best regards Waldemar
On 6/21/17 4:11 PM, Waldemar Brodkorb wrote:
Hi, Thomas Petazzoni wrote,
Hello,
On Wed, 31 May 2017 23:41:26 +0000, Anthony G. Basile wrote:
From: "Anthony G. Basile" <blueness@gentoo.org>
man feature_test_macros(7) specifies that _BSD_SOURCE and _SVID_SOURCE have been deprecated in favor of _DEFAULT_SOURCE since libc 2.20. Specifying either of the former is now equivalent to specifying just the latter. We add this macro to conform to this standard, but do not add the compiler warning to maintain full backwards compatibility with earlier version of glibc and uclibc.
Signed-off-by: Anthony G. Basile <blueness@gentoo.org> This patch breaks the build of the "knock" package in Buildroot:
http://autobuild.buildroot.net/results/908/90863b5adb769a346acd3dc4bbe8d5fa4...
src/knockd.c:1296:37: error: 'struct tcphdr' has no member named 'th_flags'
The tcphdr structure is defined in uClibc in two different ways, depending on whether _FAVOR_BSD is defined or not. If _FAVOR_BSD is defined, then the structure does have this th_flags member, otherwise not.
_FAVOR_BSD is defined as follows:
#if defined _BSD_SOURCE && \ !(defined _POSIX_SOURCE || defined _POSIX_C_SOURCE || \ defined _XOPEN_SOURCE || defined _XOPEN_SOURCE_EXTENDED || \ defined _GNU_SOURCE || defined _SVID_SOURCE) # define __FAVOR_BSD 1 #endif
When being built, the program passes both -D_BSD_SOURCE and -D_DEFAULT_SOURCE. However, this patch has the effect that defining _DEFAULT_SOURCE defines _SVID_SOURCE, which has the side effect of no longer defining _FAVOR_BSD.
The definition of _DEFAULT_SOURCE is that it is equivalent to defining _BSD_SOURCE and _SVID_SOURCE. However, it turns out that in the context of uClibc, defining _SVID_SOURCE prevents __FAVOR_BSD from being defined.
Where is the bug? In what the knock build system is doing, or in uClibc? As it seems to compile fine for glibc based toolchain, it is a regression in uClibc-ng.
best regards Waldemar
I just did a grep of glibc master/HEAD and it looks like __FAVOR_BSD has been removed. If we remove __FAVOR_BSD from uclibc, will buildroot stuff build fine? You can test by just removing those lines from features.h and forcing undef __FAVOR_BSD. If it works, I can produce a patch. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : basile@freeharbor.net GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Hello, On Thu, 22 Jun 2017 08:33:31 -0400, Anthony G. Basile wrote:
I just did a grep of glibc master/HEAD and it looks like __FAVOR_BSD has been removed. If we remove __FAVOR_BSD from uclibc, will buildroot stuff build fine? You can test by just removing those lines from features.h and forcing undef __FAVOR_BSD. If it works, I can produce a patch.
Well, "Buildroot stuff" is very vague. Are you talking about such this "knock" package of the ~2000 packages that Buildroot has? If you provide a patch, I can quickly validate if it fixes the knock package. However, if you want to be sure it doesn't cause regressions for other packages, I would have to commit this patch in Buildroot, so that it gets tested by our automated testing infrastructure. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
On 6/22/17 8:37 AM, Thomas Petazzoni wrote:
Hello,
On Thu, 22 Jun 2017 08:33:31 -0400, Anthony G. Basile wrote:
I just did a grep of glibc master/HEAD and it looks like __FAVOR_BSD has been removed. If we remove __FAVOR_BSD from uclibc, will buildroot stuff build fine? You can test by just removing those lines from features.h and forcing undef __FAVOR_BSD. If it works, I can produce a patch. Well, "Buildroot stuff" is very vague. Are you talking about such this "knock" package of the ~2000 packages that Buildroot has?
If you provide a patch, I can quickly validate if it fixes the knock package. However, if you want to be sure it doesn't cause regressions for other packages, I would have to commit this patch in Buildroot, so that it gets tested by our automated testing infrastructure.
Best regards,
Thomas
Yes, I'm worried about regressions. __FAVOR_BSD is still used in the following: include/setjmp.h include/unistd.h include/signal.h include/features.h include/netinet/udp.h and deals with the differences in which signals and long jmps were handled in older BSD. I don't know buildroot that well, but if you grep the tree, will it show where __FAVOR_BSD is used? Or does it (like gentoo's portage) pull in source code as it builds. I assume the latter so grepping is probably insufficient. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : basile@freeharbor.net GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Hello, On Thu, 22 Jun 2017 08:47:06 -0400, Anthony G. Basile wrote:
Yes, I'm worried about regressions. __FAVOR_BSD is still used in the following:
include/setjmp.h include/unistd.h include/signal.h include/features.h include/netinet/udp.h
and deals with the differences in which signals and long jmps were handled in older BSD. I don't know buildroot that well, but if you grep the tree, will it show where __FAVOR_BSD is used? Or does it (like gentoo's portage) pull in source code as it builds. I assume the latter so grepping is probably insufficient.
Buildroot is a build system, it doesn't contain code. It downloads the source code of the selected packages, as part of the build process. In addition, the knock package is not using __FAVOR_BSD anywhere, so this problematic package would not even match on a grep __FAVOR_BSD. What knock package is doing is that it assumes a BSD-style definition of tcphdr will be provided if _BSD_SOURCE and _SVID_SOURCE are defined. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
On 6/22/17 9:06 AM, Thomas Petazzoni wrote:
Hello,
On Thu, 22 Jun 2017 08:47:06 -0400, Anthony G. Basile wrote:
Yes, I'm worried about regressions. __FAVOR_BSD is still used in the following:
include/setjmp.h include/unistd.h include/signal.h include/features.h include/netinet/udp.h
and deals with the differences in which signals and long jmps were handled in older BSD. I don't know buildroot that well, but if you grep the tree, will it show where __FAVOR_BSD is used? Or does it (like gentoo's portage) pull in source code as it builds. I assume the latter so grepping is probably insufficient.
Buildroot is a build system, it doesn't contain code. It downloads the source code of the selected packages, as part of the build process.
In addition, the knock package is not using __FAVOR_BSD anywhere, so this problematic package would not even match on a grep __FAVOR_BSD. What knock package is doing is that it assumes a BSD-style definition of tcphdr will be provided if _BSD_SOURCE and _SVID_SOURCE are defined.
Best regards,
Thomas
Can you take a look at include/signal.h and tell me if knocks wants __FAVOR_BSD defined or not? More generally, if _BSD_SOURCE and _SVID_SOURCE are defined, do we want __FAVOR_BSD automatically defined as well? -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Hi Thomas, Anthony, Anthony G. Basile wrote,
On 6/22/17 9:06 AM, Thomas Petazzoni wrote:
Hello,
On Thu, 22 Jun 2017 08:47:06 -0400, Anthony G. Basile wrote:
Yes, I'm worried about regressions. __FAVOR_BSD is still used in the following:
include/setjmp.h include/unistd.h include/signal.h include/features.h include/netinet/udp.h
Glibc removed __FAVOR_BSD for a while. I think we should just follow this way. I will add following patch soon. best regards Waldemar
participants (4)
-
Anthony G. Basile -
Anthony G. Basile -
Thomas Petazzoni -
Waldemar Brodkorb