Bug#782254: libphobos-5-dev: Unable to install: depends on gcc-5-base (= 5-20150205-1) [UNAVAILABLE]
Package: libphobos-5-dev Version: 5-20150205 Severity: grave Justification: renders package unusable Dear Maintainer, I assume that at the time, gcc-5-base had an 0205 version, but being experimental, has moved on, and left gdc/phobos behind, so all (I know, I know) that's needed is for a rebuild. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150409143746.5208.32508.reportbug@longsword.imperial.fleet
Bug#869090: gcc-6: Address sanitizer: Shadow memory range interleaves
Package: gcc-6 Version: 6.4.0-1 Severity: important Dear Maintainer, building autotools packages with address sanitizer currently breaks with gcc-6 and gcc-7. gcc-5 is not effected. This breaks quality checking and fuzzing with ASAN enabled. Using LD_PRELOAD to load libasan first doesn't change anything. This doesn't help either (in case this is a ASLR problem with the kernel): echo 0 >/proc/sys/kernel/randomize_va_space $ CC=gcc-6 CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking for gcc... gcc-6 checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... configure: error: in `/usr/oms/src/libpsl': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details >From config.log: configure:3459: gcc-6 -o conftest -g -fsanitize=address -fno-omit-frame-pointer conftest.c >&5 configure:3463: $? = 0 configure:3470: ./conftest ==13782==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. ==13782==ASan shadow was supposed to be located in the [0x7fff7000-0x10007fff7fff] range. ==13782==Process memory map follows: 0x005450338000-0x005450339000 /usr/oms/src/libpsl/conftest 0x005450539000-0x00545053a000 /usr/oms/src/libpsl/conftest ... 0x7fff70943000-0x7fff70964000 [stack] 0x7fff709a4000-0x7fff709a6000 [vvar] 0x7fff709a6000-0x7fff709a8000 [vdso] ==13782==End of process memory map. configure:3474: $? = 1 configure:3481: error: in `/usr/oms/src/libpsl': configure:3483: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details Regards, Tim -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gcc-6 depends on: ii binutils 2.28-6 ii cpp-6 6.4.0-1 ii gcc-6-base6.4.0-1 ii libc6 2.24-12 ii libcc1-0 7.1.0-9 ii libgcc-6-dev 6.4.0-1 ii libgcc1 1:7.1.0-9 ii libgmp10 2:6.1.2+dfsg-1 ii libisl15 0.18-1 ii libmpc3 1.0.3-1+b2 ii libmpfr4 3.1.5-1 ii libstdc++67.1.0-9 ii zlib1g1:1.2.8.dfsg-5 Versions of packages gcc-6 recommends: ii libc6-dev 2.24-12 Versions of packages gcc-6 suggests: ii gcc-6-doc 6.3.0-1 pn gcc-6-locales pn gcc-6-multilib pn libasan3-dbg pn libatomic1-dbg pn libcilkrts5-dbg pn libgcc1-dbg pn libgomp1-dbg pn libitm1-dbg pn liblsan0-dbg pn libmpx2-dbg pn libquadmath0-dbg pn libtsan0-dbg pn libubsan0-dbg -- no debconf information
Bug#869090: gcc-6: Address sanitizer: Shadow memory range interleaves
Any program:
#include
int main(void)
{
printf("Hello\n");
}
$ gcc-6 -g -fsanitize=address -fno-omit-frame-pointer x.c -o x
$ ./x
==29033==Shadow memory range interleaves with an existing memory
mapping. ASan cannot proceed correctly. ABORTING.
==29033==ASan shadow was supposed to be located in the
[0x7fff7000-0x10007fff7fff] range.
==29033==Process memory map follows:
0x0001-0x00011000 /usr/oms/src/libpsl/x
0x00010020-0x000100201000 /usr/oms/src/libpsl/x
0x000100201000-0x000100202000 /usr/oms/src/libpsl/x
0x75889000-0x75bdb000
0x75bdb000-0x75bf1000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x75bf1000-0x75df /lib/x86_64-linux-gnu/libgcc_s.so.1
...
With Best Regards, Tim
On 07/20/2017 05:09 PM, Matthias Klose wrote:
> On 20.07.2017 14:45, Tim Ruehsen wrote:
>> Package: gcc-6
>> Version: 6.4.0-1
>> Severity: important
>>
>> Dear Maintainer,
>>
>> building autotools packages with address sanitizer currently breaks with
>> gcc-6 and gcc-7.
>> gcc-5 is not effected.
>>
>> This breaks quality checking and fuzzing with ASAN enabled.
>> Using LD_PRELOAD to load libasan first doesn't change anything.
>>
>> This doesn't help either (in case this is a ASLR problem with the kernel):
>> echo 0 >/proc/sys/kernel/randomize_va_space
>>
>>
>> $ CC=gcc-6 CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer"
>> ./configure
>> checking for a BSD-compatible install... /usr/bin/install -c
>>
>>
>> checking whether build environment is sane... yes
>>
>>
>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>>
>>
>> checking for gawk... gawk
>>
>>
>> checking whether make sets $(MAKE)... yes
>>
>>
>> checking whether make supports nested variables... yes
>>
>>
>> checking for gcc... gcc-6
>>
>>
>> checking whether the C compiler works... yes
>>
>>
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... configure: error: in
>> `/usr/oms/src/libpsl':
>> configure: error: cannot run C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
>>
>>
>> >From config.log:
>> configure:3459: gcc-6 -o conftest -g -fsanitize=address
>> -fno-omit-frame-pointer conftest.c >&5
>> configure:3463: $? = 0
>> configure:3470: ./conftest
>> ==13782==Shadow memory range interleaves with an existing memory mapping.
>> ASan cannot proceed correctly. ABORTING.
>> ==13782==ASan shadow was supposed to be located in the
>> [0x7fff7000-0x10007fff7fff] range.
>> ==13782==Process memory map follows:
>> 0x005450338000-0x005450339000 /usr/oms/src/libpsl/conftest
>> 0x005450539000-0x00545053a000 /usr/oms/src/libpsl/conftest
>> ...
>> 0x7fff70943000-0x7fff70964000 [stack]
>> 0x7fff709a4000-0x7fff709a6000 [vvar]
>> 0x7fff709a6000-0x7fff709a8000 [vdso]
>> ==13782==End of process memory map.
>> configure:3474: $? = 1
>> configure:3481: error: in `/usr/oms/src/libpsl':
>> configure:3483: error: cannot run C compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
>
> please could you attach the failing conftest?
>
>
>
signature.asc
Description: OpenPGP digital signature
Bug#869090: gcc-6: Address sanitizer: Shadow memory range interleaves
On 07/20/2017 05:09 PM, Matthias Klose wrote: > On 20.07.2017 14:45, Tim Ruehsen wrote: >> Package: gcc-6 >> Version: 6.4.0-1 >> Severity: important >> >> Dear Maintainer, >> >> building autotools packages with address sanitizer currently breaks with >> gcc-6 and gcc-7. >> gcc-5 is not effected. >> >> This breaks quality checking and fuzzing with ASAN enabled. >> Using LD_PRELOAD to load libasan first doesn't change anything. >> >> This doesn't help either (in case this is a ASLR problem with the kernel): >> echo 0 >/proc/sys/kernel/randomize_va_space >> >> >> $ CC=gcc-6 CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" >> ./configure >> checking for a BSD-compatible install... /usr/bin/install -c >> >> >> checking whether build environment is sane... yes >> >> >> checking for a thread-safe mkdir -p... /bin/mkdir -p >> >> >> checking for gawk... gawk >> >> >> checking whether make sets $(MAKE)... yes >> >> >> checking whether make supports nested variables... yes >> >> >> checking for gcc... gcc-6 >> >> >> checking whether the C compiler works... yes >> >> >> checking for C compiler default output file name... a.out >> checking for suffix of executables... >> checking whether we are cross compiling... configure: error: in >> `/usr/oms/src/libpsl': >> configure: error: cannot run C compiled programs. >> If you meant to cross compile, use `--host'. >> See `config.log' for more details >> >> >> >From config.log: >> configure:3459: gcc-6 -o conftest -g -fsanitize=address >> -fno-omit-frame-pointer conftest.c >&5 >> configure:3463: $? = 0 >> configure:3470: ./conftest >> ==13782==Shadow memory range interleaves with an existing memory mapping. >> ASan cannot proceed correctly. ABORTING. >> ==13782==ASan shadow was supposed to be located in the >> [0x7fff7000-0x10007fff7fff] range. >> ==13782==Process memory map follows: >> 0x005450338000-0x005450339000 /usr/oms/src/libpsl/conftest >> 0x005450539000-0x00545053a000 /usr/oms/src/libpsl/conftest >> ... >> 0x7fff70943000-0x7fff70964000 [stack] >> 0x7fff709a4000-0x7fff709a6000 [vvar] >> 0x7fff709a6000-0x7fff709a8000 [vdso] >> ==13782==End of process memory map. >> configure:3474: $? = 1 >> configure:3481: error: in `/usr/oms/src/libpsl': >> configure:3483: error: cannot run C compiled programs. >> If you meant to cross compile, use `--host'. >> See `config.log' for more details > > please could you attach the failing conftest? config.log doesn't even say. It continues with ==28018==End of process memory map. configure:3474: $? = 1 configure:3481: error: in `/usr/oms/src/libpsl': configure:3483: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details ## ## ## Cache variables. ## ## ## ... and exit. Regards, Tim signature.asc Description: OpenPGP digital signature
Bug#1035472: libstdc++.so: Core dump with libstdc++.so and index++
Package: libstdc++6 Version: 12.2.0-14 Severity: normal File: libstdc++.so #0 0x7f2c7daa4ccc __pthread_kill_implementation (libc.so.6 + 0x8accc) #10 0x556d13d51d8e n/a (index++ + 0xed8e) #1 0x7f2c7da55ef2 __GI_raise (libc.so.6 + 0x3bef2) #11 0x7f2c7da4118a __libc_start_call_main (libc.so.6 + 0x2718a) #12 0x7f2c7da41245 __libc_start_main_impl (libc.so.6 + 0x27245) #13 0x556d13d5482a n/a (index++ + 0x1182a) #2 0x7f2c7da40472 __GI_abort (libc.so.6 + 0x26472) #3 0x7f2c7dc9d919 n/a (libstdc++.so.6 + 0x9d919) #4 0x7f2c7dca8e1a n/a (libstdc++.so.6 + 0xa8e1a) #5 0x7f2c7dca8e85 _ZSt9terminatev (libstdc++.so.6 + 0xa8e85) #6 0x7f2c7dca90d8 __cxa_throw (libstdc++.so.6 + 0xa90d8) #7 0x7f2c7dca026d n/a (libstdc++.so.6 + 0xa026d) #8 0x556d13d598a6 n/a (index++ + 0x168a6) #9 0x556d13d608b6 n/a (index++ + 0x1d8b6) ELF object binary systemd-coredump[3959523]: Process 3959515 (index++) of user 0 dumped core. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libstdc++6:amd64 depends on: ii gcc-12-base 12.2.0-14 ii libc62.36-9 ii libgcc-s112.2.0-14 libstdc++6:amd64 recommends no packages. libstdc++6:amd64 suggests no packages. -- debconf-show failed
Bug#1035472: bug 1035472
This can be closed the issue is no longer occurring. -- Tim McConnell
Bug#464365: gcc-4.2: patch doesn't solve the problem
> ARCH=arm MAKEFLAGS="CC=something" dh_shlibdeps -plibstdc++6-arm-cross > -l/usr/arm-linux-gnu/lib > /usr/bin/perl: error while loading shared libraries: > /usr/arm-linux-gnu/lib/libdl.so.2: ELF file OS ABI invalid That looks like an error running dpkg-shlibdeps itself. It appears that where dh_shlibdeps's man page says -l adds directories to LD_LIBRARY_PATH before running dpkg-shlibdeps, it means that literally - dpkg-shlibdeps does not allow the directories to be specified (directly) by a command-line option. I guess building for x86_64 on i386 let me get away with it. As pointed out in bug #453267 (see discussion starting at around <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453267#41>), dpkg-shlibdeps is fundamentally broken here: the libraries I want it to search are not necessarily the same libraries I want to use to run it. I suppose we just have to wait until that's fixed. I do wonder why the diversions were removed from dkpg-cross before the equivalent functionality was properly implemented in dpkg-dev and debhelper. Hmmm... a possible workaround: Create a fake package build directory that just contains a symlink to /usr/$(DEB_TARGET_GNU_TYPE)/lib (or lib32 or lib64, as appropriate), and pass that to dh_shlibdeps with -L. It's an ugly hack, but does allow dpkg-shlibdeps to find the right libraries without having to modify LD_LIBRARY_PATH. Updated patch attached. (If you're wondering about the use of readlink, it's because although dpkg-shlibdeps does do symlink resolution (which is how this can work), it's only on the last path component and not recursive, and one of the libX directories for biarch targets will already be a symlink.) This patch needs a bit of tidying, as it won't clean properly. -- Tim Bagot, BlueArc Engineering --- debian/rules.d/binary-libstdcxx-cross.mk +++ debian/rules.d/binary-libstdcxx-cross.mk @@ -40,12 +40,19 @@ $(docdir) \ $(PF)/$(DEB_TARGET_GNU_TYPE)/lib64 +dirs_lib32 = \ + $(docdir) \ + $(PF)/$(DEB_TARGET_GNU_TYPE)/lib32 + files_lib = \ $(PF)/$(DEB_TARGET_GNU_TYPE)/lib/libstdc++.so.* files_lib64 = \ $(PF)/$(DEB_TARGET_GNU_TYPE)/lib64/libstdc++.so.* +files_lib32 = \ + $(PF)/$(DEB_TARGET_GNU_TYPE)/lib32/libstdc++.so.* + dirs_dev = \ $(docdir) \ $(PF)/$(DEB_TARGET_GNU_TYPE)/lib \ @@ -124,7 +131,9 @@ dh_makeshlibs -p$(p_lib) -V '$(p_lib) (>= $(DEB_STDCXX_SOVERSION))' -n sed s/$(cross_lib_arch)//g < debian/$(p_lib)/DEBIAN/shlibs > debian/$(p_lib)/DEBIAN/shlibs.fixed mv debian/$(p_lib)/DEBIAN/shlibs.fixed debian/$(p_lib)/DEBIAN/shlibs - ARCH=$(DEB_TARGET_ARCH) MAKEFLAGS="CC=something" dh_shlibdeps -p$(p_lib) + mkdir debian/$(p_lib)-deps + ln -s "`readlink -e /usr/$(DEB_TARGET_GNU_TYPE)/lib`" debian/$(p_lib)-deps/lib + ARCH=$(DEB_TARGET_ARCH) MAKEFLAGS="CC=something" dh_shlibdeps -p$(p_lib) -L$(p_lib)-deps sed 's/\(lib[^ ]*\) /\1$(cross_lib_arch) /g' < debian/$(p_lib).substvars > debian/$(p_lib).substvars.new mv debian/$(p_lib).substvars.new debian/$(p_lib).substvars dh_gencontrol -p$(p_lib) -- -v$(DEB_VERSION) $(common_substvars) @@ -174,11 +183,13 @@ dh_makeshlibs -p$(p_lib64) -V '$(p_lib64) (>= $(DEB_STDCXX_SOVERSION))' -n sed s/$(cross_lib_arch)//g < debian/$(p_lib64)/DEBIAN/shlibs > debian/$(p_lib64)/DEBIAN/shlibs.fixed mv debian/$(p_lib64)/DEBIAN/shlibs.fixed debian/$(p_lib64)/DEBIAN/shlibs - ARCH=$(DEB_TARGET_ARCH) MAKEFLAGS="CC=something" dh_shlibdeps -p$(p_lib64) + mkdir debian/$(p_lib64)-deps + ln -s "`readlink -e /usr/$(DEB_TARGET_GNU_TYPE)/lib64`" debian/$(p_lib64)-deps/lib + ARCH=$(DEB_TARGET_ARCH) MAKEFLAGS="CC=something" dh_shlibdeps -p$(p_lib64) -L$(p_lib64)-deps sed 's/\(lib[^ ]*\) /\1$(cross_lib_arch) /g' < debian/$(p_lib64).substvars > debian/$(p_lib64).substvars.new mv debian/$(p_lib64).substvars.new debian/$(p_lib64).substvars dh_gencontrol -p$(p_lib64) -- -v$(DEB_VERSION) $(common_substvars) - dh_gencontrol -p$(p_dbg64) -- -v$(DEB_VERSION) $(common_substvars) + #dh_gencontrol -p$(p_dbg64) -- -v$(DEB_VERSION) $(common_substvars) dh_installdeb -p$(p_lib64) dh_md5sums -p$(p_lib64) @@ -210,8 +221,8 @@ rm -rf $(d_lib32)/usr/lib32 # End workaround find $(d_lib32) - tar -C $(d_lib32) -c -f - usr/$(DEB_TARGET_GNU_TYPE)/lib/debug | tar -v -C $(d_dbg32) -x -f - - rm -rf $(d_lib32)/usr/$(DEB_TARGET_GNU_TYPE)/lib/debug + tar -C $(d_lib32) -c -f - usr/$(DEB_TARGET_GNU_TYPE)/lib32/debug | tar -v -C $(d_dbg32) -x -f - + rm -rf $(d_lib32)/usr/$(DEB_TARGET_GNU_TYPE)/lib32/debug dh_installdocs -p$(p_lib32) echo "See /$(docdir)/$(p_base) for more information" \ @@ -222,14 +233,16 @@ debian/dh_rmemptydirs -p$(p_lib32) dh_compress -p$(p_lib32) dh_fixperms -p$(p_lib32) - + dh_makeshlibs -p$(p_lib32) -V '$(p_lib32) (>= $(DEB_STDCXX_SOVERSION))' -n sed s/$(cross_lib_arch)//g < deb
Bug#466422: gcc-4.2: broken alternatives for amd64 cross target
Source: gcc-4.2 Version: 4.2.2-7 Severity: normal When building a cross compiler targeting Debian-amd64, the executable prefix is x86_64-linux-gnu, but the alternatives are installed using the prefix x86-64-linux-gnu, i.e. with a hyphen instead of the underscore. e.g.: /usr/bin/x86-64-linux-gnu-gcc -> /etc/alternatives/x86-64-linux-gnu-gcc -> /usr/bin/x86-64-linux-gnu-gcc-4.2, which doesn't exist. The postinst and prerm scripts are generated by these lines in debian/rules.d/binary-gcc-cross.mk: sed 's/cross-/$(TP)/g;s/-ver/$(pkg_ver)/g' < debian/gcc-cross.postinst > debian/$(p_gcc)/DEBIAN/postinst sed 's/cross-/$(TP)/g;s/-ver/$(pkg_ver)/g' < debian/gcc-cross.prerm > debian/$(p_gcc)/DEBIAN/prerm and similarly in binary-cpp-cross.mk and binary-cxx-cross.mk. The problem is that $(TP) has the underscore converted to a hyphen even though the actual executables do not: TP = $(subst _,-,$(DEB_TARGET_GNU_TYPE))- The file names passed to dh_movefiles are OK because they are constructed using $(DEB_TARGET_GNU_TYPE) directly, e.g.: files_gcc = \ $(PF)/bin/$(DEB_TARGET_GNU_TYPE)-gcc$(pkg_ver) \ [...] The minimal patch is to remove the substitution from the definition of $(TP): = --- debian/rules.defs +++ debian/rules.defs @@ -96,7 +96,7 @@ # LS: Library Suffix. Used primarily at the end of cross compiler # library package names (e.g. libgcc-powerpc-cross). DEB_TARGET_ALIAS ?= $(DEB_TARGET_GNU_TYPE) - TP = $(subst _,-,$(DEB_TARGET_GNU_TYPE))- + TP = $(DEB_TARGET_GNU_TYPE)- TS = -$(subst _,-,$(DEB_TARGET_ALIAS)) LS = -$(subst _,-,$(DEB_TARGET_ARCH))-cross endif = Obviously this could be improved by consistently using $(TP) wherever it is appropriate. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.2 depends on: ii binutils2.18.1~cvs20080103-1 The GNU assembler, linker and bina ii cpp-4.2 4.2.2-7 The GNU C preprocessor ii gcc-4.2-base4.2.2-7 The GNU Compiler Collection (base ii libc6 2.7-6GNU C Library: Shared libraries ii libgcc1 1:4.3-20080127-1 GCC support library Versions of packages gcc-4.2 recommends: ii libc6-dev 2.7-6 GNU C Library: Development Librari -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#473107: should provide /usr/lib/libgfortran.so ?
Package: gfortran Version: 4:4.3.0-1 Severity: normal --- Please enter the report below this line. --- Sorry if this is a dumb question, but shouldn't the gfortran package provide /usr/lib/libgfortran.so apt-file seems to think so, at least: > apt-file search /usr/lib/libgfortran.so gfortran: /usr/lib/libgfortran.so but since my last upgrade this link seems to be missing --- System information. --- Architecture: i386 Kernel: Linux 2.6.24-1-686 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.uk.debian.org --- Package information. --- Depends (Version) | Installed ===-+-=== cpp (>= 4:4.2.3-4) | 4:4.2.3-4 gcc (>= 4:4.2.3-4) | 4:4.2.3-4 gfortran-4.3 (>= 4.3.0-1) | 4.3.0-2 -- Tim Gershon University of Warwick +44 (0) 24765 23778 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Could someone explain bug 770025 to me?
Could someone explain the reasoning behind bug 770025 to me? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770025 I'm planning to upgrade from Debian 7 to 8. Why is it necessary for gcc-4.9-base to force the removal of gcc-4.7-base, when these packages share no files in common? In my particular situation, we have software which *must* be compiled using gcc-4.7. I'm a little confused by message #20 which seems to imply that gcc-4.7 could be reinstalled after the upgrade is complete. Thanks, Tim Gokcen
Bug#798029: Impossible to keep gcc-4.7 after upgrade to Debian Jessie
Package: gcc-4.9-base Version: 4.9.2-10 Debian bug 770025 added a "Breaks: gcc-4.7-base (< 4.7.3)" header to gcc-4.9, because it was found in bug 736607 (which relates to gcc-4.8) that the package manager would sometimes leave the system with an older-release version of gcc instead of using the version from Jessie (4.7.3 and up). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770025 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736607 However, then Debian bug 765379 came around and gcc 4.7 was completely removed from Jessie. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765379 As a result it is now impossible to keep gcc 4.7 installed on a Jessie system when upgrading from an earlier release, or to install the package from an older release, even though absolutely nothing would actually break as a result of this. Since the original problem posed in bug 770025 (of the package manager failing to update gcc-4.7) has been fixed, I believe the "Breaks: gcc-4.7-base (<4.7.3)" clause should be removed from gcc-4.9 (and probably from gcc-4.8, too).
Re: Could someone explain bug 770025 to me?
Actually, I think I've figured it out. It looks like bugs 770025, which was an extension of bug 736607, were intended to force gcc-4.7 to be upgraded to the Jessie version. However, these changes were then trumped by bug 765379 which just straight-up removed gcc-4.7 from Debian Jessie. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770025 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736607 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765379 I've opened a new bug to address this issue. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798029
Bug#721720: -floop-parallelize-all misleadingly accepted
Alternatively, failure to perform this requested optimization could be made a warning rather than an error. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/c043526c-03da-470b-b2f0-b394d9d34...@pobox.com
Bug#741960: gcc-4.7: [C++] Bogus narrowing conversion warning when initializing bit-field in union
Package: gcc-4.7
Version: 4.7.2-5
Severity: normal
Dear Maintainer,
Compiling the following as C++ with -Wall:
unsigned int n;
union U { unsigned int x:8; } u = { n };
results in:
$ gcc-4.7 -Wall -c test.cpp
test.cpp:2:39: warning: narrowing conversion of 'n' from 'unsigned int' to
'unsigned char' inside { } is ill-formed in C++11 [-Wnarrowing]
The type of the field U::x is not unsigned char: it is unsigned int.
Since u.x and n have the same type, there is no narrowing conversion
as defined in [dcl.init.list].
(See also )
This bug seems to affect only unions, not ordinary structs.
-- System Information:
Debian Release: 7.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'oldstable-updates'), (500, 'stable'),
(500, 'oldstable'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gcc-4.7 depends on:
ii binutils 2.22-8
ii cpp-4.7 4.7.2-5
ii gcc-4.7-base 4.7.2-5
ii libc6 2.13-38
ii libgcc1 1:4.7.2-5
ii libgmp10 2:5.0.5+dfsg-2
ii libgomp1 4.7.2-5
ii libitm1 4.7.2-5
ii libmpc2 0.9-4
ii libmpfr4 3.1.0-5
ii libquadmath0 4.7.2-5
ii zlib1g1:1.2.7.dfsg-13
Versions of packages gcc-4.7 recommends:
ii libc6-dev 2.13-38
Versions of packages gcc-4.7 suggests:
pn binutils-gold
ii gcc-4.7-doc 4.7.2-2
pn gcc-4.7-locales
ii gcc-4.7-multilib 4.7.2-5
ii libcloog-ppl00.15.11-4
pn libgcc1-dbg
pn libgomp1-dbg
pn libitm1-dbg
pn libmudflap0-4.7-dev
pn libmudflap0-dbg
pn libppl-c2
pn libppl7
pn libquadmath0-dbg
-- no debconf information
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/7cob14u7hv@bazalgette.dev.bluearc.com
Bug#710220: libstdc++6: 4.8.0-8 upgrade breaks system_clock
Package: libstdc++6
Version: 4.8.0-8
Severity: important
Dear Maintainer,
Attached test case gets the current system time using std::chrono and using
gettimeofday, both with millisecond precision. Using libstdc++6 version 4.8.0-7,
this code works properly, both timestamps being identical. However, since
upgrading to 4.8.0-8, the std::chrono version reports a timestamp in seconds
despite the explicit duration_case to milliseconds, when compiling with GCC 4.6
or 4.7. Using libstdc++6 4.8.0-8 with GCC 4.8 results in correct output.
Looking through the preprocessed output, it seems like there is a a mismatch
between the system_clock duration of the preprocessed output (i.e. the duration
field in the system_clock struct generated by the chrono header) and the one
libstdc++ exposes. The output compiled with GCC 4.7 contains a system_clock
struct with a duration typedef'd to std::chrono::nanoseconds, which results in
correct timestamps using libstdc++6 version 4.8.0-7 but doesn't with version
4.8.0-8 (off by a factor of 1000). GCC 4.8 uses a nanosecond duration as well,
but accesses a system_clock within a V2 namespace, which seems to expose a
nanosecond-precision.
I'm guessing the upgrade to libstdc++6 version 4.8.0-8 changed the system_clock
exposed by the library, now using microsecond precision rather than nanosecond
precision (the V2 system_clock seems to be the one offering nanosecond precision
now). This conflicts with the chrono header, which -- due to the
_GLIBCXX_USE_CLOCK_REALTIME definition -- accesses the system_clock with
nanosecond duration.
Best,
Tim
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.8-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libstdc++6 depends on:
ii gcc-4.8-base 4.8.0-8
ii libc6 2.17-3
ii libgcc11:4.8.0-8
ii multiarch-support 2.17-3
libstdc++6 recommends no packages.
libstdc++6 suggests no packages.
-- no debconf information
#include
#include
#include
int main()
{
std::chrono::time_point tp
= std::chrono::high_resolution_clock::now();
printf("C++: %lu\n", std::chrono::duration_cast
(tp.time_since_epoch()).count());
struct timeval tv;
gettimeofday(&tv, NULL);
printf("C: %lu\n", tv.tv_sec * 1000 + tv.tv_usec / 1000);
return 0;
}
Bug#710220:
This also seems to apply to already-compiled binaries, e.g. if I compile the aforementioned testcase with libstdc++6 version 4.8.0-7, which results in correct output, and then upgrade libstdc++6 to version 4.8.0-8, re-running the testcase without recompilation results in faulty output. So since this affects unrelated binaries making use of std::chrono, without requiring recompilation, I guess the impact of this bug is quite a bit higher... -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALLU6nn_KMzhoQefeNtW3sDXmjxpcJOvqv5D6Hq1g3=aszq...@mail.gmail.com
Bug#710220: libstdc++6: 4.8.0-8 upgrade breaks system_clock
Hi Matthias, > Please could you name the software where you did see this failure? I only spotted this regression in my own development code, so it seems that the impact is limited after all. Thanks, Tim -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/callu6nnf1c-sdwgor3mdfnm2tvlesojck-4af_xkh3vfpo8...@mail.gmail.com
Bug#710220: libstdc++6: 4.8.0-8 upgrade breaks system_clock
Is there a workaround for this bug, while waiting for gcc <4.8 to get fixed? Holding libstdc++6 back tends to break stuff. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALLU6n=pzzwr6pje+3kllnzvtmx-8iu8hs-07vdbzejq41y...@mail.gmail.com
Technical Forums
If you are unable to view the images in this email, please copy and paste the following url into your browser... http://www.haestad.com/forums/09 debian-gcc@lists.debian.org not part of the Civil Engineering community? Reply to this message with the subject " stop ". 11546-1013201
Bug#333733: mysterious source file
Note that in the gcc subversion repository, the file listed in the assertion does not exist for the 4.0.2 release tag. In the 4.0.2 release, GtkImage is in a pure Java file; the jni tree only has GtkImagePainter. See: http://gcc.gnu.org/viewcvs/tags/gcc_4_0_2_release/libjava/jni/gtk-peer/ and http://gcc.gnu.org/viewcvs/tags/gcc_4_0_2_release/libjava/gnu/java/awt/peer/gtk/ So this seems to be a debian packaging problem, with a non-4.0.2 libgcj marked as 4.0.2. In fact, the jni/..._GtkImage.c isn't in 4.0.0/4.0.1 either, nor is it in 4.1 (where the entire jni tree seems to have been removed), so I'm at a loss as to where it comes from. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/34628] [4.2/4.3 Regression] problems with inlining on ARM
-- tim at buttersideup dot com changed: What|Removed |Added CC||tim at buttersideup dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
