[devel] I: glibc 2.34

[devel] I: glibc 2.34

[Gleb Fotengauer-Malinovskiy]

Hi,

В Сизиф совсем скоро попадёт glibc 2.34.

Enjoy!

Список пакетов, пересборка которых сломается и почему:

	/usr/src/RPM/BUILD/citra-nightly-nightly-1724/externals/dynarmic/src/backend/x64/exception_handler_posix.cpp:63:50: error: no matching function for call to 'max(long int, int)'
	/usr/src/RPM/BUILD/catch2-2.13.4/single_include/catch2/catch.hpp:10822:58: error: call to non-'constexpr' function 'long int sysconf(int)'
	/usr/src/RPM/BUILD/buildcache-0.26.1/src/third_party/doctest/doctest.h:4084:47: error: size of array 'altStackMem' is not an integral constant-expression
	/usr/src/RPM/BUILD/manticore-3.6.0/src/searchd.cpp:1182:21: error: storage size of 'exception_handler_stack' isn't constant
	../../src/sysdep.c:1795:22: error: variably modified 'sigsegv_stack' at file scope

	* Add _SC_MINSIGSTKSZ and _SC_SIGSTKSZ.  When _DYNAMIC_STACK_SIZE_SOURCE
	  or _GNU_SOURCE are defined, MINSIGSTKSZ and SIGSTKSZ are no longer
	  constant on Linux.  MINSIGSTKSZ is redefined to sysconf(_SC_MINSIGSTKSZ)
	  and SIGSTKSZ is redefined to sysconf (_SC_SIGSTKSZ).  This supports
	  dynamic sized register sets for modern architectural features like
	  Arm SVE.
buildcache	svn17 @everybody
catch2	pv @everybody
chromium	legion cas
citra	nenderus @everybody
clickhouse	rider darktemplar
codelite	grenka @everybody
emacs26	evg @emacs @everybody
ensmallen	viy @everybody
libbox2d	george @everybody
libcpp-hocon	cas @everybody
libkeyfinder	lvol @everybody
libleatherman	cas @everybody
libmmtf	lav @everybody
libvariant	lav @everybody
manticore	lav @everybody
megasync	lav @everybody
mustache-cpp	viy @everybody
ocaml	rider shaba @qa
python3-module-cysignals	cas @everybody
qpid-proton	shaba @everybody
qt5-webengine	zerg
rxcpp	darktemplar @everybody
sfizz	iv @everybody
spdlog	lav @everybody
yuzu	nenderus @everybody


	ld: /usr/src/tmp/ccCup5Ug.ltrans0.ltrans.o: undefined reference to symbol 'ns_get32@@GLIBC_2.9'
	/usr/src/RPM/BUILD/arpwatch-2.1a15/./dns.c:113: undefined reference to `_getshort'
	/usr/lib64/ghc-8.6.4/resolv-0.1.1.2/libHSresolv-0.1.1.2-FnHYhF4Lf0wK5YRpbsaqd7.a(FFI__1.o):function ghczuwrapperZC0ZCresolvzm0zi1zi1zi2zmFnHYhF4Lf0wK5YRpbsaqd7ZCNetworkziDNSziFFIZChszureszumkquery: error: undefined reference to '__res_nmkquery'
	ld: ../../src/libspf2/.libs/libspf2.so: undefined reference to `__dn_expand'

	* Various symbols previously defined in libresolv have been moved to libc
	  in order to prepare for libresolv moving entirely into libc (see earlier
	  entry for merging libraries into libc).  The symbols __dn_comp,
	  __dn_expand, __dn_skipname, __res_dnok, __res_hnok, __res_mailok,
	  __res_mkquery, __res_nmkquery, __res_nquery, __res_nquerydomain,
	  __res_nsearch, __res_nsend, __res_ownok, __res_query, __res_querydomain,
	  __res_search, __res_send formerly in libresolv have been renamed and no
	  longer have a __ prefix.  They are now available in libc.
adcli	shaba @everybody
arpwatch	@core mike @qa
ghc8.6.4-cabal-install	sin @everybody
libspf2	darktemplar @everybody
resolv_wrapper	sin @everybody


	automount.c:87:37: error: initializer element is not constant
	work_thread.c:45:57: error: missing binary operator before token "("

	* When _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined,
	  PTHREAD_STACK_MIN is no longer constant and is redefined to
	  sysconf(_SC_THREAD_STACK_MIN).  This supports dynamic sized register
	  sets for modern architectural features like Arm SVE.
