[Git][glibc-team/glibc][sid] 4 commits: debian/rules: drop DEB_STAGE and DEB_BUILD_PROFILE support
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc Commits: dfa09e53 by Helmut Grohne at 2018-03-05T21:06:52+01:00 debian/rules: drop DEB_STAGE and DEB_BUILD_PROFILE support Please use DEB_BUILD_PROFILES now. - - - - - 8d2dd692 by Helmut Grohne at 2018-03-05T21:07:53+01:00 debian/rules: disable tests for stage1 Trying to build stage1 with tests enabled, simply fails finding prerequisites. There is no point in testing stage1. - - - - - 9a9fc227 by Helmut Grohne at 2018-03-05T22:09:53+01:00 debian/control.in/*: drop libc*-dev - libc* dependencies in stage1 During a stage1 build we only emit (crippled) libc*-dev packages containing headers and stub libraries. Shared libraries are not emitted at all. Thus we should also drop the dependencies on the missing packages to make the resulting packages installable. - - - - - 16bfe25e by Aurelien Jarno at 2018-03-05T22:11:51+01:00 debian/control.in/mips32: swap dependencies for consistency with the other files - - - - - 18 changed files: - debian/changelog - debian/control - debian/control.in/amd64 - debian/control.in/armel - debian/control.in/armhf - debian/control.in/i386 - debian/control.in/kfreebsd-i386 - debian/control.in/libc - debian/control.in/mips32 - debian/control.in/mips64 - debian/control.in/mipsn32 - debian/control.in/powerpc - debian/control.in/ppc64 - debian/control.in/s390 - debian/control.in/sparc - debian/control.in/sparc64 - debian/control.in/x32 - debian/rules View it on GitLab: https://salsa.debian.org/glibc-team/glibc/compare/5151257a611258e3c6fa7d7ef4fdba8eb1d83e57...16bfe25ef10722d46354119c98eadf15d453de96 --- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/compare/5151257a611258e3c6fa7d7ef4fdba8eb1d83e57...16bfe25ef10722d46354119c98eadf15d453de96 You're receiving this email because of your account on salsa.debian.org.
Bug#892126: glibc: stage1 build failure due to missing multilib lib-names-*.h
Source: glibc Version: 2.27-1 User: helm...@debian.org Usertags: rebootstrap Hi Aurelien, I need a bug number for tracking this issue, so I am filing this bug summarizing the problem and recording my knowledge. Building glibc with DEB_BUILD_OPTIONS=nocheck DEB_BUILD_PROFILES=stage1 presently fails (even natively) on architectures with multilib packages. The symptom always is that some variant of a multilib lib-names-*.h goes missing in the packaging part of the installation procedure recently added. The headers in question are not generated during a (stage1) build and a gcc stage2 (the only relevant user) does not use them. I verified that simply not installing them makes a bootstrap of e.g. mips work again: sed -i -e 's#debian/tmp-.*/usr/include/gnu/lib-names.*\.h#$(if $(filter stage1,$(DEB_BUILD_PROFILES)),,&)#' debian/sysdeps/*.mk Now I am not asking you to include this fix (thus not adding a patch tag), because we both know it is ugly, but I am recording the workaround to improve our understanding. It confirms our intuition that the same workaround as for gnu/stubs.h should be applicable here. My attempts at implementing that properly weren't fruitful thus far. So all I can do now is document the problem. Helmut
Bug#890801: marked as done (libc6-i386 conflicts with libc6-amd64:i386)
Your message dated Mon, 5 Mar 2018 21:04:37 +0100 with message-id <20180305200437.ga7...@aurel32.net> and subject line Re: Bug#890801: libc6-i386 conflicts with libc6-amd64:i386 has caused the Debian Bug report #890801, regarding libc6-i386 conflicts with libc6-amd64:i386 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 890801: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890801 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6-i386 Version: 2.26-6 Severity: important Dear Maintainer, I tried cross compile 32-bit Mesa on 64-bit Debian (amd64), and I had to install these packages in order to do it: llvm-5.0-dev:i386 libclang-5.0-dev:i386 gcc-multilib g++-multilib Unfortunately it failed, and I managed to narrow it down to the conflict between libc6-i386 conflicts and libc6-amd64:i386: sudo apt-get install libc6-amd64:i386 libc6-i386 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libc6-amd64:i386 : Conflicts: libc6-i386 but 2.26-6 is to be installed libc6-i386 : Conflicts: libc6-amd64:i386 but 2.26-6 is to be installed E: Unable to correct problems, you have held broken packages. How can this be resolved? -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libc6-i386 depends on: ii libc6 2.26-6 libc6-i386 recommends no packages. libc6-i386 suggests no packages. --- End Message --- --- Begin Message --- On 2018-02-19 10:18, Aurelien Jarno wrote: > On 2018-02-18 19:17, Hillel Lubman wrote: > > Package: libc6-i386 > > Version: 2.26-6 > > Severity: important > > > > Dear Maintainer, > > > > I tried cross compile 32-bit Mesa on 64-bit Debian (amd64), and I had to > > install these packages in order to do it: > > > > llvm-5.0-dev:i386 libclang-5.0-dev:i386 gcc-multilib g++-multilib > > > > Unfortunately it failed, and I managed to narrow it down to the conflict > > between libc6-i386 conflicts and libc6-amd64:i386: > > You can install only one set of multilib package at the same time, > otherwise you end up with files conflict. In your case llvm-5.0-dev:i386 > requires the :i386 version of the multilib set, while gcc-multilib > requires the :amd64 version of it. > > > sudo apt-get install libc6-amd64:i386 libc6-i386 > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > Some packages could not be installed. This may mean that you have > > requested an impossible situation or if you are using the unstable > > distribution that some required packages have not yet been created > > or been moved out of Incoming. > > The following information may help to resolve the situation: > > > > The following packages have unmet dependencies: > > libc6-amd64:i386 : Conflicts: libc6-i386 but 2.26-6 is to be installed > > libc6-i386 : Conflicts: libc6-amd64:i386 but 2.26-6 is to be installed > > E: Unable to correct problems, you have held broken packages. > > > > How can this be resolved? > > If you want to install llvm for i386 you also need to install gcc for > i386. The other option is to not install gcc-multilib and g++-multilib. > > If that solution is not acceptable for you, here are the few other > alternatives I can think of: > - report a bug against llvm to split libclang-common-5.0-dev into two > parts, one providing the native support, the other one the multilib > support, just like it is done in GCC. > - report a bug against llvm to support a multiarch alternative to the > 64-bit libraries. That means for example changing the lib64gcc1:i386 > dependency into lib64gcc1:i386 | libgcc1:amd64. This might require > code change to look into both multiarch and multilib paths. > - report a bug against gcc to support a multiarch alternative to the > 32-bit libraries. > - report a bug against gcc-7-cross to add an i386 cross-compiler on > amd64. > >
Processed (with 1 error): Re: libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer
Processing control commands: > reassign -1 gcc-snapshot Bug #892096 [libc6] libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer Bug reassigned from package 'libc6' to 'gcc-snapshot'. No longer marked as found in versions glibc/2.27-1. Ignoring request to alter fixed versions of bug #892096 to the same values previously set > gcc-snapshot: AddressSanitizer uses glibc internal functions Unknown command or malformed arguments to command. -- 892096: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892096 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer
control: reassign -1 gcc-snapshot
control: gcc-snapshot: AddressSanitizer uses glibc internal functions
On 2018-03-05 14:27, Vincent Lefevre wrote:
> Control: reassign -1 libc6 2.27-1
> Control: retitle -1 libc6:i386 yields invalid writes, triggered by GCC's
> AddressSanitizer
> Control: severity -1 serious
>
> On 2018-03-05 14:10:56 +0100, Vincent Lefevre wrote:
> > cventin:~> cat tst.c
> > int main (void)
> > {
> > return 0;
> > }
> > cventin:~> gcc-snapshot -m32 -fsanitize=address tst.c -o tst
> > cventin:~> ./tst
> > AddressSanitizer:DEADLYSIGNAL
> > =
> > ==25032==ERROR: AddressSanitizer: SEGV on unknown address 0xf7fa7e70 (pc
> > 0xf7fa7e84 bp 0xffbf40ac sp 0xffbf406c T16777215)
> > ==25032==The signal is caused by a WRITE memory access.
> > #0 0xf7fa7e83 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x11e83)
> > #1 0xf7ac147d (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0x10e47d)
> > #2 0xf7aafd27 (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0xfcd27)
> > #3 0xf7fa591a (/lib/ld-linux.so.2+0xf91a)
> > #4 0xf7f96cb9 (/lib/ld-linux.so.2+0xcb9)
> >
> > AddressSanitizer can not provide additional info.
> > SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e83) in
> > _dl_get_tls_static_info
> > ==25032==ABORTING
>
> libc6:i386 was actually the cause (gcc-snapshot had not changed).
> Reverting to 2.26-6 makes the crash disappear.
The AddressSanitizer is using glibc internal functions though dlsym(),
and such functions have the right to change in new major versions:
From libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:
| void *get_tls_static_info_ptr = dlsym(RTLD_NEXT, "_dl_get_tls_static_info");
And on the glibc side:
| $ readelf -s /lib/ld-linux.so.2 | grep _dl_get_tls_static_info
| 4: 00011e7035 FUNCGLOBAL DEFAULT 12
_dl_get_tls_static_info@@GLIBC_PRIVATE
This has been discussed for example there:
https://www.sourceware.org/ml/libc-alpha/2018-02/msg00611.html
The AddressSanitizer people should discuss for a public API so that it
doesn't happen again. Otherwise it might break at every new glibc
version.
I am therefore reassigning the bug to gcc-snapshot.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer
Control: reassign -1 libc6 2.27-1
Control: retitle -1 libc6:i386 yields invalid writes, triggered by GCC's
AddressSanitizer
Control: severity -1 serious
On 2018-03-05 14:10:56 +0100, Vincent Lefevre wrote:
> cventin:~> cat tst.c
> int main (void)
> {
> return 0;
> }
> cventin:~> gcc-snapshot -m32 -fsanitize=address tst.c -o tst
> cventin:~> ./tst
> AddressSanitizer:DEADLYSIGNAL
> =
> ==25032==ERROR: AddressSanitizer: SEGV on unknown address 0xf7fa7e70 (pc
> 0xf7fa7e84 bp 0xffbf40ac sp 0xffbf406c T16777215)
> ==25032==The signal is caused by a WRITE memory access.
> #0 0xf7fa7e83 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x11e83)
> #1 0xf7ac147d (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0x10e47d)
> #2 0xf7aafd27 (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0xfcd27)
> #3 0xf7fa591a (/lib/ld-linux.so.2+0xf91a)
> #4 0xf7f96cb9 (/lib/ld-linux.so.2+0xcb9)
>
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e83) in
> _dl_get_tls_static_info
> ==25032==ABORTING
libc6:i386 was actually the cause (gcc-snapshot had not changed).
Reverting to 2.26-6 makes the crash disappear.
--
Vincent Lefèvre - Web:
Processed: libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer
Processing control commands: > reassign -1 libc6 2.27-1 Bug #892096 [gcc-snapshot] gcc-snapshot: AddressSanitizer /usr/lib/gcc-snapshot/lib32/libasan.so.5 is broken: SEGV Bug reassigned from package 'gcc-snapshot' to 'libc6'. No longer marked as found in versions gcc-snapshot/20180216-1. Ignoring request to alter fixed versions of bug #892096 to the same values previously set Bug #892096 [libc6] gcc-snapshot: AddressSanitizer /usr/lib/gcc-snapshot/lib32/libasan.so.5 is broken: SEGV Marked as found in versions glibc/2.27-1. > retitle -1 libc6:i386 yields invalid writes, triggered by GCC's > AddressSanitizer Bug #892096 [libc6] gcc-snapshot: AddressSanitizer /usr/lib/gcc-snapshot/lib32/libasan.so.5 is broken: SEGV Changed Bug title to 'libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer' from 'gcc-snapshot: AddressSanitizer /usr/lib/gcc-snapshot/lib32/libasan.so.5 is broken: SEGV'. > severity -1 serious Bug #892096 [libc6] libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer Severity set to 'serious' from 'important' -- 892096: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892096 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
