Message ID | 20170531234126.28218-1-basile@freeharbor.net |
---|---|
State | Accepted |
Headers | show |
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/90863b5adb769a346acd3dc4bbe8d5fa497a0581/build-end.log 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
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/90863b5adb769a346acd3dc4bbe8d5fa497a0581/build-end.log > > 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/90863b5adb769a346acd3dc4bbe8d5fa497a0581/build-end.log >> >> 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.
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
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.
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
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?
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 && \