autofs	sbolshakov @everybody
ntp	asy mike @qa
passenger	majioa @ruby @everybody
unit	vt andy @everybody


gmake[2]: *** No rule to make target '/usr/lib64/librt.so', needed by 'cctz_benchmark'.  Stop.
error: No such file or directory: /usr/src/tmp/dante-buildroot/usr/lib64/libdsocks.so
gmake[2]: *** No rule to make target '/usr/lib64/libutil.so', needed by 'bin/libqSlicerBaseQTCore.so.4.11.20210226'.  Stop.
ld: cannot find CCC: No such file or directory
	* In order to support smoother in-place-upgrades and to simplify
	  the implementation of the runtime all functionality formerly
	  implemented in the libraries libpthread, libdl, libutil, libanl has
	  been integrated into libc.
cctz	rider @everybody
dante	george @everybody
slicer	darktemplar @everybody
xnee	george @everybody


	/usr/include/sys/cdefs.h:265:61: error: missing ')' after "__has_attribute"
	/usr/include/sys/cdefs.h:252:60: error: macro "__has_attribute" requires an identifier

	https://sourceware.org/git/?p=glibc.git;a=commit;h=c8ba52ab3350c334d6e34b1439a4c0c1431351f3
	misc: Sync cdefs.h with gnulib
arduino-ctags	viy @everybody
ctags	@nobody
libowfat	darktemplar @everybody


	posix-io.c:577:23: error: void value not ignored as it ought to be
	ulockmgr_server.c:127:12: error: conflicting types for 'closefrom'; have 'int(int)'

	* The function closefrom has been added.  It closes all file descriptors
	  greater than or equal to a given integer.  This function is a GNU extension,
	  although it is also present in other systems.
gpgme	manowar zerg
fuse-2.9.9-alt1
postfix-1:3.6.2-alt1


	profiles/audio/media.c:1284:13: error: conflicting types for 'pause'; have '_Bool(void *)'
	../../src/pbar/lpbar.h:24:56: error: 'write' redeclared as different kind of symbol

	These packages pollute namespace with declarations conflicting with <unistd.h>
	header which is now included from <signal.h> after SIGSTKSZ-related change.
bluez	shrek aris zerg
quvi0.9	aris @gnome
scilab	cas @everybody


	conf.c:3470:9: error: argument 3 null where non-null expected [-Werror=nonnull]

	* On Linux, the function execveat has been added.  It operates similar to
	  execve and it is is already used to implement fexecve without requiring
	  /proc to be mounted.  However, different than fexecve, if the syscall is not
	  supported by the kernel an error is returned instead of trying a fallback.
pve-lxc	shrek @everybody


	/usr/include/sys/stat.h:485: undefined reference to `__xmknod'

	https://sourceware.org/git/?p=glibc.git;a=commit;h=589260cef8c2090d67d3deaa0a9ffa61c96de951
	Remove mknod wrapper functions, move them to symbols
dmraid	aris @everybody


	pam_alreadyloggedin.c:111:16: warning: implicit declaration of function '__xstat'; did you mean 'lstat'? [-Wimplicit-function-declaration]

	https://sourceware.org/git/?p=glibc.git;a=commit;h=8ed005daf0ab03e142500324a34087ce179ae78e
	Remove stat wrapper functions, move them to exported symbols
pam_alreadyloggedin	darktemplar @everybody


	/usr/include/wchar.h:582:24: error: 'malloc' attribute argument 1 is ambiguous

	https://sourceware.org/git/?p=glibc.git;a=commit;h=c1760eaf3b575ad174fd88b252fd16bd525fa818
	Enable support for GCC 11 -Wmismatched-dealloc.
rawtherapee	aris


	../../../lib/cobalt/printf.c:732:9: error: 'pthread_setspecific' expecting 1 byte in a region of size 0 [-Werror=stringop-overread]

	https://sourceware.org/git/?p=glibc.git;a=commit;h=a1561c3bbe8e72c6e44280d1eb5e529d2da4ecd0
	Add __attribute_access_none to disable GCC warnings [BZ #27714]
xenomai	vt @kernel


	./malloc/dynarray-skeleton.c:195:24: error: expected declaration specifiers or '...' before '(' token

	https://lists.gnu.org/archive/html/bug-guile/2021-08/msg00010.html
	http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=b4a80f4239b19fea4d2cc3e9d197f24b809f0624
guile30	sbolshakov @everybody


	tester.c:312:10: error: 'mallinfo' is deprecated [-Werror=deprecated-declarations]

	* The mallinfo function is marked deprecated.  Callers should call
	  mallinfo2 instead.
libbctoolbox	taf @everybody


	Heap-Layers/wrappers/gnuwrapper-hooks.cpp:93:25: error: '__malloc_hook' was not declared in this scope; did you mean 'my_malloc_hook'?

	* The deprecated memory allocation hooks __malloc_hook, __realloc_hook,
	  __memalign_hook and __free_hook are now removed from the API.  Compatibility
	  symbols are present to support legacy programs but new applications can no
	  longer link to these symbols.  These hooks no longer have any effect on glibc
	  functionality.  The malloc debugging DSO libc_malloc_debug.so currently
	  supports hooks and can be preloaded to get this functionality back for older
	  programs.  However this is a transitional measure and may be removed in a
	  future release of the GNU C Library.  Users may port away from these hooks by
	  writing and preloading their own malloc interposition library.
libhoard	viy @everybody


	morecore.c:351:17: error: '__morecore' undeclared (first use in this function); did you mean 'thp_morecore'?

	* The __morecore and __after_morecore_hook malloc hooks and the default
	  implementation __default_morecore have been removed from the API.  Existing
	  applications will continue to link against these symbols but the interfaces
	  no longer have any effect on malloc.
libhugetlbfs	viy @everybody


	/usr/src/RPM/BUILD/libupnp16-1.12.1/upnp/sample/common/sample_util.c:68: undefined reference to `pthread_mutexattr_setkind_np'

	[This symbol was never a part of public interface.]
	https://sourceware.org/git/?p=glibc.git;a=commit;h=b76c066d092d78124deeba9b687f5b10924e97de
	nptl: Move pthread_mutexattr_settype, __pthread_mutexattr_settype into libc
	And pthread_mutexattr_setkind_np as a compatibility symbol.
