Created attachment 10417 [details] patch disabling float128 Hi, I'm trying to update to glibc 2.26 in Buildroot but I encounter the same build issue with some C++ programs or libraries (mesa, kodi, jsoncpp for now). Each issue can be fixed easily but this means that we can't use "std::fpclassify" anymore. See: [mesa] http://patchwork.ozlabs.org/patch/809139/ [kodi] http://patchwork.ozlabs.org/patch/809146/ [jsoncpp] http://patchwork.ozlabs.org/patch/809144/ git bisect return the offending commit: https://sourceware.org/git/?p=glibc.git;a=commit;h=c86ed71d633c22d6f638576f7660c52a5f783d66 As a workaround I disabled float128 on x86 and x86_64 and the C++ issue is gone. But this is not a good solution... I haven't find any bug report about this. Can you have a look? Best regards, Romain Naour
Adding some details for each packages: mesa3d: mesa is adding the following function from the std namespace to the global namespace. error: « std::fpclassify » was not declared in this scope error: « std::isfinite » was not declared in this scope error: « std::isinf » was not declared in this scope error: « std::isnan » was not declared in this scope error: « std::isnormal » was not declared in this scope error: « std::signbit » was not declared in this scope error: « std::isgreater » was not declared in this scope error: « std::isgreaterequal » was not declared in this scope error: « std::isless » was not declared in this scope error: « std::islessequal » was not declared in this scope error: « std::islessgreater » was not declared in this scope error: « std::isunordered » was not declared in this scope kodi: kodi is using std::isnan in their code leading to the same build issue but with a different error message. error: '__builtin_isnan' is not a member of 'std' jsoncpp: Like for mesa and kodi, isfinite is used from the std namespace. error: 'isfinite' is not a member of 'std' Best regards, Romain Naour
To confirm: are you using a version of 2.26 branch recent enough to include Gabriel's backports for bug 21930 (58270c0049404ef2f878fdd45df55f17f0b8c1f7, 35dded99a89db873b06270ca7f21245a0faf712a, ef8566d72af5e03c1b82cf02efb794268a347f8c, 5e989c36934d0f0cf13b7a53ef2fa440bce39210, c2921b17a37e887b8a5ca9d84b875b9ba702b79c)?
Hi Joseph, Yes, I'm using glibc 2.26 from the stable branch (commit 56ce01906ecb0a3e04411f8ceb60b27f4877f070). Same for gcc 7.x (commit 56ce01906ecb0a3e04411f8ceb60b27f4877f070) and binutils 2.29.1 (commit b8440a913ad431f633aa1f5a4257418162cd4b7a). Best regards, Romain Naour
And to confirm: you built GCC against a version of glibc that included those release branch fixes, not against an older 2.26 version? Because the described symptom in bug 21930 was missing support for these C99 interfaces in libstdc++ when configured against a glibc version without those fixes, which seems to match what you're seeing. (The std:: interfaces for C99 macros come from libstdc++, not glibc; glibc only provides them for TS 18661-1 macros such as iszero and issignaling.) What did the libstdc++ configure check "for ISO C99 support in <math.h> for C++98" result in when you built your GCC? If it failed, you should look in more detail at config.log from the libstdc++ build and see exactly how the headers from current glibc 2.26 branch sources got expanded there.
(In reply to joseph@codesourcery.com from comment #4) > What did the libstdc++ configure check "for ISO C99 support in <math.h> > for C++98" result in when you built your GCC? If it failed, you should > look in more detail at config.log from the libstdc++ build and see exactly > how the headers from current glibc 2.26 branch sources got expanded there. Hi, I am also testing Romains patches in buildroot and tried them with https://sourceware.org/git/?p=glibc.git;a=commit;h=2422c6032fd5e95b1c29df5b8671455ead51314e today. Quoting configure log of gcc-6.4.0: > Checking multilib configuration for libstdc++-v3... > mkdir -p -- x86_64-buildroot-linux-gnu/libstdc++-v3 > Configuring in x86_64-buildroot-linux-gnu/libstdc++-v3 [...] > checking for sin in -lm... yes > checking for ISO C99 support in <math.h> for C++98... no > checking tgmath.h usability... yes Now quoting config.log configure:16569: checking for sin in -lm [...] configure:16606: result: yes configure:16620: checking for ISO C99 support in <math.h> for C++98 configure:16689: /home/bernd/buildroot/br6/output/build/host-gcc-final-6.4.0/build/./gcc/xgcc -shared-libgcc -B/home/bernd/buildroot/br6/output/build/host-gcc-final-6.4.0/build/./gcc -nostdinc++ -L/home/bernd/buildroot/br6/output/build/host-gcc-final-6.4.0/build/x86_64-buildroot-linux-gnu/libstdc++-v3/src -L/home/bernd/buildroot/br6/output/build/host-gcc-final-6.4.0/build/x86_64-buildroot-linux-gnu/libstdc++-v3/src/.libs -L/home/bernd/buildroot/br6/output/build/host-gcc-final-6.4.0/build/x86_64-buildroot-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/bernd/buildroot/br6/output/host/x86_64-buildroot-linux-gnu/bin/ -B/home/bernd/buildroot/br6/output/host/x86_64-buildroot-linux-gnu/lib/ -isystem /home/bernd/buildroot/br6/output/host/x86_64-buildroot-linux-gnu/include -isystem /home/bernd/buildroot/br6/output/host/x86_64-buildroot-linux-gnu/sys-include -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -D_GNU_SOURCE -std=c++98 -fno-exceptions conftest.cpp -lm >&5 In file included from conftest.cpp:36:0: conftest.cpp: In function 'int main()': conftest.cpp:42:5: error: expected primary-expression before '__typeof' i = fpclassify(d1); ^ conftest.cpp:42:5: error: expected primary-expression before 'float' i = fpclassify(d1); ^ conftest.cpp:42:5: error: '__builtin_types_compatible_p' was not declared in this scope i = fpclassify(d1); ^ conftest.cpp:42:5: error: expected primary-expression before '__typeof' i = fpclassify(d1); ^ conftest.cpp:42:5: error: expected primary-expression before 'double' i = fpclassify(d1); ^ conftest.cpp:42:5: error: expected primary-expression before '__typeof' i = fpclassify(d1); ^ conftest.cpp:42:5: error: expected primary-expression before 'long' i = fpclassify(d1); ^ conftest.cpp:42:5: error: '__builtin_choose_expr' was not declared in this scope i = fpclassify(d1); ^ conftest.cpp:42:5: error: '__builtin_choose_expr' was not declared in this scope i = fpclassify(d1); ^ conftest.cpp:42:5: error: redeclaration of '<typeprefixerror>__builtin_choose_expr' conftest.cpp:42:5: note: previous declaration '<typeprefixerror>__builtin_choose_expr' i = fpclassify(d1); ^ conftest.cpp:42:5: error: '__builtin_choose_expr' was not declared in this scope i = fpclassify(d1); ^ conftest.cpp:42:5: error: redeclaration of '<typeprefixerror>__builtin_choose_expr' conftest.cpp:42:5: note: previous declaration '<typeprefixerror>__builtin_choose_expr' i = fpclassify(d1); ^ configure:16689: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "package-unused" | #define PACKAGE_TARNAME "libstdc++" | #define PACKAGE_VERSION "version-unused" | #define PACKAGE_STRING "package-unused version-unused" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | #define _GLIBCXX_HOSTED 1 | #define _GLIBCXX_VERBOSE 1 | #define _GLIBCXX_ATOMIC_BUILTINS 1 | #define _GLIBCXX_USE_INT128 1 | #define _GLIBCXX_USE_FLOAT128 1 | #define HAVE_STRXFRM_L 1 | #define HAVE_STRERROR_L 1 | #define HAVE_STRERROR_R 1 | #define HAVE_LIBINTL_H 1 | #define _GLIBCXX_USE_NLS 1 | #define _GLIBCXX_USE_LONG_LONG 1 | #define HAVE_WCHAR_H 1 | #define HAVE_MBSTATE_T 1 | #define HAVE_WCTYPE_H 1 | #define _GLIBCXX_USE_WCHAR_T 1 | /* end confdefs.h. */ | #include <math.h> | volatile double d1, d2; | volatile int i; | int | main () | { | i = fpclassify(d1); | i = isfinite(d1); | i = isinf(d1); | i = isnan(d1); | i = isnormal(d1); | i = signbit(d1); | i = isgreater(d1, d2); | i = isgreaterequal(d1, d2); | i = isless(d1, d2); | i = islessequal(d1, d2); | i = islessgreater(d1, d2); | i = islessgreater(d1, d2); | i = isunordered(d1, d2); | | ; | return 0; | } configure:16700: result: no configure:16714: checking tgmath.h usability
The issue is the use of -Os to build libstdc++. Gabriel, it looks like fpclassify needs a conditional as well to avoid the __MATH_TG version for (C++ and float128 support), for the same reason as isinf but only applicable when -Os is used to build libstdc++.
For the record, this also applies to powerpc64le (and should apply to ia64 and x86, as well, though I haven't checked on these platforms). However, since compiler support for float128 is not enabled by default on powerpc64le (not before GCC 8), this error will not be seen unless -mfloat128 is passed as a compiler option to g++ (e.g.: CXXFLAGS=-mfloat128). I'm working on a fix for glibc.
Hi Hi have a different error from the config.log. I'm using gcc 7.x (commit 56ce01906ecb0a3e04411f8ceb60b27f4877f070) configure:18385: checking for obsolete isnan function in <math.h> configure:18405: /home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/./gcc/xgcc -shared-libgcc -B/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/./gcc -nostdinc++ -L/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/x86_64-buildroot-linux-gnu/libstdc++-v3/src -L/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/x86_64-buildroot-linux-gnu/libstdc++-v3/src/.libs -L/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/x86_64-buildroot-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/bin/ -B/home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/lib/ -isystem /home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/include -isystem /home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/sys-include -c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -D_GNU_SOURCE -std=c++11 conftest.cpp >&5 conftest.cpp:67:24: error: '::isnan' has not been declared using ::isnan; ^~~~~ conftest.cpp:72:32: error: call of overloaded 'isnan(double)' is ambiguous bool b = isnan(0.0); ^ conftest.cpp:68:21: note: candidate: bool std::isnan(float) bool isnan(float); ^~~~~ conftest.cpp:69:21: note: candidate: bool std::isnan(long double) bool isnan(long double); ^~~~~ configure:18405: $? = 1 Also, I don't have the error reported by Bernd: configure:16625: checking for ISO C99 support in <math.h> for C++98 configure:16694: /home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/./gcc/xgcc -shared-libgcc -B/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/./gcc -nostdinc++ -L/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/x86_64-buildroot-linux-gnu/libstdc++-v3/src -L/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/x86_64-buildroot-linux-gnu/libstdc++-v3/src/.libs -L/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/x86_64-buildroot-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/bin/ -B/home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/lib/ -isystem /home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/include -isystem /home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/sys-include -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -D_GNU_SOURCE -std=c++98 -fno-exceptions conftest.cpp -lm >&5 configure:16694: $? = 0
Created attachment 10434 [details] x86_64-buildroot-linux-gnu/libstdc++-v3/config.log gcc 7.x
On Wed, 20 Sep 2017, romain.naour at gmail dot com wrote: > Hi have a different error from the config.log. I'm using gcc 7.x (commit > 56ce01906ecb0a3e04411f8ceb60b27f4877f070) > > configure:18385: checking for obsolete isnan function in <math.h> That's nothing to do with float128. The obsolete X/Open isnan C function isn't declared by glibc for C++, deliberately. That test is *meant* to fail. Look at the <cmath> and <math.h> installed with GCC - in locations such as <target>/include/c++/7.2.1/math.h. The math.h header should include <cmath> and then have various using declarations. The cmath header should include directives such as "#undef fpclassify" (meaning that all these math.h macros in glibc's math.h are completely irrelevant for C++). If they don't, you need to trace back why the wrong versions of those headers got installed by libstdc++ (compare configure results with an installation built without --enable-target-optspace, for example). If the headers look as expected, you need to trace the exact sequence of header inclusions, macros defines and undefines seen in your C++ test, to see why the C macros are visible for C++ when they should always be undefined by the C++ cmath header, which is included from the C++ version of math.h.
Hi, Sorry, In my previous comment I was looking at the libstdc++ build log where float128 was disabled. Here is the result of the test: configure:16625: checking for ISO C99 support in <math.h> for C++98 configure:16694: /home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/./gcc/xgcc -shared-libgcc -B/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/./gcc -nostdinc++ -L/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/x86_64-buildroot-linux-gnu/libstdc++-v3/src -L/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/x86_64-buildroot-linux-gnu/libstdc++-v3/src/.libs -L/home/kubu/toolchain/x86_64-glibc-master/build/host-gcc-final-custom/build/x86_64-buildroot-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/bin/ -B/home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/lib/ -isystem /home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/include -isystem /home/kubu/toolchain/x86_64-glibc-master/host/x86_64-buildroot-linux-gnu/sys-include -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -D_GNU_SOURCE -std=c++98 -fno-exceptions conftest.cpp -lm >&5 In file included from conftest.cpp:36:0: conftest.cpp: In function 'int main()': conftest.cpp:42:5: error: expected primary-expression before '__typeof' i = fpclassify(d1); ^ conftest.cpp:42:5: error: expected primary-expression before 'float' i = fpclassify(d1); ^ conftest.cpp:42:5: error: '__builtin_types_compatible_p' was not declared in this scope i = fpclassify(d1); ^ conftest.cpp:42:5: note: suggested alternative: '__builtin_ia32_comile' conftest.cpp:42:5: error: expected primary-expression before '__typeof' i = fpclassify(d1); ^ conftest.cpp:42:5: error: expected primary-expression before 'double' i = fpclassify(d1); ^ conftest.cpp:42:5: error: expected primary-expression before '__typeof' i = fpclassify(d1); ^ conftest.cpp:42:5: error: expected primary-expression before 'long' i = fpclassify(d1); ^ conftest.cpp:42:5: error: '__builtin_choose_expr' was not declared in this scope i = fpclassify(d1); ^ conftest.cpp:42:5: note: suggested alternative: '__builtin_cexpi' conftest.cpp:42:5: error: '__builtin_choose_expr' was not declared in this scope i = fpclassify(d1); ^ conftest.cpp:42:5: note: suggested alternative: '__builtin_cexpi' conftest.cpp:42:5: error: '__builtin_choose_expr' was not declared in this scope i = fpclassify(d1); ^ conftest.cpp:42:5: note: suggested alternative: '__builtin_cexpi' configure:16694: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "package-unused" | #define PACKAGE_TARNAME "libstdc++" | #define PACKAGE_VERSION "version-unused" | #define PACKAGE_STRING "package-unused version-unused" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | #define _GLIBCXX_HOSTED 1 | #define _GLIBCXX_VERBOSE 1 | #define _GLIBCXX_ATOMIC_BUILTINS 1 | #define _GLIBCXX_USE_INT128 1 | #define _GLIBCXX_USE_FLOAT128 1 | #define HAVE_STRXFRM_L 1 | #define HAVE_STRERROR_L 1 | #define HAVE_STRERROR_R 1 | #define HAVE_LIBINTL_H 1 | #define _GLIBCXX_USE_NLS 1 | #define _GLIBCXX_USE_LONG_LONG 1 | #define HAVE_WCHAR_H 1 | #define HAVE_MBSTATE_T 1 | #define HAVE_WCTYPE_H 1 | #define _GLIBCXX_USE_WCHAR_T 1 | /* end confdefs.h. */ | #include <math.h> | volatile double d1, d2; | volatile int i; | int | main () | { | i = fpclassify(d1); | i = isfinite(d1); | i = isinf(d1); | i = isnan(d1); | i = isnormal(d1); | i = signbit(d1); | i = isgreater(d1, d2); | i = isgreaterequal(d1, d2); | i = isless(d1, d2); | i = islessequal(d1, d2); | i = islessgreater(d1, d2); | i = islessgreater(d1, d2); | i = isunordered(d1, d2); | | ; | return 0; | } configure:16705: result: no So, it's the same issue as for gcc 6.4.0. Sorry for the noise...
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via c5c4a626098ec884b8527356abdf2a4bb7b6bf27 (commit) from 23947846658fd41875381c0bcc05b319c3c7bde4 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c5c4a626098ec884b8527356abdf2a4bb7b6bf27 commit c5c4a626098ec884b8527356abdf2a4bb7b6bf27 Author: Gabriel F. T. Gomes <gabriel@inconstante.eti.br> Date: Wed Sep 20 15:10:26 2017 -0300 Let fpclassify use the builtin when optimizing for size in C++ mode (bug 22146) When optimization for size is on (-Os), fpclassify does not use the type-generic __builtin_fpclassify builtin, instead it uses __MATH_TG. However, when library support for float128 is available, __MATH_TG uses __builtin_types_compatible_p, which is not available in C++ mode. On the other hand, libstdc++ undefines (in cmath) many macros from math.h, including fpclassify, so that it can provide its own functions. However, during its configure tests, libstdc++ just tests for the availability of the macros (it does not undefine them, nor does it provide its own functions). Finally, when libstdc++ is configured with optimization for size enabled, its configure tests include math.h and get the definition of fpclassify that uses __MATH_TG (and __builtin_types_compatible_p). Since libstdc++ does not undefine the macros during its configure tests, they fail. This patch lets fpclassify use the builtin in C++ mode, even when optimization for size is on. This allows the configure test in libstdc++ to work. Tested for powerpc64le and x86_64. [BZ #22146] math/math.h: Let fpclassify use the builtin in C++ mode, even when optimazing for size. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 6 ++++++ math/math.h | 8 +++++++- 2 files changed, 13 insertions(+), 1 deletions(-)
Fixed for 2.27.
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, release/2.26/master has been updated via d37c951fde57e8acb320a9a7d437ba50a1fc3c8a (commit) from 37d4262a7a35886cf8ac856457bbad8c0498c8d6 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d37c951fde57e8acb320a9a7d437ba50a1fc3c8a commit d37c951fde57e8acb320a9a7d437ba50a1fc3c8a Author: Gabriel F. T. Gomes <gabriel@inconstante.eti.br> Date: Wed Sep 20 15:10:26 2017 -0300 Let fpclassify use the builtin when optimizing for size in C++ mode (bug 22146) When optimization for size is on (-Os), fpclassify does not use the type-generic __builtin_fpclassify builtin, instead it uses __MATH_TG. However, when library support for float128 is available, __MATH_TG uses __builtin_types_compatible_p, which is not available in C++ mode. On the other hand, libstdc++ undefines (in cmath) many macros from math.h, including fpclassify, so that it can provide its own functions. However, during its configure tests, libstdc++ just tests for the availability of the macros (it does not undefine them, nor does it provide its own functions). Finally, when libstdc++ is configured with optimization for size enabled, its configure tests include math.h and get the definition of fpclassify that uses __MATH_TG (and __builtin_types_compatible_p). Since libstdc++ does not undefine the macros during its configure tests, they fail. This patch lets fpclassify use the builtin in C++ mode, even when optimization for size is on. This allows the configure test in libstdc++ to work. Tested for powerpc64le and x86_64. [BZ #22146] math/math.h: Let fpclassify use the builtin in C++ mode, even when optimazing for size. (cherry picked from commit c5c4a626098ec884b8527356abdf2a4bb7b6bf27) ----------------------------------------------------------------------- Summary of changes: ChangeLog | 6 ++++++ NEWS | 1 + math/math.h | 8 +++++++- 3 files changed, 14 insertions(+), 1 deletions(-)
Romain Naour, I have applied the fix to the master branch, as well as I have backported it to the stable branch for glibc 2.26. Could you test it in your setup in buildroot, please? Thank you.
Hi Gabriel, Thanks for the patch! I tested it on x86_64 with glibc build with -Os and the C++ issue is gone. Do you plan to release glibc 2.26.1 soon ? It would help me to update to glibc 2.26.x in Buildroot since I need to backport (at least) patches for bug 21930 and this one. Best regards, Romain
(In reply to romain.naour from comment #16) > > Do you plan to release glibc 2.26.1 soon ? > It would help me to update to glibc 2.26.x in Buildroot since I need to > backport (at least) patches for bug 21930 and this one. Each branch in glibc is maintained by a release manager [1] (for glibc 2.26, that would be Siddhesh (now in CC)). We could ask him what are the plans for further tagging, if any. Romain, let me ask you this in advance... In Buildroot, can you fetch the components from a particular revision in their VCS, meaning you could fetch glibc from a commit ID that contains this backport (i.e.: commit ID d37c951fde57 or newer)? [1] https://sourceware.org/glibc/wiki/Release#General_policy (not written in stone, but provides some insight into the branch/tag policies)
No plans for a 2.26.1 release, but you're free to backport to the 2.26 branch and then merge into whatever distribution you're using.
Gabriel, (In reply to Gabriel F. T. Gomes from comment #17) > (In reply to romain.naour from comment #16) > > Do you plan to release glibc 2.26.1 soon ? > > It would help me to update to glibc 2.26.x in Buildroot since I need to > > backport (at least) patches for bug 21930 and this one. > Romain, let me ask you this in advance... In Buildroot, can you fetch the > components from a particular revision in their VCS, meaning you could fetch > glibc from a commit ID that contains this backport (i.e.: commit ID > d37c951fde57 or newer)? Yes, we could technically use a sha1 (or a tag) from the glibc git tree. However, using "2.26.1" is much more descriptive than "1d4f239a7b34cf12" (totally made up sha1). Also, a release tarball is a strong indication that the content has somehow been sanctioned by upstream, much more than a random sha1 from the git tree. Regards, Yann E. MORIN.
(In reply to Siddhesh Poyarekar from comment #18) > No plans for a 2.26.1 release, but you're free to backport to the 2.26 > branch and then merge into whatever distribution you're using. I do fully agree with Yann's comment. Bugs 21930 and 22146 impact one of the major architecture (x86_64) for C++ programs (ex: mesa). Releasing glibc 2.26.1 would allow other packagers (usual Linux distrib, Yocto, Buildroot...) to sync with it and benefit from all corrections. Best regards, Romain
Most distributions I have worked with (Fedora, Debian, Ubuntu) prefer to backport specific patches that interest them rather than rebasing to upstream tarballs mid-release or as updates. This is because it gives them much finer control for maintenance from the distro viewpoint; it is easier to back off one patch and test instead of using a different tarball. So distribution use is not a sufficient case for a point release because they have never really asked for it in the past. I'm open to other reasons or suggestions or even opening up a debate on whether it makes sense to have point releases (and if distributions are actually going to use it) but bugzilla is not the place to discuss it. Please start a discussion on the libc-alpha mailing list.