31 May
2017
31 May
'17
11:41 p.m.
From: "Anthony G. Basile" <blueness(a)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(a)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
21 Jun
21 Jun
7:16 p.m.
New subject: [PATCH] include/features.h: add _DEFAULT_SOURCE macro
Hello,
On Wed, 31 May 2017 23:41:26 +0000, Anthony G. Basile wrote:
From: "Anthony G. Basile"
<blueness(a)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(a)gentoo.org>
This patch breaks the build of the "knock" package in Buildroot:
http://autobuild.buildroot.net/results/908/90863b5adb769a346acd3dc4bbe8d5fa…
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
8:11 p.m.
New subject: [PATCH] include/features.h: add _DEFAULT_SOURCE macro
Hi,
Thomas Petazzoni wrote,
Hello,
On Wed, 31 May 2017 23:41:26 +0000, Anthony G. Basile wrote:
As it seems to compile fine for glibc based toolchain, it is a
regression in uClibc-ng.
best regards
Waldemar
From: "Anthony G. Basile"
<blueness(a)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(a)gentoo.org>
This patch breaks the build of the "knock" package in Buildroot:
http://autobuild.buildroot.net/results/908/90863b5adb769a346acd3dc4bbe8d5fa…
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?
22 Jun
22 Jun
12:33 p.m.
New subject: [PATCH] include/features.h: add _DEFAULT_SOURCE macro
On 6/21/17 4:11 PM, Waldemar Brodkorb wrote:
Hi,
Thomas Petazzoni 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.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : basile(a)freeharbor.net
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
Hello,
On Wed, 31 May 2017 23:41:26 +0000, Anthony G. Basile wrote:
As it
seems to compile fine for glibc based toolchain, it is a
regression in uClibc-ng.
best regards
Waldemar From: "Anthony G. Basile"
<blueness(a)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(a)gentoo.org>
This patch breaks the
build of the "knock" package in Buildroot:
http://autobuild.buildroot.net/results/908/90863b5adb769a346acd3dc4bbe8d5fa…
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?
12:37 p.m.
New subject: [PATCH] include/features.h: add _DEFAULT_SOURCE macro
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
12:47 p.m.
New subject: [PATCH] include/features.h: add _DEFAULT_SOURCE macro
On 6/22/17 8:37 AM, Thomas Petazzoni wrote:
Hello,
On Thu, 22 Jun 2017 08:33:31 -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.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : basile(a)freeharbor.net
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
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
1:06 p.m.
New subject: [PATCH] include/features.h: add _DEFAULT_SOURCE macro
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
1:37 p.m.
New subject: [PATCH] include/features.h: add _DEFAULT_SOURCE macro
On 6/22/17 9:06 AM, Thomas Petazzoni wrote:
Hello,
On Thu, 22 Jun 2017 08:47:06 -0400, Anthony G. Basile wrote:
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(a)gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
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
9:59 p.m.
New subject: [PATCH] include/features.h: add _DEFAULT_SOURCE macro
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
2710
days inactive
2732
days old
8 comments
4 participants
participants (4)
-
Anthony G. Basile -
Anthony G. Basile -
Thomas Petazzoni -
Waldemar Brodkorb