libupnp16	sbolshakov @everybody


	E: Couldn't find package /usr/sbin/zdump

	* Following a change in the tzdata 2018a release upstream, the zdump
	  program is now installed in the /usr/bin subdirectory.  Previously,
	  the /usr/sbin subdirectory was used.
gcal	viy @everybody


	phdr[6]: unknown object file note type 32 with owner name '^E' at offset 48
	phdr[6]: extra 72 bytes after last note
	verify-elf: ERROR: ./usr/bin/blender: eu-elflint failed

	While the GNU Gold linker has been quite promising especially in being
	faster than the conventional GNU linker, Google developers are no longer
	actively advancing this linker and thus raising concerns it could begin to
	suffer from bit-rot. 

blender	darktemplar @everybody
springrts	darktemplar @everybody

-- 
glebfm

Re: [devel] I: glibc 2.34

[Gleb Fotengauer-Malinovskiy]

On Wed, Oct 13, 2021 at 02:05:30PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> Hi,
> 
> В Сизиф совсем скоро попадёт glibc 2.34.
> 
> Enjoy!
> 
> Список пакетов, пересборка которых сломается и почему:
[...]
> 	posix-io.c:577:23: error: void value not ignored as it ought to be
> 	ulockmgr_server.c:127:12: error: conflicting types for 'closefrom'; have 'int(int)'
> 
> 	* The function closefrom has been added.  It closes all file descriptors
> 	  greater than or equal to a given integer.  This function is a GNU extension,
> 	  although it is also present in other systems.
> gpgme	manowar zerg
> fuse-2.9.9-alt1
> postfix-1:3.6.2-alt1

fuse	mithraen mike rider @qa
postfix	glebfm @core

Прошу прощения, здесь не заменилось на acl.

-- 
glebfm

Re: [devel] I: glibc 2.34

[Alexey Sheplyakov]

On 13.10.2021 15:05, Gleb Fotengauer-Malinovskiy wrote:
> Hi,
> 
> В Сизиф совсем скоро попадёт glibc 2.34.
> 
> Enjoy!
> 
> 	/usr/src/RPM/BUILD/buildcache-0.26.1/src/third_party/doctest/doctest.h:4084:47: error: size of array 'altStackMem' is not an integral constant-expression

https://github.com/mbitsnbites/buildcache/issues/235

Re: [devel] I: glibc 2.34

[Alexey Tourbin]

On Wed, Oct 13, 2021 at 2:05 PM Gleb Fotengauer-Malinovskiy
<glebfm@altlinux.org> wrote:
> В Сизиф совсем скоро попадёт glibc 2.34.

When an application gets relinked with glibc 2.34, it will no longer
have the dependency on libpthread.so.0, right? Will the application
still work with glibc 2.32?

Re: [devel] I: glibc 2.34

[Dmitry V. Levin]

On Wed, Oct 13, 2021 at 04:34:32PM +0300, Alexey Tourbin wrote:
> On Wed, Oct 13, 2021 at 2:05 PM Gleb Fotengauer-Malinovskiy wrote:
> > В Сизиф совсем скоро попадёт glibc 2.34.
> 
> When an application gets relinked with glibc 2.34, it will no longer
> have the dependency on libpthread.so.0, right? Will the application
> still work with glibc 2.32?

Those that use pthread API will get references to @GLIBC_2.34 symbols
and therefore will require glibc >= 2.34 to run.


-- 
ldv

Re: [devel] I: glibc 2.34

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

On Wed, Oct 13, 2021 at 04:34:32PM +0300, Alexey Tourbin wrote:
> On Wed, Oct 13, 2021 at 2:05 PM Gleb Fotengauer-Malinovskiy
> <glebfm@altlinux.org> wrote:
> > В Сизиф совсем скоро попадёт glibc 2.34.
> 
> When an application gets relinked with glibc 2.34, it will no longer
> have the dependency on libpthread.so.0, right?

Yes, DT_NEEDED structure for libpthread.so.0 is not going to be added
anymore.

> Will the application still work with glibc 2.32?

No.

All symbols previously provided by the libpthread, librt, libutil, and
libanl libraries are now supported by libc as compatibility symbols.
Shared objects linked with glibc >= 2.34 will require @GLIBC_2.34
versions of these symbols.

Furthermore, all executables linked with glibc >= 2.34 will be
incompatible with the older versions of glibc due
to linking with the __libc_start_main@@GLIBC_2.34 symbol.

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: glibc 2.34

[Aleksei Nikiforov]

13.10.2021 14:05, Gleb Fotengauer-Malinovskiy пишет:
> Hi,
> 
> В Сизиф совсем скоро попадёт glibc 2.34.
> 
> Enjoy!
> 
> Список пакетов, пересборка которых сломается и почему:
> 

...

> 	phdr[6]: unknown object file note type 32 with owner name '^E' at offset 48
> 	phdr[6]: extra 72 bytes after last note
> 	verify-elf: ERROR: ./usr/bin/blender: eu-elflint failed
> 
> 	While the GNU Gold linker has been quite promising especially in being
> 	faster than the conventional GNU linker, Google developers are no longer
> 	actively advancing this linker and thus raising concerns it could begin to
> 	suffer from bit-rot.
> 
> blender	darktemplar @everybody
> springrts	darktemplar @everybody
> 

Здравствуйте.

Есть предложения как это может быть исправлено?

С уважением,
Алексей Никифоров

Re: [devel] I: glibc 2.34

[Dmitry V. Levin]

Hi,

On Thu, Oct 14, 2021 at 11:26:52AM +0300, Aleksei Nikiforov wrote:
> 13.10.2021 14:05, Gleb Fotengauer-Malinovskiy пишет:
> > Hi,
> > 
> > В Сизиф совсем скоро попадёт glibc 2.34.
> > 
> > Enjoy!
> > 
> > Список пакетов, пересборка которых сломается и почему:
> > 
> 
> ...
> 
> > 	phdr[6]: unknown object file note type 32 with owner name '^E' at offset 48
> > 	phdr[6]: extra 72 bytes after last note
> > 	verify-elf: ERROR: ./usr/bin/blender: eu-elflint failed
> > 
> > 	While the GNU Gold linker has been quite promising especially in being
> > 	faster than the conventional GNU linker, Google developers are no longer
> > 	actively advancing this linker and thus raising concerns it could begin to
> > 	suffer from bit-rot.
> > 
> > blender	darktemplar @everybody
> > springrts	darktemplar @everybody
> > 
> 
> Здравствуйте.
> 
> Есть предложения как это может быть исправлено?

Использовать вместо слабо поддерживаемого GNU Gold другой linker.


-- 
ldv

Re: [devel] I: glibc 2.34

[Sergey Y. Afonin]

On Wednesday 13 October 2021, Gleb Fotengauer-Malinovskiy wrote:

>         * When _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined,
>           PTHREAD_STACK_MIN is no longer constant and is redefined to
>           sysconf(_SC_THREAD_STACK_MIN).  This supports dynamic sized register
>           sets for modern architectural features like Arm SVE.

> ntp     asy mike @qa

Пока поступил так: https://bugs.ntp.org/show_bug.cgi?id=3741

-- 
С уважением, Сергей Афонин