Bug#1021167: fix building glibc on arc
Package: src:glibc Version: 2.35-1 Severity: important Tags: sid bookworm patch Please fix building glibc on arc, both for 2.35 and 2.36. --- a/debian/rules.d/control.mk +++ b/debian/rules.d/control.mk @@ -1,7 +1,7 @@ libc_packages := libc6 libc6.1 libc0.1 libc0.3 libc0_1_archs := kfreebsd-amd64 kfreebsd-i386 libc0_3_archs := hurd-i386 -libc6_archs := amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el \ +libc6_archs := amd64 arc arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el \ mipsn32r6 mipsn32r6el mips64r6 mips64r6el nios2 powerpc ppc64 ppc64el riscv64 \ sparc sparc64 s390x sh3 sh4 x32 libc6_1_archs := alpha ia64 --- a/debian/control +++ b/debian/control @@ -158,7 +158,7 @@ slow services like LDAP, NIS or NIS+. Package: libc6 -Architecture: amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el nios2 powerpc ppc64 ppc64el riscv64 sparc sparc64 s390x sh3 sh4 x32 +Architecture: amd64 arc arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el nios2 powerpc ppc64 ppc64el riscv64 sparc sparc64 s390x sh3 sh4 x32 Section: libs Priority: optional Multi-Arch: same @@ -190,7 +190,7 @@ and the standard math library, as well as many others. Package: libc6-dev -Architecture: amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el nios2 powerpc ppc64 ppc64el riscv64 sparc sparc64 s390x sh3 sh4 x32 +Architecture: amd64 arc arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el nios2 powerpc ppc64 ppc64el riscv64 sparc sparc64 s390x sh3 sh4 x32 Section: libdevel Priority: optional Multi-Arch: same @@ -205,7 +205,7 @@ and link programs which use the standard C library. Package: libc6-dbg -Architecture: amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el nios2 powerpc ppc64 ppc64el riscv64 sparc sparc64 s390x sh3 sh4 x32 +Architecture: amd64 arc arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el nios2 powerpc ppc64 ppc64el riscv64 sparc sparc64 s390x sh3 sh4 x32 Section: debug Priority: optional Multi-Arch: same @@ -218,7 +218,7 @@ Package: libc6-udeb Package-Type: udeb -Architecture: amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el nios2 powerpc ppc64 ppc64el riscv64 sparc sparc64 s390x sh3 sh4 x32 +Architecture: amd64 arc arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el nios2 powerpc ppc64 ppc64el riscv64 sparc sparc64 s390x sh3 sh4 x32 Section: debian-installer Priority: optional Provides: libc6, libc-udeb, libnss-dns-udeb, libnss-files-udeb
Bug#1018071: glibc causes ftbfs in c-t-b-*
Package: src:glibc Version: 2.34-5 Severity: serious https://salsa.debian.org/glibc-team/glibc/-/commit/776abab introduces sed -i \ + -e "usr/lib/.*\.a/d" \ -e "/LIBDIR.*\.a /d" \ -e "s#TMPDIR#$(debian-tmp)#g" \ -e "s#RTLDDIR#$$rtlddir#g" \ that probably should be -e "/usr\/lib\/.*\.a/d", plus Makefile quoting [...] for t in $templates ; do \ for s in debian/$t$pass.* ; do \ t=`echo $s | sed -e "s#libc\(.*\)$pass#libc6\1$suffix#"` ; \ echo "Generating $t ..."; \ if [ "$s" != "$t" ] ; then \ cp $s $t ; \ fi ; \ sed -i \ -e "usr/lib/.*\.a/d" \ -e "/LIBDIR.*\.a /d" \ -e "s#TMPDIR#debian/tmp#g" \ -e "s#RTLDDIR#$rtlddir#g" \ -e "s#SLIBDIR#$slibdir#g" \ -e "s#LIBDIR#$libdir#g" \ -e "/gdb/d" \ -e "/audit/d" \ $t; \ done ; \ done Generating debian/libc6-dev.NEWS ... sed: -e expression #1, char 1: unknown command: `u' Generating debian/libc6-dev.install ... sed: -e expression #1, char 1: unknown command: `u' Generating debian/libc6-dev.install.hurd-i386 ... sed: -e expression #1, char 1: unknown command: `u' Generating debian/libc6-dev.lintian-overrides ... sed: -e expression #1, char 1: unknown command: `u' make[1]: *** [debian/rules.d/debhelper.mk:152: /home/packages/cross/base/p/cross-toolchain-base-ports/glibc-2.34/stamp-dir/debhelper_libc] Error 1
Bug#991897: removal of the any/local-rtlddir-cross.diff patch broke cross builds
Package: src:glibc Version: 2.31-13 Severity: serious Tags: sid bullseye when cross-building glibc in the c-t-b packages, the libc.so linker file for some non-default multilib builds like the sparc build for sparc64 is broken, leading to build failures for at least all gcc-N cross multilib packages at least. $ cat usr/lib32/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-sparc) GROUP ( /lib32/libc.so.6 /usr/lib32/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) ) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985617#62 says that the maintainer is investigating, but apparently this never happened. Accepting such a change that late into bullseye is interesting ...
Bug#982360: test all passes before failing the build (in case of regressions)
Package: src:glibc
Version: 2.31-9
Tags: patch
test all passes before failing the build (in case of regressions). I'd like to
see everything which probably needs fixing, not just the first failure.
* Run checks for every pass before failing the build.
diff --git a/debian/rules b/debian/rules
index cc11e6d2..b6fde574 100755
--- a/debian/rules
+++ b/debian/rules
@@ -203,7 +203,24 @@ clean:: unpatch
# Required Debian targets
build-arch: $(stamp)info \
$(patsubst %,$(stamp)build_%,$(GLIBC_PASSES)) \
- $(patsubst %,$(stamp)check_%,$(GLIBC_PASSES))
+ $(patsubst %,$(stamp)check_%,$(GLIBC_PASSES)) \
+ post-check
+post-check: $(patsubst %,$(stamp)check_%,$(GLIBC_PASSES))
+ @echo "CHECK SUMMARY"
+ @for pass in $(patsubst %,$(stamp)check_%,$(GLIBC_PASSES)); do \
+ if [ -f $${pass}_passed ]; then \
+ echo "check for $$(basename $$pass) passed"; \
+ fi; \
+ done
+ @fail=0; \
+ for pass in $(patsubst %,$(stamp)check_%,$(GLIBC_PASSES)); do \
+ if [ -f $${pass}_failed ]; then \
+ echo "check for $$(basename $$pass) failed"; \
+ fail=1; \
+ fi; \
+ done; \
+ exit $$fail
+
ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
build-arch: $(stamp)build_C.UTF-8 \
$(stamp)build_locales-all
diff --git a/debian/rules.d/build.mk b/debian/rules.d/build.mk
index 3ede4f5d..74c7a2f1 100644
--- a/debian/rules.d/build.mk
+++ b/debian/rules.d/build.mk
@@ -170,12 +170,13 @@ $(stamp)check_%: $(stamp)build_%
echo "+-+" ; \
grep -E '^FAIL:' $(DEB_BUILDDIR)/tests.sum | sort ; \
if ! dpkg-parsechangelog | egrep -q '^Version:.*\+deb[0-9]+u[0-9]+' ; then \
- exit 1 ; \
+ touch $@_failed ; \
fi ; \
else \
echo "+-+" ; \
echo "| Passed regression testing. Give yourself a hearty pat on the back. |" ; \
echo "+-+" ; \
+ touch $@_passed ; \
fi ; \
fi
touch $@
Bug#982203: all/local-ldd.diff patch needs to be updated or dropped for glibc 2.33
Package: src:glibc all/local-ldd.diff patch needs to be updated or dropped for glibc 2.33. see https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1914860
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On 7/8/20 9:21 PM, Paul Gevers wrote: > Hi, > > [Note, this e-mail may look familiar as it is mostly copied over from > the buster call, not much has changed, AFAICT]. > > As part of the interim architecture qualification for bullseye, we > request that DSA, the security team, Wanna build, and the toolchain > maintainers review and update their list of known concerns for bullseye > release architectures. > > Summary of the current concerns and issues: > * DSA have announced a blocking issue for armel and armhf (see below) > * Concerns from DSA about ppc64el and s390x have been carried over from >(stretch and) buster. > * Concerns from the GCC maintainers about i386, armel, armhf, mips64el >and mipsel have been carried over from (stretch and) buster. > > If the issues and concerns from you or your team are not up to date, > then please follow up to this email (keeping debian-release@l.d.o in CC > to ensure we are notified). > > Whilst porters remain ultimately responsible for ensuring the > architectures are ready for release, we do expect that you / your team > are willing to assist with clarifications of the concerns and to apply > patches/changes in a timely manner to resolve the concerns. > > > List of blocking issues by architecture > === > > The following is a summary from the current architecture qualification > table. > > armel/armhf: > > > * Undesirable to keep the hardware running beyond 2020. armhf VM >support uncertain. (DSA) >- Source: [DSA Sprint report] >- I was under the impression that this issue has been resolved (at > least for armhf) by now, but we like a fresh statement on this. > > > [DSA Sprint report]: > https://lists.debian.org/debian-project/2018/02/msg4.html > > > List of concerns for architectures > == > > The following is a summary from the current architecture qualification > table. > > * Concern for ppc64el and s390x: we are dependent on sponsors for >hardware. >(Raised by DSA; carried over from stretch and buster) > > * Concern for armel and armhf: only secondary upstream support in GCC >(Raised by the GCC maintainer; carried over from stretch and buster) this was wrong, and still is wrong. See https://gcc.gnu.org/gcc-10/criteria.html. arm-linux-gnueabi is listed as a primary platform. The arm-linux-gnueabihf triplet never gained much traction outside of Debian/Ubuntu, so should be included. armel might be special because the use of the libatomics library is mandatory. > * Concern for mips, mips64el, mipsel and ppc64el: no upstream support >in GCC; Debian carries patches in binutils and GCC that haven't been >integrated upstream even after a long time. >(Raised by the GCC maintainer; carried over from stretch and buster) this is wrong for ppc64el (at least I didn't raise that). powerpc64-unknown-linux-gnu is listed as a primary platform. https://gcc.gnu.org/gcc-8/criteria.html explicitly lists the little endian variant, and after checking with upstream it looks like an omission to document that for GCC 9 and GCC 10 as well. A concern that appears to get ignored by the release team is that both mipsel and mips64el are neither a primary or a secondary release architecture. You seem to mention it in the summary, but don't have it in the list of concerns. GCC upstream only lists the bare metal mips*elf target, plus I don't see any other test results getting posted to the gcc-testresults ML besides for the Debian builds. Please also note the 100+ test failures for mips* in binutils, which are not addressed for years. See https://sourceware.org/pipermail/binutils/2020-July/112201.html mipsel now adds another work around to build 64bit compilers to be able to build larger projects (see e.g. binutils64). > Architecture status > === > > These are the architectures currently being built for bullseye: > > * Intel/AMD-based: amd64, i386 > * ARM-based: arm64, armel, armhf > * MIPS-based: mipsel, mips64el > * Other: ppc64el, s390x > > If the blocking issues cannot be resolved, affected architectures are at > risk of removal from testing before bullseye is frozen. > > We are currently unaware of any new architectures likely to be ready in > time for inclusion in bullseye. > > On behalf of the release team, > Paul Gevers >
Bug#962457: installation of finclude/math-vector-fortran.h
Package: src:glibc Version: 2.30-8 Severity: important Tags: sid bullseye 2.30-2 removed the installation of finclude/math-vector-fortran.h, which leads to build errors like reported in https://launchpad.net/bugs/1879092 glibc (2.30-2) unstable; urgency=medium * debian/rules.d/build.mk: do not install for now as it is not multiarch safe. Forwarded the discussion to https://gcc.gnu.org/pipermail/gcc/2020-June/232779.html It looks like the current x86 variant of this file is conditionalized and installable on any architecture. So instead of dropping the file, just install the x86 variant on every architecture.
Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt
On 3/4/20 9:48 AM, Florian Weimer wrote: > * Matthias Klose: > >> On 3/4/20 9:33 AM, Florian Weimer wrote: >>> * Matthias Klose: >>> >>>> The __glibc_has_include macro needs to be restored until GCC is rebuilt. At >>>> least on s390x, you get a non-wrorking compiler, which at least cannot >>>> glibc >>>> anymore. The macro is still referenced in the include-fixed directory. >>>> >>>> Seen with the 2.31 branch, but I see that this is also backported to 2.30. >>> >>> This is a bug in the gcc package. It must not run fixincludes, to >>> avoid producing mutually incompatible headers because only a subset of >>> them is rewritten. >> >> Is this something which should be done upstream? Or just don't include any >> fixed header in the GCC packages? > > Distributions should never run fixincludes for this reason. This is a > hack for installing compilers as non-root on proprietary systems, > where you can't fix the headers. > > Other distributions routinely backport compiler compatibility fixes > into glibc (even into stable releases), and I think this is the way it > has to be done. > >> Anyway, either glibc or GCC has to be fixed to avoid a non-working compiler. > > If I recall correctly, the header is broken anyway because linux is > rewritten into __linux__, due to a fixincludes bug. > > It should be possible to hide the header by having a file with an > #include directive with an absolute path in a directory used during > the build. ok, now removing that leads to: $ cat foo.c #include $ gcc -c foo.c In file included from foo.c:1: /usr/include/limits.h:124:26: error: no include path in which to search for limits.h 124 | # include_next | ^ wondering if other distros patch glibc for that ...
Bug#953657: generate dependencies on libgcc-sN instead of libgccN
Package: src:glibc Version: 2.29-10 Tags: patch Please generate dependencies on libgcc-sN instead of libgccN. * libc6: Depend on libgcc-sN instead of libgccN. diff -Nru glibc-2.31/debian/rules.d/debhelper.mk glibc-2.31/debian/rules.d/debhelper.mk --- glibc-2.31/debian/rules.d/debhelper.mk 2020-03-02 15:24:11.0 + +++ glibc-2.31/debian/rules.d/debhelper.mk 2020-03-07 08:34:11.0 + @@ -166,7 +166,7 @@ # Generate common substvars files. : > tmp.substvars ifeq ($(filter stage1 stage2,$(DEB_BUILD_PROFILES)),) - echo 'libgcc:Depends=libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4 [hppa]' >> tmp.substvars + echo 'libgcc:Depends=libgcc-s1 [!hppa !m68k], libgcc-s2 [m68k], libgcc-s4 [hppa]' >> tmp.substvars echo 'libcrypt:Depends=libcrypt1' >> tmp.substvars echo 'libcrypt-dev:Depends=libcrypt-dev' >> tmp.substvars endif
Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt
On 3/4/20 10:04 PM, Aurelien Jarno wrote: > On 2020-03-04 09:33, Matthias Klose wrote: >> Package: src:glibc >> Version: 2.30-0experimental2 >> Severity: important >> Tags: sid bullseye patch >> >> The __glibc_has_include macro needs to be restored until GCC is rebuilt. At > > I am fine reverting temporarily that commit. But it fixes a real issue, > so the problem has to be fixed on the gcc side before the bullseye release. yes, that would be temporary. >> least on s390x, you get a non-wrorking compiler, which at least cannot glibc >> anymore. The macro is still referenced in the include-fixed directory. > > Do you have more details in the issue? The include-fixed directory only > contains limits.h and syslimits.h and none of them have a reference to > __glibc_has_include. no build log anymore, but it was bits/statx.h on s390x. Matthias
Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt
On 3/4/20 9:33 AM, Florian Weimer wrote: > * Matthias Klose: > >> The __glibc_has_include macro needs to be restored until GCC is rebuilt. At >> least on s390x, you get a non-wrorking compiler, which at least cannot glibc >> anymore. The macro is still referenced in the include-fixed directory. >> >> Seen with the 2.31 branch, but I see that this is also backported to 2.30. > > This is a bug in the gcc package. It must not run fixincludes, to > avoid producing mutually incompatible headers because only a subset of > them is rewritten. Is this something which should be done upstream? Or just don't include any fixed header in the GCC packages? Anyway, either glibc or GCC has to be fixed to avoid a non-working compiler.
Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt
Package: src:glibc Version: 2.30-0experimental2 Severity: important Tags: sid bullseye patch The __glibc_has_include macro needs to be restored until GCC is rebuilt. At least on s390x, you get a non-wrorking compiler, which at least cannot glibc anymore. The macro is still referenced in the include-fixed directory. Seen with the 2.31 branch, but I see that this is also backported to 2.30. Index: b/misc/sys/cdefs.h === --- a/misc/sys/cdefs.h +++ b/misc/sys/cdefs.h @@ -412,6 +412,14 @@ # define __glibc_has_attribute(attr) 0 #endif +#ifdef __has_include +/* Do not use a function-like macro, so that __has_include can inhibit + macro expansion. */ +# define __glibc_has_include __has_include +#else +# define __glibc_has_include(header) 0 +#endif + #if (!defined _Noreturn \ && (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) < 201112 \ && !__GNUC_PREREQ (4,7))
Bug#934823: glibc needs an update for linux-5.2 kernel headers (alpha)
Package: src:glibc Version: 2.28-10 Severity: sersious Tags: sid bullseye patch currently c-t-b-p ftbfs on alpha. A patch needs to be backported. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836064 the c-t-b-ports package ftbfs: /bin/bash ../scripts/move-if-change /<>/glibc-2.29/build-tree/alpha-libc/gnu/lib-names.T /<>/glibc-2.29/build-tree/alpha-libc/gnu/lib-names.h touch /<>/glibc-2.29/build-tree/alpha-libc/gnu/lib-names.stmp if test -r /<>/glibc-2.29/build-tree/alpha-libc/csu/abi-tag.h.new; then mv -f /<>/glibc-2.29/build-tree/alpha-libc/csu/abi-tag.h.new /<>/glibc-2.29/build-tree/alpha-libc/csu/abi-tag.h; \ else echo >&2 'This configuration not matched in ../abi-tags'; exit 1; fi In file included from :1: ../sysdeps/unix/sysv/linux/alpha/sysdep.h:54: error: "__NR_osf_shmat" redefined [-Werror] #define __NR_osf_shmat 209 In file included from ../sysdeps/unix/sysv/linux/sys/syscall.h:24, from ../sysdeps/unix/sysdep.h:20, from ../sysdeps/unix/alpha/sysdep.h:19, from ../sysdeps/unix/sysv/linux/alpha/sysdep.h:29, from :1: /<>/glibc-2.29/debian/include/asm/unistd.h:8: note: this is the location of the previous definition #define __NR_osf_shmat __NR_shmat cc1: all warnings being treated as errors a definition of __NR_osf_shmat was added during the 5.1 cycle: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=12b57c5c70f397a9410411d4e348096edada20f9 Looks like a fix has been applied to upstream glibc: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d5ecee822e72a2fd156338ab2be2f2e70a1da55a
Re: cross-toolchain-base: FTBFS: applying patches fails
On 08.01.19 21:08, Paul Gevers wrote: > user debian...@lists.debian.org > usertags needs-update > thanks > > Hi all, > > On Sat, 29 Dec 2018 23:46:40 +0100 Lucas Nussbaum wrote: >> During a rebuild of all packages in sid, your package failed to build >> on amd64. >> >> Relevant part (hopefully): >>> debian/rules build >>> linux: 4.19.12-1 / 4.18.20-2cross2 >>> glibc: 2.28-4 / 2.28-2cross2 >>> >>> old linux version: 4.18.20-2 / 2 >>> old glibc version: 2.28-2 / 2 >>> >>> new linux version: 4.19.12-1cross1 >>> new glibc version: 2.28-4cross1 >>> START stamp-dir/init-glibc >>> rm -rf glibc-2.28 >>> tar -x -f /usr/src/glibc/glibc-2.28.tar.xz >>> cp -a /usr/src/glibc/debian/ glibc-2.28 >>> cd glibc-2.28 ; \ >>> QUILT_PATCHES=/<>/debian/patches/glibc/debian quilt --quiltrc >>> /dev/null push -a && \ >>> rm -rf .pc/ >>> Applying patch dpkg-shlibs.patch >>> patching file debian/rules.d/debhelper.mk >>> >>> Applying patch local-kill-locales.patch >>> patching file debian/rules >>> patching file localedata/SUPPORTED >>> >>> Applying patch glibc-build-tools.diff >>> patching file debian/rules >>> >>> Applying patch gcc-8-armel.diff >>> patching file debian/sysdeps/armel.mk >>> Hunk #1 FAILED at 1. >>> 1 out of 1 hunk FAILED -- rejects in file debian/sysdeps/armel.mk >>> Patch gcc-8-armel.diff does not apply (enforce with -f) >>> make: *** [debian/rules:436: stamp-dir/init-glibc] Error 1 > > I hope you are aware that the same issue is currently blocking the > latest version of glibc from migrating to testing as the autopkgtest of > cross-toolchain-base fails on the same error: > > https://ci.debian.net/data/autopkgtest/testing/amd64/c/cross-toolchain-base/1663556/log.gz please see https://lists.debian.org/debian-mips/2019/07/msg1.html
Re: Buster / GCC 7.4 Problem
On 18.12.18 16:39, Hagen Paul Pfeifer wrote: > Hallo, > > since December 7.3 to 7.4 switch I am not able to compile Yocto anymore: > >> | make[3]: Entering directory > '/home/pfeifer/git/p/p-core/build/tmp/work/x86_64-linux/m4-native/1.4.18-r0/build/lib' > > > | gcc -I. -I../../m4-1.4.18/lib > -isystem/home/pfeifer/git/p/p-core/build/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recip > e-sysroot-native/usr/include > -isystem/home/pfeifer/git/p/p-core/build/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot- > native/usr/include -O2 -pipe -c -o freadahead.o > ../../m4-1.4.18/lib/freadahead.c > > > | gcc -I. -I../../m4-1.4.18/lib > -isystem/home/pfeifer/git/p/p-core/build/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recip > e-sysroot-native/usr/include > -isystem/home/pfeifer/git/p/p-core/build/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot- > native/usr/include -O2 -pipe -c -o fseeko.o ../../m4-1.4.18/lib/fseeko.c > > > | ../../m4-1.4.18/lib/freadahead.c: In function ‘freadahead’: > > > | ../../m4-1.4.18/lib/freadahead.c:92:3: error: #error "Please port > gnulib freadahead.c to your platform! Look at the definition of fflush > , fread, ungetc on your system, then report this to bug-gnulib." > > > | #error "Please port gnulib freadahead.c to your platform! Look at the > definition of fflush, fread, ungetc on your system, then report > this to bug-gnulib." > > > |^ > > > | ../../m4-1.4.18/lib/fseeko.c: In function ‘rpl_fseeko’: > > > | ../../m4-1.4.18/lib/fseeko.c:110:4: error: #error "Please port gnulib > fseeko.c to your platform! Look at the code in fseeko.c, then repo > rt this to bug-gnulib." > > > |#error "Please port gnulib fseeko.c to your platform! Look at the > code in fseeko.c, then report this to bug-gnulib." > > | ^ > > | make[3]: *** [Makefile:1915: freadahead.o] Error 1 > > > This happens in stage1 cross compiling step during m4 compiling. Any ideas? this is unrelated to GCC, but happens with glibc 2.28.
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On 07.07.18 17:24, YunQiang Su wrote: > Niels Thykier 于2018年6月28日周四 上午4:06写道： >> List of concerns for architectures >> == >> >> The following is a summary from the current architecture qualification >> table. >> >> * Concern for ppc64el and s390x: we are dependent on sponsors for >>hardware. >>(Raised by DSA; carried over from stretch) >> >> * Concern for armel and armhf: only secondary upstream support in GCC >>(Raised by the GCC maintainer; carried over from stretch) I don't think anybody objected about the status for armhf. I didn't follow armel issues too closely. >> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support >>in GCC >>(Raised by the GCC maintainer; carried over from stretch) >> > > This is a misunderstanding as MIPS company had some unrest in recent half > year. > Currently we are stable now, and the shape of gcc upstream is also good. This is an optimistic view. While currently not having any RC issues, we still see mips* specific issues popping up more often than on other release architectures. According to https://gcc.gnu.org/gcc-8/criteria.html there is no mips*-linux* target listed as either primary or secondary platform. As far as I understand the mips porters argue that this is covered by mipsisa64-elf, a bare metal target. I don't agree with this view, because - testing is missing on mips*-linux-* targets. If you look at the gcc-testresults ML, you see only test reports submitted for the Debian GCC packages, nothing else. - A bare metal target is usually only built/used for C and C++. I doubt that other frontends are tested. - Configurations like libgcjit are not tested/used upstream, and not addressed. See #798710. The Debian bug tracking for the MIPS port could be better, I usually need some pings to the MIPS porters to get things forwarded or addressed. To me it looks sometimes that Debian is used for testing by upstream, and for that the mips architectures don't need to be release architectures. Matthias
Bug#881646: don't build multilib library packages in stage1
Package: src:glibc Version: 2.24-17 Severity: important Tags: patch The recent debhelper changes expose a bug building stage1, because glibc build the multilib library packages in stage1, which shouldn't be built (only all dev packages should be built). --- glibc-2.24/debian/rules~ 2017-08-26 11:03:41.0 +0200 +++ glibc-2.24/debian/rules 2017-11-13 21:26:07.428822436 +0100 @@ -164,8 +164,12 @@ -include debian/sysdeps/$(DEB_HOST_ARCH).mk ifeq ($(filter nobiarch,$(DEB_BUILD_PROFILES)),) -GLIBC_PASSES += $(GLIBC_MULTILIB_PASSES) -DEB_ARCH_REGULAR_PACKAGES += $(DEB_ARCH_MULTILIB_PACKAGES) + GLIBC_PASSES += $(GLIBC_MULTILIB_PASSES) + ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),) +DEB_ARCH_REGULAR_PACKAGES += $(foreach p,$(DEB_ARCH_MULTILIB_PACKAGES), $(if $(findstring -dev,$(p)), $(p))) + else +DEB_ARCH_REGULAR_PACKAGES += $(DEB_ARCH_MULTILIB_PACKAGES) + endif endif # Don't run dh_strip on this package
Bug#881455: glibc: don't build hardware enhancement library packages when stage1
we shouldn't build these for stage2 either.
Bug#881636: fix stage1/stage2 builds with updated debhelper
Package: src:glibc Version: 2.24-17 Tags: patch debhelper got a bit more strict, and now fails to build libc6.1-alphaev67 during stage1 and stage2. The solution is not to build this optimized package during stage1 and stage2. --- glibc-2.24/debian/sysdeps/alpha.mk~ 2017-06-19 17:36:06.0 +0200 +++ glibc-2.24/debian/sysdeps/alpha.mk 2017-11-13 20:01:11.276751435 +0100 @@ -2,8 +2,10 @@ libc = libc6.1 # build an ev67 optimized library +ifeq (,$(filter stage1 stage2, $(DEB_BUILD_PROFILES))) GLIBC_PASSES += alphaev67 DEB_ARCH_REGULAR_PACKAGES += libc6.1-alphaev67 +endif alphaev67_configure_target = alphaev67-linux-gnu alphaev67_CC = $(CC) -mcpu=ev67 -mtune=ev67 alphaev67_CXX = $(CXX) -mcpu=ev67 -mtune=ev67
Bug#874491: [patch] fix glibc-2.25 /26 stage1 build
Package: src:glibc Tags: patch fix glibc-2.25 /26 stage1 build. The python hooks are not installed for the stage1 build. --- a/debian/rules.d/debhelper.mk +++ b/debian/rules.d/debhelper.mk @@ -220,6 +220,7 @@ -e "s#RTLDDIR#$$rtlddir#g" \ -e "s#SLIBDIR#$$slibdir#g" \ -e "s#LIBDIR#$$libdir#g" \ + -e "/gdb/d" \ $$t; \ done ; \ done
Bug#870257: Add conflicts for multilib development packages
Package: src:glibc
Version: 2.24-12
Tags: patch
Please add conflicts for the multilib development packages. There are bug
reports with foreign architectures that try to install both libc6-dev-i386 and
libc6-dev-amd64 packages, and then failing because of conflicts in /usr/include.
This patch adds the conflicts for all the known multilib pairs/triples.
* Add conflicts for multilib development packages.
diff -Nru glibc-2.24/debian/control.in/amd64 glibc-2.24/debian/control.in/amd64
--- glibc-2.24/debian/control.in/amd64 2017-06-18 16:13:52.0 +0200
+++ glibc-2.24/debian/control.in/amd64 2017-07-31 13:03:42.0 +0200
@@ -16,6 +16,15 @@
Depends: libc6-amd64 (= ${binary:Version}), libc6-dev (= ${binary:Version}), ${misc:Depends}
Recommends: gcc-multilib
Provides: lib64c-dev
+Conflicts: libc6-dev-i386,
+ libc6-dev-mips32,
+ libc6-dev-mips64,
+ libc6-dev-mipsn32,
+ libc6-dev-powerpc,
+ libc6-dev-ppc64,
+ libc6-dev-sparc,
+ libc6-dev-sparc64,
+ libc6-dev-x32
Build-Profiles:
Description: GNU C Library: 64bit Development Libraries for AMD64
Contains the symlinks and object files needed to compile and link programs
diff -Nru glibc-2.24/debian/control.in/i386 glibc-2.24/debian/control.in/i386
--- glibc-2.24/debian/control.in/i386 2017-06-18 16:13:52.0 +0200
+++ glibc-2.24/debian/control.in/i386 2017-07-31 13:03:42.0 +0200
@@ -17,6 +17,15 @@
Provides: lib32c-dev
Depends: libc6-i386 (= ${binary:Version}), libc6-dev (= ${binary:Version}), ${misc:Depends}
Recommends: gcc-multilib
+Conflicts: libc6-dev-amd64,
+ libc6-dev-mips32,
+ libc6-dev-mips64,
+ libc6-dev-mipsn32,
+ libc6-dev-powerpc,
+ libc6-dev-ppc64,
+ libc6-dev-sparc,
+ libc6-dev-sparc64,
+ libc6-dev-x32
Build-Profiles:
Description: GNU C Library: 32-bit development libraries for AMD64
Contains the symlinks and object files needed to compile and link programs
diff -Nru glibc-2.24/debian/control.in/mips32 glibc-2.24/debian/control.in/mips32
--- glibc-2.24/debian/control.in/mips32 2017-06-18 16:13:52.0 +0200
+++ glibc-2.24/debian/control.in/mips32 2017-07-31 13:03:42.0 +0200
@@ -19,6 +19,15 @@
libc6-dev-mips64 (= ${binary:Version}) [mipsn32 mipsn32el],
${misc:Depends}
Recommends: gcc-multilib
+Conflicts: libc6-dev-amd64,
+ libc6-dev-i386,
+ libc6-dev-mips64,
+ libc6-dev-mipsn32,
+ libc6-dev-powerpc,
+ libc6-dev-ppc64,
+ libc6-dev-sparc,
+ libc6-dev-sparc64,
+ libc6-dev-x32
Build-Profiles:
Description: GNU C Library: o32 Development Libraries for MIPS
Contains the symlinks and object files needed to compile and link programs
diff -Nru glibc-2.24/debian/control.in/mips64 glibc-2.24/debian/control.in/mips64
--- glibc-2.24/debian/control.in/mips64 2017-06-18 16:13:52.0 +0200
+++ glibc-2.24/debian/control.in/mips64 2017-07-31 13:03:42.0 +0200
@@ -16,6 +16,15 @@
Provides: lib64c-dev
Depends: libc6-mips64 (= ${binary:Version}), libc6-dev (= ${binary:Version}), ${misc:Depends}
Recommends: gcc-multilib
+Conflicts: libc6-dev-amd64,
+ libc6-dev-i386,
+ libc6-dev-mips32,
+ libc6-dev-mipsn32,
+ libc6-dev-powerpc,
+ libc6-dev-ppc64,
+ libc6-dev-sparc,
+ libc6-dev-sparc64,
+ libc6-dev-x32
Build-Profiles:
Description: GNU C Library: 64bit Development Libraries for MIPS64
Contains the symlinks and object files needed to compile and link programs
diff -Nru glibc-2.24/debian/control.in/mipsn32 glibc-2.24/debian/control.in/mipsn32
--- glibc-2.24/debian/control.in/mipsn32 2017-06-18 16:13:52.0 +0200
+++ glibc-2.24/debian/control.in/mipsn32 2017-07-31 13:03:42.0 +0200
@@ -16,6 +16,15 @@
Provides: libn32c-dev
Depends: libc6-mipsn32 (= ${binary:Version}), libc6-dev-mips64 (= ${binary:Version}) [mips mipsel], libc6-dev (= ${binary:Version}), ${misc:Depends}
Recommends: gcc-multilib
+Conflicts: libc6-dev-amd64,
+ libc6-dev-i386,
+ libc6-dev-mips32,
+ libc6-dev-mips64,
+ libc6-dev-powerpc,
+ libc6-dev-ppc64,
+ libc6-dev-sparc,
+ libc6-dev-sparc64,
+ libc6-dev-x32
Build-Profiles:
Description: GNU C Library: n32 Development Libraries for MIPS64
Contains the symlinks and object files needed to compile and link programs
diff -Nru glibc-2.24/debian/control.in/powerpc glibc-2.24/debian/control.in/powerpc
--- glibc-2.24/debian/control.in/powerpc 2017-06-18 16:13:52.0 +0200
+++ glibc-2.24/debian/control.in/powerpc 2017-07-31 13:03:42.0 +0200
@@ -16,6 +16,15 @@
Provides: lib32c-dev
Depends: libc6-powerpc (= ${binary:Version}), libc6-dev (= ${binary:Version}), ${misc:Depends}
Recommends: gcc-multilib
+Conflicts: libc6-dev-amd64,
+ libc6-dev-i386,
+ libc6-dev-mips32,
+ libc6-dev-mips64,
+ libc6-dev-mipsn32,
+ libc6-dev-ppc64,
+ libc6-dev-sparc,
+ libc6-dev-sparc64,
+ libc6-dev-x32
Build-Profiles:
Description: GNU C Library: 32bit powerpc development libraries for ppc64
Contains the symlinks and object files needed to compile and link programs
diff -Nru glibc-2.24/debian/control.in/ppc64 glibc-2.24/debian/control.in/ppc64
---
Bug#845544: allow to inject linux-libc-dev dependency for cross-toolchain-base builds
Package: src:glibc
Version: 2.24-6
Tags: patch
cross-toolchain-base builds both linux-libc-dev and libc-dev packages at the
same time, without having an linux-libc-dev installed. just allow to inject that
dependency by the build environment. It's better than having a local patch in
the cross-toolchain-base package which can fail to apply with further updates.
diff -Nru glibc-2.24/debian/changelog glibc-2.24/debian/changelog
--- glibc-2.24/debian/changelog 2016-11-21 18:22:48.0 +
+++ glibc-2.24/debian/changelog 2016-11-24 11:19:24.0 +
@@ -1,3 +1,10 @@
+glibc (2.24-6.1) UNRELEASED; urgency=medium
+
+ * Allow to inject the libc-dev dependency on linux-libc-dev by the build
+environment.
+
+ -- Matthias Klose <d...@debian.org> Thu, 24 Nov 2016 12:19:24 +0100
+
glibc (2.24-6) unstable; urgency=medium
[ Samuel Thibault ]
diff -Nru glibc-2.24/debian/rules.d/debhelper.mk glibc-2.24/debian/rules.d/debhelper.mk
--- glibc-2.24/debian/rules.d/debhelper.mk 2016-11-21 18:22:01.0 +
+++ glibc-2.24/debian/rules.d/debhelper.mk 2016-11-24 11:19:21.0 +
@@ -160,7 +160,14 @@
echo 'libgcc:Depends=libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4 [hppa]' >> tmp.substvars
endif
ifeq ($(DEB_HOST_ARCH_OS),linux)
- echo "libc-dev:Depends=$$(dpkg-query -f '$${binary:Package} (>= $${Version}) ' -W linux-libc-dev:$(DEB_HOST_ARCH) | sed -e 's/:\S\+//')" >> tmp.substvars
+ # cross-toolchain-base builds both linux-libc-dev and libc-dev package in one step,
+ # not using an installed linux-libc-dev package. Injecting the dependency by the env.
+ if [ -n "$$CTB_LIBC_DEV_DEPENDS" ]; then \
+ depends=$$CTB_LIBC_DEV_DEPENDS; \
+ else \
+ depends=$$(dpkg-query -f '$${binary:Package} (>= $${Version}) ' -W linux-libc-dev:$(DEB_HOST_ARCH) | sed -e 's/:\S\+//'); \
+ fi; \
+ echo "libc-dev:Depends=$$depends" >> tmp.substvars
endif
for pkg in $(DEB_ARCH_REGULAR_PACKAGES) $(DEB_INDEP_REGULAR_PACKAGES) $(DEB_UDEB_PACKAGES); do \
Bug#835946: glibc: non-standard gcc/g++ used for build (gcc-5)
Package: glibc Version: 2.23-5 Severity: important Tags: sid stretch User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-5, gcc-5-legacy This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++, or with gcc-6/g++-6. Please keep this report open until the package uses the default compiler version (or gcc-6) for the package build. If the package cannot be built anymore, please file a bug report for ftp.debian.org, asking for the removal of the package. The severity of this report is likely to be raised before the release, so that the gcc-5 package can be removed for the release.
Bug#834138: build stage1 glibc without a C++ compiler
Package: src:glibc Version: 2.24-0experimental0 Tags: patch build stage1 glibc without a C++ compiler. As long as this is not required, we shouldn't be forced to a C++ compiler for stage1. --- glibc-2.24/debian/rules.d/build.mk~ 2016-08-12 10:49:51.119631719 +0200 +++ glibc-2.24/debian/rules.d/build.mk 2016-08-12 12:54:25.763270288 +0200 @@ -31,10 +31,12 @@ @echo Configuring $(curpass) rm -f $(DEB_BUILDDIR)/configparms echo "CC = $(call xx,CC)" >> $(DEB_BUILDDIR)/configparms - echo "CXX = $(call xx,CXX)" >> $(DEB_BUILDDIR)/configparms echo "MIG = $(call xx,MIG)" >> $(DEB_BUILDDIR)/configparms echo "BUILD_CC = $(BUILD_CC)" >> $(DEB_BUILDDIR)/configparms +ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),) + echo "CXX = $(call xx,CXX)" >> $(DEB_BUILDDIR)/configparms echo "BUILD_CXX = $(BUILD_CXX)" >> $(DEB_BUILDDIR)/configparms +endif echo "CFLAGS = $(HOST_CFLAGS)">> $(DEB_BUILDDIR)/configparms echo "ASFLAGS = $(HOST_CFLAGS)" >> $(DEB_BUILDDIR)/configparms echo "BUILD_CFLAGS = $(BUILD_CFLAGS)" >> $(DEB_BUILDDIR)/configparms @@ -83,7 +85,7 @@ $(call logme, -a $(log_build), \ cd $(DEB_BUILDDIR) && \ CC="$(call xx,CC)" \ - CXX="$(call xx,CXX)" \ + $(if $(filter stage1,$(DEB_BUILD_PROFILES)),,CXX="$(call xx,CXX)") \ MIG="$(call xx,MIG)" \ AUTOCONF=false \ MAKEINFO=: \
Bug#806912: Don't build optimized variants in stage1 or stage2 builds
Package: src:glibc Version: 2.21-1 Tags: patch Don't build optimized variants in stage1 or stage2 builds; saves a pass on alpha and i386. diff -Nru glibc-2.21/debian/changelog glibc-2.21/debian/changelog --- glibc-2.21/debian/changelog 2015-11-30 23:17:58.0 + +++ glibc-2.21/debian/changelog 2015-12-02 20:06:12.0 + @@ -1,3 +1,9 @@ +glibc (2.21-1.1) UNRELEASED; urgency=medium + + * Don't build optimized variants in stage1 or stage2 builds. + + -- Matthias Klose <d...@debian.org> Wed, 02 Dec 2015 21:05:26 +0100 + glibc (2.21-1) unstable; urgency=medium [ Aurelien Jarno ] diff -Nru glibc-2.21/debian/sysdeps/alpha.mk glibc-2.21/debian/sysdeps/alpha.mk --- glibc-2.21/debian/sysdeps/alpha.mk 2015-03-16 16:03:45.0 + +++ glibc-2.21/debian/sysdeps/alpha.mk 2015-12-02 20:05:02.0 + @@ -3,6 +3,7 @@ libc = libc6.1 # build an ev67 optimized library +ifeq ($(filter stage1 stage2,$(DEB_BUILD_PROFILES)),) GLIBC_PASSES += alphaev67 DEB_ARCH_REGULAR_PACKAGES += libc6.1-alphaev67 alphaev67_add-ons = $(add-ons) @@ -10,3 +11,4 @@ alphaev67_extra_cflags = -mcpu=ev67 -mtune=ev67 -O2 alphaev67_extra_config_options = $(extra_config_options) alphaev67_slibdir = /lib/$(DEB_HOST_MULTIARCH)/ev67 +endif diff -Nru glibc-2.21/debian/sysdeps/i386.mk glibc-2.21/debian/sysdeps/i386.mk --- glibc-2.21/debian/sysdeps/i386.mk 2015-03-16 16:03:45.0 + +++ glibc-2.21/debian/sysdeps/i386.mk 2015-12-02 20:04:41.0 + @@ -3,6 +3,7 @@ # We use -march=i686 and glibc's i686 routines use cmov, so require it. # A Debian-local glibc patch adds cmov to the search path. # The optimized libraries also use NPTL! +ifeq ($(filter stage1 stage2,$(DEB_BUILD_PROFILES)),) GLIBC_PASSES += i686 DEB_ARCH_REGULAR_PACKAGES += libc6-i686 i686_add-ons = $(add-ons) @@ -10,6 +11,7 @@ i686_extra_cflags = -march=i686 -mtune=generic i686_slibdir = /lib/$(DEB_HOST_MULTIARCH)/i686/cmov i686_extra_config_options = $(extra_config_options) +endif # We use -mno-tls-direct-seg-refs to not wrap-around segments, as it # greatly increase the speed when running under the 32bit Xen hypervisor.
Bug#766877: pasted wrong bug number
Control: reopen -1 sorry, pasted the bug number from a wrong browser tab. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5541318b.5050...@debian.org
Bug#779294: /usr/bin/python: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python)
On 02/26/2015 06:01 PM, Andreas Beckmann wrote: during a test with piuparts I noticed a failure to upgrade from 'wheezy'. I'm not exactly sure which package to blame. This happened on i386, I cannot reproduce it on amd64. The package being tested was lsb-desktop, but it can probably show up elsewhere as well. From the attached log (scroll to the bottom...): (Reading database ... 18847 files and directories currently installed.) Preparing to replace libpython2.7 2.7.3-6+deb7u2 (using .../libpython2.7_2.7.8-11_i386.deb) ... Unpacking replacement libpython2.7:i386 ... Preparing to replace python2.7 2.7.3-6+deb7u2 (using .../python2.7_2.7.8-11_i386.deb) ... Unpacking replacement python2.7 ... Preparing to replace python2.7-minimal 2.7.3-6+deb7u2 (using .../python2.7-minimal_2.7.8-11_i386.deb) ... Unpacking replacement python2.7-minimal ... dpkg: warning: unable to delete old directory '/etc/python2.7': Directory not empty Selecting previously unselected package libpython2.7-minimal:i386. Unpacking libpython2.7-minimal:i386 (from .../libpython2.7-minimal_2.7.8-11_i386.deb) ... Preparing to replace debconf 1.5.49 (using .../debconf_1.5.55_all.deb) ... /usr/bin/python: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) dpkg: warning: subprocess old pre-removal script returned error exit status 1 dpkg: trying script from the new package instead ... /usr/bin/python: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) dpkg: error processing /var/cache/apt/archives/debconf_1.5.55_all.deb (--unpack): subprocess new pre-removal script returned error exit status 1 /usr/bin/python: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) dpkg: error while cleaning up: subprocess installed post-installation script returned error exit status 1 Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/debconf_1.5.55_all.deb This looks a bit like python was unpacked before the new glibc. debconf calls pycompile (and python). It looks like this kind of thing can happen with any binary which needs the new glibc, and in this case it hits python. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54ef58ce.6010...@debian.org
Bug#766877: Fix multilib enabled stage1 cross builds
Package: src:glibc
Version:
Tags: patch
The patch fixes building multilib enabled stage1 cross, by doing the call xx
dance for stage1 as well, as well as generating the debhelper files for multilib
stage1 packages.
--- glibc-2.19/debian/rules.d/debhelper.mk.orig 2014-10-22 21:10:46.131349002
+0200
+++ glibc-2.19/debian/rules.d/debhelper.mk 2014-10-22 21:20:07.863363493
+0200
@@ -201,19 +201,30 @@
templates=libc-dev ;\
pass= ; \
suffix= ;\
+ case $$curpass:$$slibdir in \
+ libc:*) \
+ ;; \
+ *:/lib32 | *:/lib64 | *:/libx32 | *:/lib/arm-linux-gnueabi*) \
+ pass=-alt \
+ suffix=-$(curpass) \
+ ;; \
+ esac ; \
for t in $$templates ; do \
for s in debian/$$t$$pass.* ; do \
t=`echo $$s | sed -e s#libc\(.*\)$$pass#$(libc)\1$$suffix#` ; \
+ echo Generating $$t ...; \
if [ $$s != $$t ] ; then \
cp $$s $$t ; \
fi ; \
- sed -e s#TMPDIR#debian/tmp-$$curpass#g -i $$t; \
- sed -e s#RTLDDIR#$$rtlddir#g -i $$t; \
- sed -e s#SLIBDIR#$$slibdir#g -i $$t; \
+ sed -i \
+ -e /LIBDIR.*.a /d \
+ -e s#TMPDIR#debian/tmp-$$curpass#g \
+ -e s#RTLDDIR#$$rtlddir#g \
+ -e s#SLIBDIR#$$slibdir#g \
+ -e s#LIBDIR#$$libdir#g \
+ $$t; \
done ; \
done
-
- sed -e /LIBDIR.*.a /d -e s#LIBDIR#lib#g -i
debian/$(libc)-dev.install
else
$(patsubst %,debhelper_%,$(GLIBC_PASSES)) :: debhelper_% : $(stamp)debhelper_%
$(stamp)debhelper_%: $(stamp)debhelper-common $(stamp)install_%
--- glibc-2.19/debian/rules.d/build.mk.orig 2014-10-23 15:14:45.302186092
+0200
+++ glibc-2.19/debian/rules.d/build.mk 2014-10-23 15:15:37.194572346 +0200
@@ -165,10 +165,10 @@
cross-compiling=yes install_root=$(CURDIR)/debian/tmp-$(curpass)
\
install-bootstrap-headers=yes install-headers )
- install -d $(CURDIR)/debian/tmp-$(curpass)/lib
- install -m 644 $(DEB_BUILDDIR)/csu/crt[1in].o
$(CURDIR)/debian/tmp-$(curpass)/lib
- ${CC} -nostdlib -nostartfiles -shared -x c /dev/null \
- -o $(CURDIR)/debian/tmp-$(curpass)/lib/libc.so
+ install -d $(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)
+ install -m 644 $(DEB_BUILDDIR)/csu/crt[1in].o
$(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)/.
+ $(call xx,CC) -nostdlib -nostartfiles -shared -x c /dev/null \
+ -o $(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)/libc.so
else
: # FIXME: why just needed for ARM multilib?
case $(curpass) in \
@@ -209,6 +209,7 @@
$(MAKE) -f debian/generate-supported.mk IN=localedata/SUPPORTED \
OUT=debian/tmp-$(curpass)/usr/share/i18n/SUPPORTED; \
fi
+endif
# Create the multiarch directories, and the configuration file in
/etc/ld.so.conf.d
if [ $(curpass) = libc ]; then \
@@ -230,6 +231,7 @@
mv debian/tmp-$(curpass)/usr/include/ieee754.h
debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
fi
+ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
# For our biarch libc, add an ld.so.conf.d configuration; this
# is needed because multiarch libc Replaces: libc6-i386 for ld.so, and
# the multiarch ld.so doesn't look at the (non-standard) /lib32, so we
Bug#747979: eglibc: non-standard gcc/g++ used for build (gcc-4.6)
Package: eglibc Version: 2.18-5 Severity: important Tags: sid jessie User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-4.6, gcc-4.6-legacy This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++, or with gcc-4.9/g++-4.9. Please drop build dependencies of the form libstdc++6-4.6-dev, these are not needed and fulfilled by build-essential. Please keep this report open until the package uses the default compiler version (or gcc-4.9) for the package build. The severity of this report is likely to be raised before the release, so that the gcc-4.6 package can be removed for the release. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wkbop-0002yn...@ravel.debian.org
Bug#747996: eglibc: non-standard gcc/g++ used for build (gcc-4.7)
Package: eglibc Version: 2.18-5 Severity: important Tags: sid jessie User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-4.7, gcc-4.7-legacy This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++, or with gcc-4.9/g++-4.9. Please drop build dependencies of the form libstdc++6-4.7-dev, these are not needed and fulfilled by build-essential. Please keep this report open until the package uses the default compiler version (or gcc-4.9) for the package build. The severity of this report is likely to be raised before the release, so that the gcc-4.7 package can be removed for the release. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wkbsc-0003k5...@ravel.debian.org
Re: Bug#717557: gcc-4.8: can't compile working 64bit kernel with 32bit userspace gcc-4.8
Am 20.10.2013 22:58, schrieb Ben Hutchings: On Sun, 2013-10-20 at 22:21 +0200, Matthias Klose wrote: Am 20.10.2013 00:25, schrieb Ben Hutchings: On Sat, 2013-10-19 at 23:38 +0200, Matthias Klose wrote: Control: severity -1 important Control: tags -1 + moreinfo In file included from command-line:0:0: /usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or directory #include bits/predefs.h ^ compilation terminated. It looks like I can avoid this by changing the compile tests to use the -nostdinc option. But this change may possibly cause other problems, and neither the pre-included header nor the fact that -nostdinc disables it seem to be documented. please attach the test program and the command line options used for this test case. I think the issue is within the kernel build system not being prepared for multiarch and -nostdinc. gcc-4.8 -m64 -x c -c /dev/null works for me on a current sid/i386. I assume that gcc-4.8-multilib is installed? No, it works if that's installed. But gcc-X.Y-multilib was previously only needed for building with a 64-bit C library, not for building a 64-bit kernel. If this kernel configuration was actually failing to build without gcc-4.8-multilib, I wouldn't mind so much. The problem is that it's built wrongly now. Maybe some later version of the kernel will be changed to detect or work around this problem, but we have to assume people will still try to build older versions not using -nostdinc for some time to come. Is this due to the missing /usr/include/asm symlink shipped in gcc-multilib? It's not ideal, and I think I did file a bug report that this should be shipped in one of the glibc packages, but can't find it anymore. The options to deal with this include: 1. Make missing headers non-fatal while pre-including stdc-predef.h. that would be the responsibility of those packages using non-standard options like -nostdinc. 2. Disable pre-inclusion of stdc-predef.h. no, done upstream to conform to standards. 3. Make 32-bit gcc fail to compile anything with -m64 if gcc-X.Y-multilib is not installed, even if -nostdinc is used. welcome to multiarch, and thanks for upstreaming patches to fix these issues. 4. Make gcc-X.Y depend on gcc-X.Y-multilib on architectures where it exists. well, then you can merge these again. the whole point to have them separate were bug reports about being forced to install the non-defaults multilibs by default. 5. Install the whole glibc headers into the multiarch header path. Would fix some other things too, like allowing multiarch configurations for non-glibc based triplets. And I assume it would allow your build to fail. Matthias -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52644ed0.60...@debian.org
Bug#708265: gnu-stubs multilib headers not shipped at least on mips
Package: src:eglibc Version: 2.17-2 Severity: serious seen when trying to build gcc-4.8: In file included from /usr/include/features.h:395:0, from /usr/include/stdio.h:27, from ../../../../src/libgcc/../gcc/tsystem.h:87, from ../../../../src/libgcc/libgcc2.c:27: /usr/include/gnu/stubs.h:17:33: fatal error: gnu/stubs-n32_hard.h: No such file or directory # include gnu/stubs-n32_hard.h ^ compilation terminated. make[7]: *** [_muldi3.o] Error 1 make[7]: Leaving directory `/home/doko/gcc/4.8/gcc-4.8-4.8.0/build/mips-linux-gnu/n32/libgcc' make[6]: *** [multi-do] Error 1 $ dpkg -S stubs libc6-dev:mips: /usr/include/mips-linux-gnu/gnu/stubs.h libc6-dev:mips: /usr/include/mips-linux-gnu/gnu/stubs-o32_hard.h -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51926160.6060...@debian.org
Bug#663150: Backport ARM makecontext() routines.
Package: eglibc Please backport ARM makecontext() routines from trunk, or https://code.launchpad.net/~michaelh1/ubuntu/precise/eglibc/lp696794/+merge/96465 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f5931a1.5030...@ubuntu.com
Bug#654744: eglibc: non-standard gcc/g++ used for build (gcc-4.4)
Package: eglibc Version: 2.13-24 Severity: important User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-4.4 This package builds with a non standard compiler version; please check if this package can be built with the default version of gcc/g++, or with gcc-4.6/g++-4.6. Please keep this report open until the package uses the default compiler version (or gcc-4.6) for the package build. The severity of this report is likely to be raised before the release, so that the gcc-4.4 package can be removed for the release. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rioc3-0001nu...@ravel.debian.org
Bug#637141: file conflicts in libc6-dev and libc6-dev-amd64
Package: libc6-dev Version: 2.13-15 Severity: serious $ dpkg -c libc6-dev_2.13-15_i386.deb | grep fpu_control -rw-r--r-- root/root 3163 2011-08-08 20:21 ./usr/include/fpu_control.h -rw-r--r-- root/root 3291 2011-08-08 20:10 ./usr/include/i386-linux-gnu/fpu_control.h -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e403795.8080...@debian.org
Bug#634850: [patch] provide the multiarch libdir for the non-default multilibs
Package: eglibc Version: 2.13-10 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu oneiric ubuntu-patch this is for a pending change for the multiarch updates in GCC. On multilib enabled archs the include and library directories are looked up using a prefix and a relative path. With the pending upload, lookups will fail for the non-default multilibs, e.g. on amd64 /usr/lib/i386-linux-gnu/../../lib32 doesn't work as long as the /usr/lib/i386-linux-gnu directory is non-existant (needed to access the crti.o et al. files). the eglibc biarch -dev packages should ship this empty directory. The attached patch needs updating for mips, mipsel and kfreebsd-amd64. * Add an empty directory /usr/lib/multiarch in the biarch -dev packages, needed by GCC to resolve names relative to this path. === modified file 'debian/sysdeps/amd64.mk' --- debian/sysdeps/amd64.mk 2011-06-02 18:13:24 + +++ debian/sysdeps/amd64.mk 2011-07-20 13:09:58 + @@ -47,6 +47,7 @@ cp -af debian/tmp-i386/usr/include/i486-linux-gnu/sys/vm86.h \ debian/libc6-dev-i386/usr/include/sys mkdir -p debian/libc6-dev-i386/usr/include/i486-linux-gnu +mkdir -p debian/libc6-dev-i386/usr/lib/i386-linux-gnu endef define libc6-i386_extra_pkg_install === modified file 'debian/sysdeps/i386.mk' --- debian/sysdeps/i386.mk 2011-03-09 01:00:53 + +++ debian/sysdeps/i386.mk 2011-07-20 13:10:55 + @@ -58,5 +58,6 @@ cp -af debian/tmp-amd64/usr/include/gnu/stubs-64.h \ debian/libc6-dev-amd64/usr/include/gnu mkdir -p debian/libc6-dev-amd64/usr/include/x86_64-linux-gnu +mkdir -p debian/libc6-dev-amd64/usr/lib/x86_64-linux-gnu endef === modified file 'debian/sysdeps/powerpc.mk' --- debian/sysdeps/powerpc.mk 2011-03-09 01:00:53 + +++ debian/sysdeps/powerpc.mk 2011-07-20 13:12:54 + @@ -19,5 +19,6 @@ cp -af debian/tmp-ppc64/usr/include/powerpc64-linux-gnu/gnu/stubs-64.h \ debian/libc6-dev-ppc64/usr/include/gnu mkdir -p debian/libc6-dev-ppc64/usr/include/powerpc64-linux-gnu +mkdir -p debian/libc6-dev-ppc64/usr/lib/powerpc64-linux-gnu endef === modified file 'debian/sysdeps/ppc64.mk' --- debian/sysdeps/ppc64.mk 2011-03-09 01:00:53 + +++ debian/sysdeps/ppc64.mk 2011-07-20 13:13:28 + @@ -27,6 +27,7 @@ cp -af debian/tmp-powerpc/usr/include/powerpc-linux-gnu/gnu/stubs-32.h \ debian/libc6-dev-powerpc/usr/include/gnu mkdir -p debian/libc6-dev-powerpc/usr/include/powerpc-linux-gnu +mkdir -p debian/libc6-dev-powerpc/usr/lib/powerpc-linux-gnu endef # create a symlink for the 32 bit dynamic linker in /lib === modified file 'debian/sysdeps/s390.mk' --- debian/sysdeps/s390.mk 2011-03-09 01:00:53 + +++ debian/sysdeps/s390.mk 2011-07-20 13:15:18 + @@ -17,6 +17,7 @@ cp -af debian/tmp-s390x/usr/include/s390x-linux-gnu/gnu/stubs-64.h \ debian/libc6-dev-s390x/usr/include/gnu mkdir -p debian/libc6-dev-s390x/usr/include/s390x-linux-gnu +mkdir -p debian/libc6-dev-s390x/usr/lib/s390x-linux-gnu endef define libc6-s390x_extra_pkg_install === modified file 'debian/sysdeps/sparc.mk' --- debian/sysdeps/sparc.mk 2011-06-23 18:13:13 + +++ debian/sysdeps/sparc.mk 2011-07-20 13:14:27 + @@ -19,6 +19,7 @@ cp -af debian/tmp-sparc64/usr/include/sparc64-linux-gnu/gnu/stubs-64.h \ debian/libc6-dev-sparc64/usr/include/gnu mkdir -p debian/libc6-dev-sparc64/usr/include/sparc64-linux-gnu +mkdir -p debian/libc6-dev-sparc64/usr/lib/sparc64-linux-gnu endef EGLIBC_PASSES += sparc64b
Bug#594807: openjdk-6 segfaults on armel with libc6 2.11.2-2
On 01.09.2010 11:35, Aurelien Jarno wrote: On Mon, Aug 30, 2010 at 06:05:15AM +0200, Aurelien Jarno wrote: On Sun, Aug 29, 2010 at 07:30:10PM +0200, Matthias Klose wrote: Package: libc6 Version: 2.11.2-2 Severity: grave This change breaks OpenJDK on armel: * Add patches/any/cvs-flush-cache-textrels.diff to fix random crashes on ARM, if the executable or shared library has TEXTREL. Reverting this change unbreaks openjdk. I am going to revert this change for squeeze, but given it is part of upstream, it will reappear with eglibc 2.13. I have tried to reproduce the issue on my arm machine, but it failed. It looks like a CPU or more probably a kernel issue given the only thing the code does is calling the cacheflush syscall. debian-arm, please could some of you check on different kernels if /usr/lib/jvm/java-6-openjdk/bin/java -version segfaults? thanks, Matthias -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c7e29d3.1020...@ubuntu.com
Bug#594807: openjdk-6 segfaults on armel with libc6 2.11.2-2
Package: libc6
Version: 2.11.2-2
Severity: grave
This change breaks OpenJDK on armel:
* Add patches/any/cvs-flush-cache-textrels.diff to fix random crashes
on ARM, if the executable or shared library has TEXTREL.
Reverting this change unbreaks openjdk.
$ java -version -zero
Segmentation fault
$ java -version -shark
java version 1.6.0_18
OpenJDK Runtime Environment (IcedTea6 1.8.1) (6b18-1.8.1-1)
OpenJDK Shark VM (build 14.0-b16, mixed mode)
Please reassign to openjdk-6 if appropriate.
Xerces Rangby did some debugging in LP: #605042:
Testcase:
// gcc testcase.c -ldl
#include stdio.h
#include stdlib.h
#include dlfcn.h
int main(void){
void *libjvm;
libjvm = dlopen(./libjvm.so, RTLD_NOW + RTLD_GLOBAL);
if (!libjvm) {
fprintf (stderr, %s\n, dlerror());
exit(1);
}
printf(%X,(int)libjvm);
}
the crash happens during ldopen of the libjvm.so file from java
loading other librarys seems to work fine.
The libjvm.so can be obtained from the armel openjdk-6-jre-headless package
6b18-1.8.1-1 located in usr/lib/jvm/java-6-openjdk/jre/lib/arm/server/libjvm.so
The java libjvm.so file contains an asm interpreter that defines a .init_array
section in the libjvm.so
defined in the file cppInterpreter_arm.S:
http://icedtea.classpath.org/hg/icedtea6/file/0b656f7601bd/ports/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S
this .init_array section makes dlopen execute initialization code for the asm
interpreter that seems to trigger the crash.
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c7a9922.7050...@ubuntu.com
Re: Bug#585051: (no subject)
On 12.06.2010 15:19, André Wöbbeking wrote: I can confirm this also for C++ programs. It's an interaction of eglibc 2.11 and gold. eglibc 2.10 and gold work together and eglibc 2.11 without gold also works. no, it's not 2.11, but 2.11 glibc built --with-multi-arch. Would the glibc maintainers consider to disable this configure option? 2.11 doesn't contain any optimized functions, only 2.12 starts providing these for some architectures. Matthias -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c138f89.4000...@debian.org
Re: Bug#585051: (no subject)
On 12.06.2010 19:00, André Wöbbeking wrote: On Saturday 12 June 2010, Aurelien Jarno wrote: Moreover we can also backport the optimized functions that have been added in 2.12, but the current goal is to move 2.11 to squeeze, so it will be for later. All that said, I don't plan to disable --with-multi-arch. Aurelien, you mentioned in 583858 that binutils.gold is fixed in experimental (or doesn't trigger this bug). Matthias, could you backport that to Sid? I assume that the experimental binutils.gold was tested with glibc 2.10. No, I don't think a backport would be helpful. Matthias -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c13d631.6020...@debian.org
Bug#584610: [mips] gcc-4.4 build failure after upgrade to eGLIBC-2.11
On 06.06.2010 00:51, Aurelien Jarno wrote: On Sat, Jun 05, 2010 at 03:50:51AM +0200, Matthias Klose wrote: Package: eGLIBC Version: 2.11.1-2 Severity: serious gcc-4.4 and gcc-4.5 fail to build after the upgrade to eGLIBC-2.11: https://buildd.debian.org/fetch.cgi?pkg=gcc-4.4;ver=4.4.4-4;arch=mips;stamp=1275677666 This FTBFS is caused by the following change: |2009-11-20 Jakub Jelinekja...@redhat.com | |PR libc/10103 | |* math/math.h: Provide *l long double prototypes redirecting |to double functions even when __NO_LONG_DOUBLE_MATH and not |__LDBL_COMPAT. |* math/complex.h: Likewise. These functions were present before in the library, but not exported in the headers. This has been changed as it is required by ISO C99. GCC tries to find these functions in the GLIBC by compiling a program, so it was failing before, and is successful now. When they are already present in the GLIBC it does not re-export them. Strangely this should also affect ARM, but it seems to build correctly. I haven't investigated why. While these functions are strictly not needed in libstdc++6 anymore, we have two options: - revert the GLIBC change, which means we break the C99 compatibility (as before) - patch GCC to export these functions anyway. What's your opinion? For ARM I did choose the second option, but didn't get any feedback about it. So maybe it's time to ask the mips and arm porters? The patch applied for armel is: http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/libstdc%2B%2B-arm-ldbl-compat.diff?view=log -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c0c9c79.7010...@debian.org
Bug#584610: [mips] gcc-4.4 build failure after upgrade to eglibc-2.11
Package: eglibc Version: 2.11.1-2 Severity: serious gcc-4.4 and gcc-4.5 fail to build after the upgrade to eglibc-2.11: https://buildd.debian.org/fetch.cgi?pkg=gcc-4.4;ver=4.4.4-4;arch=mips;stamp=1275677666 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c09ad7b.4060...@debian.org
Bug#583839: eglibc 2.11 ftbfs on kfreebsd
Package: eglibc Version: 2.11.1-1 Severity: serious see https://buildd.debian.org/fetch.cgi?pkg=gcc-snapshot;ver=20100530-1;arch=kfreebsd-amd64;stamp=1275239549 gnatgcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../src/gcc -I../../src/gcc/build -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -DCLOOG_PPL_BACKEND -I/usr/include/libelf \ -o build/gencondmd.o build/gencondmd.c In file included from ./tm.h:37, from build/gencondmd.c:21: ../../src/gcc/config/linux.h:86:1: warning: OPTION_GLIBC redefined In file included from build/gencondmd.c:21: ./tm.h:13:1: warning: this is the location of the previous definition ../../src/gcc/config/i386/i386.md:15604: error: 'linux_libc' undeclared here (not in a function) ../../src/gcc/config/i386/i386.md:15606: warning: missing initializer ../../src/gcc/config/i386/i386.md:15606: warning: (near initialization for 'insn_conditions[13].value') ../../src/gcc/config/i386/i386.md:15606: warning: missing initializer ../../src/gcc/config/i386/i386.md:15606: warning: (near initialization for 'insn_conditions[292].value') ../../src/gcc/config/i386/i386.md:15579: warning: missing initializer ../../src/gcc/config/i386/i386.md:15579: warning: (near initialization for 'insn_conditions[941].value') make[5]: *** [build/gencondmd.o] Error 1 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c02ff79.8060...@debian.org
Bug#564685: regressions in binutils testsuite on armel, when built against eglibc-2.10.x
Package: eglibc Version: 2.10.2-5 Severity: serious The following tests fail: Test results, compared with installed binutils: W: [ld-elfvsb/elfvsb.exp] REGRESSION (PASS - FAIL): visibility (normal) (non PIC, load offset) W: [ld-elfvsb/elfvsb.exp] REGRESSION (PASS - FAIL): visibility (normal) (non PIC) W: [ld-elfvsb/elfvsb.exp] REGRESSION (PASS - FAIL): visibility (hidden_normal) (non PIC) W: [ld-elfvsb/elfvsb.exp] REGRESSION (PASS - FAIL): visibility (hidden_normal) (non PIC, load offset) W: [ld-shared/shared.exp] REGRESSION (PASS - FAIL): shared (PIC main, non PIC so) W: [ld-shared/shared.exp] REGRESSION (PASS - FAIL): shared (non PIC) W: [ld-shared/shared.exp] REGRESSION (PASS - FAIL): shared (non PIC, load offset) 7 REGRESSIONS (0.68%). Seen with 2.11 as well. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#556951: [binutils] objcopy fails with 'Invalid operation'
On 18.11.2009 14:54, Peter Fritzsche wrote:
forwarded 556951 http://sourceware.org/bugzilla/show_bug.cgi?id=10982
thanks
Matthias Klose wrote:
[]
`debian/sauerbraten-dbg/usr/lib/debug//usr/lib/games/sauerbraten/sauer_cl
ient': Invalid operation dh_strip: objcopy returned exit code 1
Is this a known problem with binutils-gold?
yes, I did see this as well recently.
Could it be that it is new with 2.20-3 or 2.20-4? I think I didn't saw that in
earlier version. I think I saw it the first time when compiling batctl - which
I compiled right after update of my Sources file. This was after the 11.
November.
I wanted to write a bug report right now but haven't a glue why it fails.
objcopy --only-keep-debug debian/batctl/usr/sbin/batctl
debian/batctl-dbg/usr/lib/debug//usr/sbin/batctl
seems to work without any problems. The real problem is
objcopy --add-gnu-debuglink debian/batctl-dbg/usr/lib/debug//usr/sbin/batctl
debian/batctl/usr/sbin/batctl
So a small test would be:
$ echo 'int main() { return 0; }' test.c \
gcc -g3 test.c -o test \
objcopy --only-keep-debug test test.dbg \
objcopy --add-gnu-debuglink=./test.dbg test echo cool it works
objcopy:stCdJOm4: cannot create debug link section `./test.dbg': Invalid
operation
This works with the old linker, but not with binutils-gold
So I build the cvs version of the linker and objcopy and it is the same here.
So it is propably an upstream bug.
I only see this when upgrading to current glibc in unstable; not with testing.
Matthias
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#556951: [binutils] objcopy fails with 'Invalid operation'
On 18.11.2009 21:43, Aurelien Jarno wrote: On Wed, Nov 18, 2009 at 07:58:47PM -0600, Matthias Klose wrote: I only see this when upgrading to current glibc in unstable; not with testing. Could you be more precise with the versions? glibc in testing and unstable have the same version. sorry, no. it probably was -5, but I'm not sure. Matthias -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556534: gcc-4.4 testsuite errors when build with current eglibc
Package: eglibc Vesion: 2.10.1-7 Severity: grave seen on i386, most of the g++/libstdc++ tests are failing. seen with current gcc-4.4 package and with the packaging in the gcc svn. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa
On 08.11.2009 20:47, Carlos O'Donell wrote: On Sun, Nov 8, 2009 at 1:42 PM, Carlos O'Donellcar...@systemhalted.org wrote: Always the same crash for all the failures I've looked at. Hopefully this is something trivial that was missed. The current libc is missing my patches to fix pthread_attr_setstack() and pthread_attr_getstack() for hppa. HPPA is an architecture under which the stack grows up and the default implementation does not take that into account. The boehm-gc then uses the wrong stack values during garbase collection initialization and thus every gcj built application crashes. I will work with Aurelian on putting out a fixed libc, until then gcj will not work correctly. Sorry about the inconvenience. It appears that the glibc testsuite is self-consistent, and because both set and get functions are affected the glibc tests actually pass. I didn't notice this because I don't normally bootstrap java. Cheers, Carlos. looking at the gcc-4.4 g++/libstdc++ test results I see regressions as well; is this reproducible for you? Matthias -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539950: when /etc/hosts doesn't exist, apt fails to resolve hostnames using libc6 2.10.1
Package: libc6 Version: 2.10.1-0exp1 Severity: important E.g. apt-get's call to getaddrinfo() returns with EAI_SYSTEM when /etc/hosts is missing and EAI_NONAME if /etc/hosts is empty. This is different from 2.9, where EAI_NONAME is returned in both cases, resulting in the regression in apt-get. `sudo whoami' prints an additional error message but works as expected otherwise. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#533767: Missing Pre-Depends: libc6-i386 (= 2.9-17)
Goswin von Brederlow schrieb: Hi, small update to the bug report. The libc6-i386 package screwed up the transition by forgetting to delete the /lib32 and /usr/lib32 in preinst. So on upgrades all files remain under /emul/ia32-linux/ and the only thing that changes is the way dpkg sees them. Nice transition :-/ So you don't need a Pre-Depends after all. But lib32gcc1 still breaks upgrades of libc6-i386 ( 2.9-14). You should conflict, break or depend there. There is nothing special about lib32gcc1, so this has to be changed in all lib32* packages. Any reason this is only filed for lib32gcc1? -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533474: unsufficent versions for lib32 libs
Package: libc6-i386 Severity: serious the current conflict (= 4.4.0-5) is not enough. it has to be 4.4.0-7. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533482: wrong version in libc6-i386-dev conflict
Package: libc6-i386 Version: 2.9-16 Severity: serious conficts with libc6-dev-i386 (= 2.9.14), which should be 2.9-14. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524046: tzdata doesn't include timezones from the pacificnew file
Package: tzdata Version: 2009e-1 tzdata doesn't include timezones from the pacificnew file, please include these. some testcase complain about the missing zones. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504031: don't assume expected and current testsuite results in same order
Package: glibc Tags: patch updated compare.sh sorting both files before comparing. Matthias #!/bin/bash if [ $# -ne '2' ]; then echo -e \nUsage: Compare a test-expected-* file and a test-results-* file. echo -e $0 : Expected testsuite results Testsuite results \n; exit 1 fi; expected=$(tempfile) results=$(tempfile) sort $1 $expected sort $2 $results REGRESSIONS=$(diff -wBI '^#.*' $expected $results | sed -e '/^/!d;s/^ //g') rm -f $expected $results if [ -n $REGRESSIONS ] ; then echo Encountered regressions that don't match expected failures: echo $REGRESSIONS exit 1 else echo Passed regression testing. No new failures, no changed error values. exit 0 fi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490622: please generate zoneinfo files in file format known by openjdk/sun-java
Package: tzdata Version: 2008c-1 Please generate zoneinfo files in the file format known by openjdk/sun-java; this should be built from the tzdata source to avoid duplication of the data and put into a separate binary package. please use either use the sources included in the ubuntu patch (currently http://patches.ubuntu.com/t/tzdata/tzdata_2008c-1ubuntu1.patch) or use the openjdk-6-jdk package to build those. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages
Package: glibc Version: 2.7-11 Severity: important Please build libc6-hppa64 and libc6-hppa64-dev packages; there is no package build-depending on libc6-hppa64-dev, but we need these packages to run the testsuites for binutils and gcc-4.X. Currently these packages are completely untested, although used to build the 64bit flavour of the kernel on hppa. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages
clone 482902 -1 reassign -1 general severity -1 serious thanks Aurelien Jarno writes: severity 482902 wishlist tag 482902 + upstream tag 482902 + wontfix thanks Matthias Klose a écrit : Package: glibc Version: 2.7-11 Severity: important Please build libc6-hppa64 and libc6-hppa64-dev packages; there is no package build-depending on libc6-hppa64-dev, but we need these packages to run the testsuites for binutils and gcc-4.X. Currently these packages are completely untested, although used to build the 64bit flavour of the kernel on hppa. There is no upstream support for 64-bit glibc on hppa, so this bug is currently a wontfix. Please provide us a patch. that's fine. in this case we should drop support for hppa for lenny. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480295: [alpha] missing asm/page.h
Package: glibc Version: 2.7-10 http://experimental.ftbfs.de/fetch.php?pkg=binutilsver=2.18.50.20080507-1arch=alphastamp=1210319481file=logas=raw In file included from ../../bfd/trad-core.c:45: /usr/include/sys/user.h:27:22: error: asm/page.h: No such file or directory make[5]: *** [trad-core.lo] Error 1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc 2.7
Glibc upstream announced recently that the glibc 2.7 will be tagged and released very soon (probably on Oct 17[0]). which toolchain versions are required as build dependencies? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434626: [powerpc] broken 64bit packages
Package: libc6-ppc64 Version: 2.6-3 Severity: serious Seen while rebuilding gcc-4.2 / gcj-4.2; 64bit configure tests fail with a segfault. Reverting to 2.6-2 lets the bootstrap succeed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434626: [powerpc] broken 64bit packages
Aurelien Jarno writes: clone 434626 -1 reassign -1 gcc-4.2 retitle -1 [powerpc] generate broken 64-bit binaries thanks On Wed, Jul 25, 2007 at 01:18:43PM +0200, Matthias Klose wrote: Package: libc6-ppc64 Version: 2.6-3 Severity: serious Seen while rebuilding gcc-4.2 / gcj-4.2; 64bit configure tests fail with a segfault. Reverting to 2.6-2 lets the bootstrap succeed. The only significant difference between 2.6-2 and 2.6-3 is that we use gcc-4.2 to build the glibc. So it looks like gcc-4.2 is broken. gcc-4.2 -m64 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427398: Bug#427907: [hppa] git-core selftest failure with -O2 and -O1, -O0 works
probably related to #427398. Gerrit Pape writes: Package: gcc-4.1 Version: 4.1.2-11 See http://buildd.debian.org/fetch.cgi?pkg=git-corever=1%3A1.5.2.1-1arch=hppastamp=1180881720file=log I can reproduce this in paer's sid chroot as follows: $ apt-get source git-core Reading package lists... Done Building dependency tree... Done Need to get 1513kB of source archives. Get:1 http://mirrors.kernel.org sid/main git-core 1:1.5.2.1-1 (dsc) [798B] Get:2 http://mirrors.kernel.org sid/main git-core 1:1.5.2.1-1 (tar) [1404kB] Get:3 http://mirrors.kernel.org sid/main git-core 1:1.5.2.1-1 (diff) [109kB] Fetched 1513kB in 0s (1660kB/s) gpg: Signature made Sun Jun 3 05:44:52 2007 MDT using DSA key ID BC70A6FF gpg: Can't check signature: public key not found dpkg-source: extracting git-core in git-core-1.5.2.1 dpkg-source: unpacking git-core_1.5.2.1.orig.tar.gz dpkg-source: applying ./git-core_1.5.2.1-1.diff.gz $ cd git-core-1.5.2.1/ $ make CFLAGS=-O2 /dev/null (cd t sh t6026-merge-attr.sh) GIT_VERSION = 1.5.2.1 * new build flags or prefix [...] * failed 1 among 6 test(s) $ make CFLAGS=-O0 /dev/null (cd t sh t6026-merge-attr.sh) * new build flags or prefix /usr/bin/ld: warning: libcrypto.so.0.9.7, needed by /usr/lib/gcc/hppa-linux-gnu/4.1.3/../../../libcurl.so, may conflict with libcrypto.so.0.9.8 /usr/bin/ld: warning: libcrypto.so.0.9.7, needed by /usr/lib/gcc/hppa-linux-gnu/4.1.3/../../../libcurl.so, may conflict with libcrypto.so.0.9.8 Writing perl.mak for Git * ok 1: setup * ok 2: merge * ok 3: check merge result in index * ok 4: check merge result in working tree * ok 5: custom merge backend * ok 6: custom merge backend * passed all 6 test(s) $ I suspect the compiler's doing bad optimization, all other archs built successfully. Thanks, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405738: glibc should build-depend on binutils (= 2.17.50)
reopen 405738 found 405738 2.5-1 apparently the build dependency has been dropped again; was there a reason to rush the glibc upload and not to wait for the binutils update? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413370: libssp32, libssp64 removed in experimental
Package: glibc Version: 2.5 Severity: important libssp32, libssp64 are not built anymore by gcc in experimental, glibc b-d on these. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413370: libssp32, libssp64 removed in experimental
Aurelien Jarno writes: Matthias Klose a écrit : Package: glibc Version: 2.5 Severity: important libssp32, libssp64 are not built anymore by gcc in experimental, glibc b-d on these. This means we will have to build-depends on gcc-4.1 from experimental. or maybe provide libssp32, libssp64 in the libc6-xxx packages? This won't be possible until it is built and uploaded for all architectures that have bi-arch support. please go ahead and upload the remaing two (sparc and s390) Matthias
Bug#405738: glibc should build-depend on binutils (= 2.17.50)
Package: glibc Version: 2.5 Tags: experimental Severity: important glibc uses --hash-style for linking, when detected. Please build-depend on the appropriate binutils version, so that glibc is always built using --hash-style=both. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391858: FTBFS: gcc-4.x with glibc from experimental
Package: glibc Version: 2.5-0exp1 Tags: experimental Severity: serious see #374535, it's the GNU_TYPE, not the Debian architecture. $ find /usr/include/ -name stubs*/usr/include/gnu/stubs.h /usr/include/gnu/stubs-32.h /usr/include/ppc64-linux-gnu/gnu/stubs.h /usr/include/ppc64-linux-gnu/gnu/stubs-64.h the headers on powerpc/powerpc64 are identical, so you may install them directly in /usr/include/ as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
glibc build-depends on gcc-4.0 on hurd-i386?
Is this a leftover, which can be changed to gcc-4.1 now? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#364231: [parisc-linux] Re: Bug#364231: exception catching
[should we drop parisc-linux?] John David Anglin writes: Er, no; we're talking about official Debian packages here, and the libstdc++.so.6 in Debian is now from gcc-4.1. The problem is precisely that GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting in the double libgcc_s problem. Then, you must build *eveything* for hppa with gcc-4.1 or later. Unfortunately, there's an ABI break. Mixing libraries compiled with 4.0 or earlier with libraries compiled with 4.1 or later is just going to cause unnecessary problems. 3.3 uses libstdc++.so.5, so you avoid the double libgcc_s problem building GMP. However, you still have the ABI change affecting the passing and return of complex types. At a fundamental level, libstdc++.so.6, libgfortran.so.1.0.0 and any other gcc libraries built with 4.1 or later need glibc built with 4.1 to function correctly because of the various complex functions in the math library. I think there's a dynamic loader bug here as well. I'm just guessing but I think the double libgcc_s problem causes a problem with the handling of .eh_frame data. Ok, coming back to the question of the system compiler on hppa for etch. Assuming that hppa does want to do that: - is glibc buildable with gcc-4.1 on hppa? - libstdc++6 would need to conflict with libgcc2, which seems to be doable, but then rules out g++-3.4 and g++-4.0 as a fallback solution, where g++-4.1 fails. - libgfortran did have a soname change, so nothing needs to be done. - is libffi hit by the ABI change as well? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361642: i386 gconv modules not found on amd64
Package: libc6-i386 Severity: important Version: 2.3.6 Tags: patch third party applications like 32bit acroread won't start. http://people.ubuntu.com/patches/glibc-amd64.diff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355800: [powerpc] GCC 3.4.6 test suite failures with current glibc-3.2.6
Package: glibc Version: 2.3.6 Severity: important Running the gcc testsuite from gcc-3.4.6-1 (or gcc-3.4.5-3) on both current Debian unstable and Ubuntu dapper shows some test failures, which are only seen on unstable's glibc. --- ../../gcc-3.4-3.4.6/test-summary2006-03-07 05:30:43.0 + +++ test-summary2006-03-07 21:05:22.0 + @@ -1,4 +1,4 @@ -Results for 3.4.6 (Debian 3.4.6-1) testsuite on powerpc-linux-gnu +Results for 3.4.6 (Ubuntu 3.4.6-1ubuntu1) testsuite on powerpc-linux-gnu LAST_UPDATED: Obtained from SVN: tags/gcc_3_4_6_release revision 111785 Native configuration is powerpc-linux-gnu (doko) @@ -13,10 +13,10 @@ === gpc Summary === # of tests5057 -# of expected passes 5052 +# of expected passes 5050 # of unexpected failures 2 -# of unsupported tests3 -/home/doko/gcc/3.4/gcc-3.4-3.4.6/build/gcc/xgpc version 20060215, based on gcc-3.4.6 (Debian 3.4.6-1) +# of unsupported tests5 +/home/doko/gcc/3.4/u/gcc-3.4-3.4.6/build/gcc/xgpc version 20060215, based on gcc-3.4.6 (Ubuntu 3.4.6-1ubuntu1) === g++ tests === @@ -54,7 +54,7 @@ # of unexpected successes 4 # of expected failures 132 # of unsupported tests 142 -/home/doko/gcc/3.4/gcc-3.4-3.4.6/build/gcc/testsuite/../g++ version 3.4.6 (Debian 3.4.6-1) +/home/doko/gcc/3.4/u/gcc-3.4-3.4.6/build/gcc/testsuite/../g++ version 3.4.6 (Ubuntu 3.4.6-1ubuntu1) === g77 tests === @@ -77,24 +77,20 @@ # of expected passes 3624 # of unsupported tests 12 -/home/doko/gcc/3.4/gcc-3.4-3.4.6/build/gcc/testsuite/../g77 version 3.4.6 (Debian 3.4.6-1) +/home/doko/gcc/3.4/u/gcc-3.4-3.4.6/build/gcc/testsuite/../g77 version 3.4.6 (Ubuntu 3.4.6-1ubuntu1) === gcc tests === Running target unix FAIL: gcc.dg/20020103-1.c scan-assembler-not LC[0-9] -FAIL: gcc.dg/cleanup-10.c execution test -FAIL: gcc.dg/cleanup-11.c execution test -FAIL: gcc.dg/cleanup-8.c execution test -FAIL: gcc.dg/cleanup-9.c execution test FAIL: gcc.dg/ppc-sdata-1.c scan-assembler [EMAIL PROTECTED](13) FAIL: gcc.dg/ppc-sdata-1.c scan-assembler [EMAIL PROTECTED](2) === gcc Summary for unix === -# of expected passes 25043 -# of unexpected failures 7 +# of expected passes 25047 +# of unexpected failures 3 # of expected failures 69 # of untested testcases7 # of unsupported tests 331 @@ -118,8 +114,6 @@ FAIL: gcc.dg/980827-1.c (test for excess errors) WARNING: gcc.dg/980827-1.c compilation failed to produce executable FAIL: gcc.dg/altivec-14.c (test for excess errors) -FAIL: gcc.dg/cleanup-8.c execution test -FAIL: gcc.dg/cleanup-9.c execution test FAIL: gcc.dg/const-elim-1.c scan-assembler-not L\$?C[^A-Z] FAIL: gcc.dg/doloop-1.c scan-assembler bdnz FAIL: gcc.dg/doloop-1.c scan-assembler-not blt @@ -130,13 +124,12 @@ FAIL: gcc.dg/ppc-sdata-2.c (test for excess errors) ERROR: gcc.dg/ppc-sdata-2.c: error executing dg-final: couldn't open ppc-sdata-2.s: no such file or directory UNRESOLVED: gcc.dg/ppc-sdata-2.c: error executing dg-final: couldn't open ppc-sdata-2.s: no such file or directory -WARNING: gcc.dg/special/gcsec-1.c compilation failed to produce executable FAIL: linkage.c === gcc Summary for unix/-m64 === -# of expected passes 25020 -# of unexpected failures 22 +# of expected passes 25023 +# of unexpected failures 20 # of expected failures 69 # of unresolved testcases 6 # of untested testcases7 @@ -144,13 +137,13 @@ === gcc Summary === -# of expected passes 50063 -# of unexpected failures 29 +# of expected passes 50070 +# of unexpected failures 23 # of expected failures 138 # of unresolved testcases 6 # of untested testcases14 # of unsupported tests 660 -/home/doko/gcc/3.4/gcc-3.4-3.4.6/build/gcc/xgcc version 3.4.6 (Debian 3.4.6-1) +/home/doko/gcc/3.4/u/gcc-3.4-3.4.6/build/gcc/xgcc version 3.4.6 (Ubuntu 3.4.6-1ubuntu1) === libstdc++ tests === @@ -166,46 +159,28 @@ # of expected failures 5 Running target unix/-m64 -FAIL: 22_locale/codecvt/in/wchar_t/2.cc execution test -FAIL: 22_locale/codecvt/in/wchar_t/3.cc execution test -FAIL: 22_locale/codecvt/length/wchar_t/2.cc execution test -FAIL: 22_locale/codecvt/length/wchar_t/3.cc execution test -FAIL: 22_locale/codecvt/out/wchar_t/2.cc execution test -FAIL: 22_locale/codecvt/out/wchar_t/3.cc execution test FAIL: 22_locale/codecvt/unicode/1.cc execution test FAIL: 22_locale/codecvt/unicode/char.cc execution test -FAIL: 22_locale/ctype/widen/wchar_t/2.cc execution test XPASS: 22_locale/locale/cons/12658_thread.cc execution test -FAIL: 22_locale/messages/members/char/1.cc execution test -FAIL: 22_locale/messages/members/char/2.cc execution
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)
Bdale Garbee writes: On Fri, 2006-02-24 at 01:12 +0100, Aurelien Jarno wrote: The only change planned is to make libc6-dev-i386 and libc6-i386 provide a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I still have to find how to do that cleanly in the debhelper files). Bdale, do you agree with such a change? Yes, I think we can handle that. It means some small work on ia32-libs to stop delivering any conflicting files, but I'm sure we can work that out easily enough. If you want to provide me a patch for ia32-libs that does what you want it to do, that would be welcome. thanks. with this setup we are able to build our toolchain without build dependencies on ia32-libs or with packages conflicting with future multiarch packages (maybe additionally building lib32z1 from zlib). Will ia32-libs on ia64 still be supported for the etch release? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving 32-bit libraries to (/usr)/lib32 on amd64
Kurt Roeckx writes: In the end, I'd like to get rid of ia32-libs, and have it be a dummy package. But on the other hand, I don't want to make a biarch version of things like the X libraries. you can't get rid of it on ia64 unless you either drop the 32bit support or else you provide a cross-toolchain (ia64-x86). Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#341147: libg2c0-dev: Has file in /usr/lib32 instead of /emul/ia32-linux/usr/lib
Kurt Roeckx writes: Package: libg2c0-dev Version: 3.4.4-10 Severity: serious Hi, libg2c0-dev installs files in /usr/lib32, which conflict with the symlink from ia32-libs. It should be putting the files in /emul/ia32-linux/usr/lib instead. Note that this works as long as you install ia32-libs before libg2c0-dev, but breaks when you do it the other way around, or try to upgrade ia32-libs when libg2c0-dev is installed. please could somebody shed some light on planned biarch/multiarch support on amd64? will a biarch glibc for amd64 move to /usr/lib32, or stay in /emul/ia32-linux/usr/lib? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340835: sparc: /lib64/libc.so.6: unexpected reloc type 0x4f
Package: glibc
Version: 2.3.5-8
Severity: serious
makes gcc* FTBFS on sparc, 2.3.5-6 looks ok.
long longval () { return (long) (sizeof (int)); }
unsigned long ulongval () { return (long) (sizeof (int)); }
#include stdio.h
#include stdlib.h
int
main ()
{
FILE *f = fopen (conftest.val, w);
if (! f)
exit (1);
if (((long) (sizeof (int))) 0)
{
long i = longval ();
if (i != ((long) (sizeof (int
exit (1);
fprintf (f, %ld\n, i);
}
else
{
unsigned long i = ulongval ();
if (i != ((long) (sizeof (int
exit (1);
fprintf (f, %lu\n, i);
}
exit (ferror (f) || fclose (f) != 0);
;
return 0;
}
$ gcc -m64 foo.c
$ ./a.out
./a.out: error while loading shared libraries: /lib64/libc.so.6: unexpected
reloc type 0x4f
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#329108: gcc-4.0 FTBFS on, uh, i386
GOTO Masanori writes: At Mon, 19 Sep 2005 19:27:15 +0200, Matthias Klose wrote: On the latest i386 Sid, gcc-4.0 does not build from source, on my machine, and on a buildd (see the logs). With dash as sh, I get: this is known, we're waiting on proper 64bit support from glibc. I'd like to downgrade this one until we have the support. Goto, you did say, you wanted address this after the last update. any news? Does this mean glibc needs to support i386 support on amd64? If so, no progress yet because I thought Jeff worked for it. Should it to be available for gcc-4.0? No, this is about amd64 support for i386, replacing amd64-libs. I'm currently building i386 biarch packages using glibc-2.3.2, which is bad. The idea was to keep this, until lkh/glibc provide the updated kernel headers. AFAIK Jeff did contact you about that. the biarch support for amd64 is another thing, which would be nice to have, but is not as urgent, because the ia32-libs still work. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] glibc binary NMU for hppa, built with gcc-3.4
John David Anglin writes: Following the discussion on parisc, I uploaded glibc built with gcc-3.4. Validated, that gcc-4.0 bootstraps again and the python build errors are gone. Does this fix GCC PR 23731? can't check, it currently segfaults trying to generate the classmap.db (same thing already happens with 4.0 on m68k-linux). $ gdb .libs/gcj-dbtool GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as hppa-linux...Using host libthread_db library /lib/libthread_db.so.1. (gdb) set args -n foo.db (gdb) run Starting program: /scratch/packages/gcc/snap/gcc-snapshot-20050919/build/hppa-linux-gnu/libjava/.libs/gcj-dbtool -n foo.db [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4227)] [New Thread 32769 (LWP 4230)] [New Thread 16386 (LWP 4231)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 4227)] 0x41809c14 in _Unwind_Resume_or_Rethrow () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 (gdb) bt #0 0x41809c14 in _Unwind_Resume_or_Rethrow () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 #1 0x4180aed0 in _Unwind_Find_FDE () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 #2 0x41995ccc in dl_iterate_phdr () from /lib/libc.so.6 #3 0x4180aa6c in _Unwind_Find_FDE () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 #4 0x41806f38 in _Unwind_FindEnclosingFunction () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 #5 0x418085d4 in _Unwind_Backtrace () from /usr/lib/gcc-snapshot/lib/libgcc_s.so.2 #6 0x40ae1004 in _Jv_StackTrace::GetStackTrace () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #7 0x40b16028 in java::lang::VMThrowable::fillInStackTrace () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #8 0x40d58e84 in java::lang::Throwable::fillInStackTrace () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #9 0x40d58f78 in java::lang::Throwable::Throwable () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #10 0x40d58fb0 in java::lang::Throwable::Throwable () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #11 0x40d5908c in java::lang::Exception::Exception () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #12 0x40d590d4 in java::lang::ClassNotFoundException::ClassNotFoundException () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #13 0x40d59100 in java::lang::ClassNotFoundException::ClassNotFoundException () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #14 0x40d91414 in java::net::URLClassLoader::findClass () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #15 0x40b2a178 in gnu::gcj::runtime::BootClassLoader::bootLoadClass () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #16 0x40b15f30 in java::lang::VMClassLoader::loadClass () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #17 0x40b0d738 in _Jv_FindClass () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #18 0x40acd64c in _Jv_FindClassFromSignature () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #19 0x40ae20ec in _Jv_Linker::resolve_field () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #20 0x40ae4250 in _Jv_Linker::ensure_class_linked () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #21 0x40ae4400 in _Jv_Linker::wait_for_state () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #22 0x40b0c720 in java::lang::Class::initializeClass () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #23 0x40b27df0 in gnu::gcj::convert::BytesToUnicode::getDecoder () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #24 0x40b13c50 in java::lang::String::init () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #25 0x40d6d71c in java::lang::String::String () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #26 0x40acddac in JvConvertArgv () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #27 0x40acf008 in _Jv_RunMain () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #28 0x40acf24c in _Jv_RunMain () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #29 0x40acf278 in JvRunMain () from /usr/lib/gcc-snapshot/lib/libgcj.so.7 #30 0x418a2664 in __libc_start_main () from /lib/libc.so.6 #31 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #32 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #33 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #34 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #35 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #36 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #37 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #38 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #39 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 #40 0x0001259c in _start () at ../sysdeps/hppa/elf/start.S:84 [gdb hangs here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] glibc binary NMU for hppa, built with gcc-3.4
John David Anglin writes: Following the discussion on parisc, I uploaded glibc built with gcc-3.4. Validated, that gcc-4.0 bootstraps again and the python build errors are gone. Does this fix GCC PR 23731? down to 475 test failures. Maybe related to PR23602 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#329108: gcc-4.0 FTBFS on, uh, i386
On the latest i386 Sid, gcc-4.0 does not build from source, on my machine, and on a buildd (see the logs). With dash as sh, I get: this is known, we're waiting on proper 64bit support from glibc. I'd like to downgrade this one until we have the support. Goto, you did say, you wanted address this after the last update. any news? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
glibc binary NMU for hppa, built with gcc-3.4
Following the discussion on parisc, I uploaded glibc built with gcc-3.4. Validated, that gcc-4.0 bootstraps again and the python build errors are gone. Please make this change for the next sourceful upload. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326594: fpsetdefaults function missing in glibc-2.3.5
GOTO Masanori writes: At Sun, 4 Sep 2005 11:41:17 +0200, Matthias Klose wrote: glibc-2.3.5 doesn't have the fpsetdefaults function anymore, which was available in 2.3.2. Is the omission intended? If yes, is there a replacement function? Currently the python fpectl module fpectl FTBFS. I guess python misdetected OS: HP-UX, not Linux. the link test did succeed with 2.3.2. so the function was included. Or was this a bug in 2.3.2 as well? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326581: gcc-4.0_4.0.1-6 FTBFS on hppa
The current package in the archive FTBFS as well, with a strange error in libjava. The headers are not yet built at this point. Using glibc-2.3.2 or breezy's glibc doesn't show the problem. /scratch/packages/gcc/4.0/gcc-4.0-4.0.1/build/gcc/gcj -B/scratch/packages/gcc/4.0/gcc-4.0-4.0.1/build/gcc/ -B/usr/hppa-linux-gnu/bin/ -B/usr/hppa-linux-gnu/lib/ -isystem /usr/hppa-linux-gnu/include -isystem /usr/hppa-linux-gnu/sys-include --encoding=UTF-8 -Wno-deprecated -C -g -classpath '' -bootclasspath /scratch/packages/gcc/4.0/gcc-4.0-4.0.1/build/hppa-linux-gnu/libjava':'../../../src/libjava':'../../../src/libjava/external/w3c_dom':'../../../src/libjava/external/sax -d /scratch/packages/gcc/4.0/gcc-4.0-4.0.1/build/hppa-linux-gnu/libjava \ -MD -MF org/ietf/jgss.deps @org/ietf/jgss.list org/ietf/jgss.list:0: warning: no input file specified echo timestamp org/ietf/jgss.stamp echo timestamp classes.stamp make[4]: *** No rule to make target `java/lang/AbstractMethodError.class', needed by `java/lang/AbstractMethodError.h'. Stop. make[4]: Leaving directory `/scratch/packages/gcc/4.0/gcc-4.0-4.0.1/build/hppa-linux-gnu/libjava' make[3]: *** [all-target-libjava] Error 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326581: [hppa] glibc-2.3.5 let's python builds FTBFS
Package: glibc Version: 2.3.5-6 Severity: grave The python2.3 package (as well as the 2.2 and 2.4 package) FTBFS on hppa (see the buildd logs). The failures do not occur when downgrading glibc to 2.3.2 from sarge, or using breezy's glibc. Not further tracked down. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326594: fpsetdefaults function missing in glibc-2.3.5
Package: glibc Version: 2.3.5-6 glibc-2.3.5 doesn't have the fpsetdefaults function anymore, which was available in 2.3.2. Is the omission intended? If yes, is there a replacement function? Currently the python fpectl module fpectl FTBFS. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323552: 64bit -dev packages should depend on libXXgcc1
Package: glibc
gcc itself cannot depend on those, without sucking in 64bit glibc
packages.
diff -u glibc-2.3.5/debian/control.in/sparc64
glibc-2.3.5/debian/control.in/sparc64
--- glibc-2.3.5/debian/control.in/sparc64
+++ glibc-2.3.5/debian/control.in/sparc64
@@ -13,7 +13,7 @@
Architecture: sparc
Section: libdevel
Priority: standard
-Depends: libc6-sparc64 (= ${Source-Version}), libc6-dev (= ${Source-Version})
+Depends: libc6-sparc64 (= ${Source-Version}), libc6-dev (= ${Source-Version}),
lib64gcc1
Description: GNU C Library: 64bit Development Libraries for UltraSPARC
Contains the symlinks and object files needed to compile and link programs
which use the standard C library. This is the 64bit version of the
diff -u glibc-2.3.5/debian/control.in/s390x glibc-2.3.5/debian/control.in/s390x
--- glibc-2.3.5/debian/control.in/s390x
+++ glibc-2.3.5/debian/control.in/s390x
@@ -13,7 +13,7 @@
Architecture: s390
Section: libdevel
Priority: standard
-Depends: libc6-s390x (= ${Source-Version}), libc6-dev (= ${Source-Version})
+Depends: libc6-s390x (= ${Source-Version}), libc6-dev (= ${Source-Version}),
lib64gcc1
Description: GNU C Library: 64bit Development Libraries for IBM zSeries
Contains the symlinks and object files needed to compile and link programs
which use the standard C library. This is the 64bit version of the
diff -u glibc-2.3.5/debian/control.in/ppc64 glibc-2.3.5/debian/control.in/ppc64
--- glibc-2.3.5/debian/control.in/ppc64
+++ glibc-2.3.5/debian/control.in/ppc64
@@ -12,7 +12,7 @@
Architecture: powerpc
Section: libdevel
Priority: standard
-Depends: libc6-ppc64 (= ${Source-Version}), libc6-dev (= ${Source-Version})
+Depends: libc6-ppc64 (= ${Source-Version}), libc6-dev (= ${Source-Version}),
lib64gcc1
Description: GNU C Library: 64bit Development Libraries for PowerPC64
Contains the symlinks and object files needed to compile and link programs
which use the standard C library. This is the 64bit version of the
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321785: fakeroot: segfaults on [hppa]
--j79F1xXV029481.1123599719/bolero.cs.tu-berlin.de-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fakeroot: segfaults on [hppa]
fakeroot-tcp shows the same behaviour. reverting back to glibc-2.3.2 is a workaround. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318297: isdnutils FTBFS, error in kernel headers
Package: linux-kernel-headers
Severity: important
Tags: patch
In file included from capidyn.c:23:
/usr/include/linux/capi.h:80: error: variable or field '__user' declared void
/usr/include/linux/capi.h:80: error: syntax error before '*' token
/usr/include/linux/capi.h:115: error: syntax error before
'capi_manufacturer_cmd'
/usr/include/linux/capi.h:117: error: syntax error before '}' token
--- /usr/include/linux/capi.h~ 2004-10-31 20:55:51.0 +0100
+++ /usr/include/linux/capi.h 2005-06-17 21:48:29.0 +0200
@@ -75,7 +77,7 @@
typedef struct capi_manufacturer_cmd {
unsigned long cmd;
- void __user *data;
+ void *data;
} capi_manufacturer_cmd;
/*
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317082: libc6-s390x: missing depends on lib64gcc1
GOTO Masanori writes: At Tue, 05 Jul 2005 20:09:59 -0700, Ryan Murray wrote: libc6-s390x is missing a depends on lib64gcc1 that causes gcc to fail to link when -m64 is used on an s390 system. I'm filling the bug here rather than on the gcc-VERSION packages because the sparc64 packages have the dependency in libc6-sparc64, and not the gcc packages. According to #258647, the latest glibc.deb in svn already removed the Depends: lib64gcc1 entry. So I think it should be fixed in gcc packages instead of libc6-s390x. How about this idea? I don't know of a good way to handle the 64bit dependencies. We do not want to unconditionally depend on the non-default biarch packages. dh_shlibdeps doesn't work for 64bit packages, so you have to hand-code all the dependencies ... maybe dpkg-shlibdeps could use objdump -x instead of ldd to determine the needed library dependencies? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317501: amd64-libs-dev conflicts with linux-kernel-headers
Daniel Jacobowitz writes:
On Sat, Jul 09, 2005 at 09:29:33AM +0200, Matthias Klose wrote:
Package: amd64-libs-dev
Version: 1.1
Severity: grave
Conflicts against linux-kernel-headers_2.6.12.0-1, the biarch build
for gcc-3.4 and gcc-4.0 on i386 have to be disabled, therefore
severity grave.
This package was meant to be transitional, anyway. In your opinion,
should we fix it, or should we remove it and make the affected library
packages build biarch on i386? I believe that's just glibc, ncurses, and
libbz2 (plus linux-kernel-headers). Ncurses and glibc already support
biarch builds.
The next gcc-4.0 package will have included
/usr/include/{i486,x86_64}-linux-gnu in the standard include path,
depending on -m32/-m64, so we can start converting the packages you
mentioned to biarch. Removing the package should be fine.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313404: glibc update needed for dpkg-architecture changes
Package: glibc Version: 2.3.2.ds1-22 Severity: important For the toolchain update to use the new GNU_TYPE's, the hppa builds needs a /usr/hppa64-linux-gnu/include symlink. Please keep the old /usr/hppa64-linux/include symlink until all compilers are using the new path. The debian build files need an update for the dpkg-architecture changes as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293154: /usr/include/pthread.h: No valid ANSI C
GOTO Masanori writes: At Tue, 1 Feb 2005 15:16:17 +0100, Matthias Klose wrote: patch at http://people.ubuntu.com/patches/glibc-pthread-sigsetjmp.diff breaks gcc-4.0 bootstraps on architectures with nptl threads. would be nice to fix for sarge ... see http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02245.html for upstream information. I looked at your URI, but I didn't find any useful information. How to reproduce the problem? bootstrapping gcc CVS. http://gcc.gnu.org/PR19333 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293154: /usr/include/pthread.h: No valid ANSI C
Package: glibc Version: 2.3.2.ds1-20 Severity: important Tags: sid, sarge patch at http://people.ubuntu.com/patches/glibc-pthread-sigsetjmp.diff breaks gcc-4.0 bootstraps on architectures with nptl threads. would be nice to fix for sarge ... see http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02245.html for upstream information. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284793: libc6-prof: Running programs compiled with -profile fails
severity 284793 minor reassign 284793 gcc thanks the -profile option isn't recognized. please use -p or --profile. in earlier gcc versions, -profile did link in the gcrt0 start file, but gcc-3.3 and later link crt0. I didn't any documentation actually mentioning -profile. Matthias Daniel Jacobowitz writes: On Wed, Dec 08, 2004 at 09:17:39PM +0100, Arno Wagner wrote: E ~/exp/c/miscgcc -profile hello.c E ~/exp/c/misca.out Inconsistency detected by ld.so: dl-version.c: 230: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! E ~/exp/c/misc This has got to be either a GCC or binutils bug. The link line is: /usr/lib/gcc-lib/i486-linux/3.3.5/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc-lib/i486-linux/3.3.5/../../../gcrt1.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crti.o /usr/lib/gcc-lib/i486-linux/3.3.5/crtbegin.o -L/usr/lib/gcc-lib/i486-linux/3.3.5 -L/usr/lib/gcc-lib/i486-linux/3.3.5/../../.. /tmp/ccNEb3Zl.o -lgcc --as-needed -lgcc_s --no-as-needed -lc_p -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc-lib/i486-linux/3.3.5/crtend.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crtn.o But somehow a.out has a DT_NEEDED entry for libc.so.6. I see two problems: 1. It looks like --as-needed -lgcc_s --no-as-needed has somehow dragged in libc.so.6, even though libgcc_s.so is not needed (and not referenced by the output). 2. Should GCC add -static automatically to -profile, since libc_p.a is a static library? You can't link libc statically to a dynamic executable. -- Daniel Jacobowitz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284563: status of libunwind patches for ia64
David Mosberger writes: I wanted to try this but found that the gcc-3.3 has a libgcc1 package for hppa only. Is this intentional? I thought a new libgcc1 package for ia64 was needed so we pick up the libunwind built from the libunwind sources. please get the libgcc1 package from the unstable distribution. It's currently built by the gcc-3.4 sources and includes the libunwind.so.7 shared library. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284563: status of libunwind patches for ia64
with the patch attached and an updated gcc-3.3 package, libunwind support for ia64 seems to work for me. I couldn't install any of the built packages. I'd like to ask people to install the test builds found at http://people.debian.org/~doko/glibc/ http://people.debian.org/~doko/gcc-3.3/ and stress test these packages. After a review these packages could go together with libunwind to testing, so that the tightened dependency on libgcc1 doesn't hurd the transition of other packages anymore. Thanks, Matthias PS: glibc maintainers: please upload a new glibc package, _after_ gcc-3.3_3.3.5-4 was uploaded to unstable ;-) glibc (2.3.2.ds1-20) unstable; urgency=high * Tighten build dependency on ia64 to gcc-3.3_3.3.5-4. * Makeconfig: Uconditionally set the libunwind macro to -lunwind, until the it's safe again to regenerate the configure script, on advice of Jeff Bailey. Closes: #284563. -- Matthias Klose [EMAIL PROTECTED] Fri, 10 Dec 2004 11:05:00 -0800 diff -u glibc-2.3.2.ds1/debian/control.in/main glibc-2.3.2.ds1/debian/control.in/main --- glibc-2.3.2.ds1/debian/control.in/main +++ glibc-2.3.2.ds1/debian/control.in/main @@ -1,7 +1,7 @@ Source: @glibc@ Section: libs Priority: required -Build-Depends: gettext (= 0.10.37-1), make (= 3.80-1), dpkg-dev (= 1.4.1.5), debianutils (= 1.13.1), tar (= 1.13.11), bzip2, texinfo (= 4.0), linux-kernel-headers (= 2.5.999-test7-bk-9) [!hurd-i386], mig (= 1.3-2) [hurd-i386], hurd-dev (= 20020608-1) [hurd-i386], gnumach-dev [hurd-i386], texi2html, file, gcc-3.3 [!ia64] | gcc-3.4 [!ia64], gcc-3.3 (= 1:3.3.5-3) [ia64] | gcc-3.4 (= 3.4.3-2) [ia64], autoconf, binutils (= 2.14.90.0.7-5), sed (= 4.0.5-4), gawk, debhelper (= 4.1.76) +Build-Depends: gettext (= 0.10.37-1), make (= 3.80-1), dpkg-dev (= 1.4.1.5), debianutils (= 1.13.1), tar (= 1.13.11), bzip2, texinfo (= 4.0), linux-kernel-headers (= 2.5.999-test7-bk-9) [!hurd-i386], mig (= 1.3-2) [hurd-i386], hurd-dev (= 20020608-1) [hurd-i386], gnumach-dev [hurd-i386], texi2html, file, gcc-3.3 [!ia64] | gcc-3.4 [!ia64], gcc-3.3 (= 1:3.3.5-4) [ia64] | gcc-3.4 (= 3.4.3-2) [ia64], autoconf, binutils (= 2.14.90.0.7-5), sed (= 4.0.5-4), gawk, debhelper (= 4.1.76) Build-Depends-Indep: perl, po-debconf Maintainer: GNU Libc Maintainers [EMAIL PROTECTED] Uploaders: Ben Collins [EMAIL PROTECTED], GOTO Masanori [EMAIL PROTECTED], Philip Blundell [EMAIL PROTECTED], Jeff Bailey [EMAIL PROTECTED], Daniel Jacobowitz [EMAIL PROTECTED] diff -u glibc-2.3.2.ds1/debian/control glibc-2.3.2.ds1/debian/control --- glibc-2.3.2.ds1/debian/control +++ glibc-2.3.2.ds1/debian/control @@ -1,7 +1,7 @@ Source: glibc Section: libs Priority: required -Build-Depends: gettext (= 0.10.37-1), make (= 3.80-1), dpkg-dev (= 1.4.1.5), debianutils (= 1.13.1), tar (= 1.13.11), bzip2, texinfo (= 4.0), linux-kernel-headers (= 2.5.999-test7-bk-9) [!hurd-i386], mig (= 1.3-2) [hurd-i386], hurd-dev (= 20020608-1) [hurd-i386], gnumach-dev [hurd-i386], texi2html, file, gcc-3.3 [!ia64] | gcc-3.4 [!ia64], gcc-3.3 (= 1:3.3.5-3) [ia64] | gcc-3.4 (= 3.4.3-2) [ia64], autoconf, binutils (= 2.14.90.0.7-5), sed (= 4.0.5-4), gawk, debhelper (= 4.1.76) +Build-Depends: gettext (= 0.10.37-1), make (= 3.80-1), dpkg-dev (= 1.4.1.5), debianutils (= 1.13.1), tar (= 1.13.11), bzip2, texinfo (= 4.0), linux-kernel-headers (= 2.5.999-test7-bk-9) [!hurd-i386], mig (= 1.3-2) [hurd-i386], hurd-dev (= 20020608-1) [hurd-i386], gnumach-dev [hurd-i386], texi2html, file, gcc-3.3 [!ia64] | gcc-3.4 [!ia64], gcc-3.3 (= 1:3.3.5-4) [ia64] | gcc-3.4 (= 3.4.3-2) [ia64], autoconf, binutils (= 2.14.90.0.7-5), sed (= 4.0.5-4), gawk, debhelper (= 4.1.76) Build-Depends-Indep: perl, po-debconf Maintainer: GNU Libc Maintainers [EMAIL PROTECTED] Uploaders: Ben Collins [EMAIL PROTECTED], GOTO Masanori [EMAIL PROTECTED], Philip Blundell [EMAIL PROTECTED], Jeff Bailey [EMAIL PROTECTED], Daniel Jacobowitz [EMAIL PROTECTED] diff -u glibc-2.3.2.ds1/debian/patches/glibc232-ia64-unwindinfo.dpatch glibc-2.3.2.ds1/debian/patches/glibc232-ia64-unwindinfo.dpatch --- glibc-2.3.2.ds1/debian/patches/glibc232-ia64-unwindinfo.dpatch +++ glibc-2.3.2.ds1/debian/patches/glibc232-ia64-unwindinfo.dpatch @@ -265,0 +266,12 @@ +--- glibc-2.3.2.ds1/build-tree/glibc-2.3.2/Makeconfig.old 2004-12-10 07:21:52.438963000 -0800 glibc-2.3.2.ds1/build-tree/glibc-2.3.2/Makeconfig 2004-12-10 11:02:44.869465565 -0800 +@@ -516,6 +516,9 @@ + else + libunwind = -lunwind + endif ++ifeq ($(shell uname -m),ia64) ++ libunwind = -lunwind ++endif + ifneq ($(have-as-needed),yes) + libgcc_eh := -lgcc_eh $(libunwind) + else -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284563: libunwind in unstable
H. J. Lu writes: On Thu, Dec 09, 2004 at 12:49:38PM +0100, Matthias Klose wrote: H. J. Lu writes: On Tue, Dec 07, 2004 at 12:16:56AM -0800, David Mosberger wrote: On Tue, 7 Dec 2004 09:01:33 +0100, Matthias Klose [EMAIL PROTECTED] said: Matthias glibc now fails to build from source: Matthias undefined reference to `__gcc_personality_v0' Argh, looks like we may have to leave unwind-c.c in LIB2ADDEH. I cc'd HJ Lu since he may remember better what the final conclusion was in regards to the personality routine. IIRC, the resolution was that it needs to be provided by libgcc. We decided that the personality routine shouldn't be the part of libunwind.so. For gcc 3.4/4.0, unwind-sjlj.c and unwind-c.c are in libgcc_eh.a, unwind-sjlj.c, unwind-c.c, unwind-compat.c and unwind-dw2-fde-compat.c are in libgcc_s.so.1. ok, I'm currently bootstrapping gcc-3.3 with the patch attached, a glibc bootstrap using this compiler did succeed. I'll upload the fixed gcc-3.3, when bootstrap and testsuite finishes. Why not just backport the 3.4 libunwind patches to 3.3? attached. works for me. I'd like to get some feedback from ia64 users/developers, as I don't use ia64 that much. Matthias gcc33.tgz Description: Binary data
Bug#284563: libunwind in unstable
H. J. Lu writes: On Tue, Dec 07, 2004 at 12:16:56AM -0800, David Mosberger wrote: On Tue, 7 Dec 2004 09:01:33 +0100, Matthias Klose [EMAIL PROTECTED] said: Matthias glibc now fails to build from source: Matthias undefined reference to `__gcc_personality_v0' Argh, looks like we may have to leave unwind-c.c in LIB2ADDEH. I cc'd HJ Lu since he may remember better what the final conclusion was in regards to the personality routine. IIRC, the resolution was that it needs to be provided by libgcc. We decided that the personality routine shouldn't be the part of libunwind.so. For gcc 3.4/4.0, unwind-sjlj.c and unwind-c.c are in libgcc_eh.a, unwind-sjlj.c, unwind-c.c, unwind-compat.c and unwind-dw2-fde-compat.c are in libgcc_s.so.1. ok, I'm currently bootstrapping gcc-3.3 with the patch attached, a glibc bootstrap using this compiler did succeed. I'll upload the fixed gcc-3.3, when bootstrap and testsuite finishes. --- gcc-3.3-3.3.5/src/gcc/config/t-libunwind2003-12-03 18:18:22.0 -0800 +++ gcc-3.3-3.3.5-fixed/src/gcc/config/t-libunwind 2004-12-04 14:34:40.301003078 -0800 @@ -2,5 +2,4 @@ # so that the resulting libgcc_s.so has the necessary DT_NEEDED entry for # libunwind. SHLIB_LC = -lunwind -lc -LIB2ADDEH = $(srcdir)/unwind-libunwind.c $(srcdir)/unwind-sjlj.c \ - $(srcdir)/unwind-c.c +LIB2ADDEH = $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#283461: new patch glibc232-nptl-pthread to build g++/libsupc++ with nptl headers
Package: glibc
diff -u glibc-2.3.2.ds1/debian/changelog glibc-2.3.2.ds1/debian/changelog
--- glibc-2.3.2.ds1/debian/changelog
+++ glibc-2.3.2.ds1/debian/changelog
@@ -1,3 +1,10 @@
+glibc (2.3.2.ds1-18ubuntu3) hoary; urgency=low
+
+ * glibc232-nptl-pthread: New patch, taken from upstream CVS: Do not
+use C99 designators, as C++ does not have support for them.
+
+ -- Matthias Klose [EMAIL PROTECTED] Mon, 29 Nov 2004 00:11:44 +0100
diff -u glibc-2.3.2.ds1/debian/patches/00list
glibc-2.3.2.ds1/debian/patches/00list
--- glibc-2.3.2.ds1/debian/patches/00list
+++ glibc-2.3.2.ds1/debian/patches/00list
@@ -115 +115 @@
-
+glibc232-nptl-pthread
--- glibc-2.3.2.ds1.orig/debian/patches/glibc232-nptl-pthread.dpatch
+++ glibc-2.3.2.ds1/debian/patches/glibc232-nptl-pthread.dpatch
@@ -0,0 +1,90 @@
+#! /bin/sh -e
+
+# All lines beginning with `# DP:' are a description of the patch.
+# DP: Description: nptl/pthread.h: Don't use C99 designators.
+# DP: Dpatch author: Matthias Klose [EMAIL PROTECTED]
+# DP: Upstream status: Taken from upstream
+# DP: Date: 2004-11-28
+
+PATCHLEVEL=1
+
+if [ $# -ne 2 ]; then
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1
+fi
+case $1 in
+-patch) patch -d $2 -f --no-backup-if-mismatch -p$PATCHLEVEL $0;;
+-unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p$PATCHLEVEL $0;;
+*)
+ echo 2 `basename $0`: script expects -patch|-unpatch as argument
+ exit 1
+esac
+exit 0
+
+# append the patch here and adjust the -p? flag in the patch calls.
+
+(PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP): Make safe for C++.
+(PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP): Likewise.
+(PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP): Likewise.
+(PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP): Likewise.
+
+===
+RCS file: /cvs/glibc/libc/nptl/sysdeps/pthread/pthread.h,v
+retrieving revision 1.24
+retrieving revision 1.25
+diff -u -r1.24 -r1.25
+--- libc/nptl/sysdeps/pthread/pthread.h2004/09/07 20:49:32 1.24
libc/nptl/sysdeps/pthread/pthread.h2004/09/09 04:58:00 1.25
+@@ -27,6 +27,7 @@
+ #include signal.h
+ #include bits/pthreadtypes.h
+ #include bits/setjmp.h
++#include bits/wordsize.h
+
+
+ /* Detach state. */
+@@ -63,12 +64,21 @@
+ #define PTHREAD_MUTEX_INITIALIZER \
+ { }
+ #ifdef __USE_GNU
+-# define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
+- { .__data = { .__kind = PTHREAD_MUTEX_RECURSIVE_NP } }
+-# define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
+- { .__data = { .__kind = PTHREAD_MUTEX_ERRORCHECK_NP } }
+-# define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
+- { .__data = { .__kind = PTHREAD_MUTEX_ADAPTIVE_NP } }
++# if __WORDSIZE == 64
++# define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
++ { { 0, 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP } }
++# define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
++ { { 0, 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP } }
++# define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
++ { { 0, 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP } }
++# else
++# define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
++ { { 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP } }
++# define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
++ { { 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP } }
++# define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
++ { { 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP } }
++# endif
+ #endif
+
+
+@@ -87,8 +97,14 @@
+ #define PTHREAD_RWLOCK_INITIALIZER \
+ { }
+ #ifdef __USE_GNU
+-# define PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP \
+- { .__data = { .__flags = PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP } }
++# if __WORDSIZE == 64
++# define PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP \
++ { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
++ PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP } }
++# else
++# define PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP \
++ { { 0, 0, 0, 0, 0, 0, PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP } }
++# endif
+ #endif
+
+
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libunwind in unstable
Matthieu Delahaye writes:
On Wed, 2004-11-24 at 17:36, Ian Wienand wrote:
On Wed, Nov 24, 2004 at 12:46:12AM +0100, Matthias Klose wrote:
ok, Ian, if it's ok with you, I'll prepare a libunwind upload, which
plays well with a libgcc1 package including the libunwind7 shared
libs.
It's actually Matthieu's package so he needs to have the final say so;
it's a rock and a hard place type problem but FWIW I think having
the Mosberger libunwind.so as the default one is an enhancement (and
something Debian should have got around to sooner).
Matthias,
I'm not really sure which of the alternatives you proposed earlier is
now the official for libunwind.
File a bug on the BTS against libunwind7 with your patch and explain me
why. I will upload it either tonight or tomorrow. However, If you think
it is more urgent than that, please NMU (But please file the bug for
documentation).
please review the attached patch. you find the corresponding gcc
package at http://people.debian.org/~doko/gcc-ia64/
Matthias
diff -u libunwind-0.98.3/debian/changelog libunwind-0.98.3/debian/changelog
--- libunwind-0.98.3/debian/changelog
+++ libunwind-0.98.3/debian/changelog
@@ -1,3 +1,10 @@
+libunwind (0.98.3-2) unstable; urgency=low
+
+ * Depend on libgcc1, for the sarge release, libunwind.so.7 is built
+by the gcc-3.4 source package.
+
+ -- Matthias Klose [EMAIL PROTECTED] Fri, 26 Nov 2004 00:48:43 +0100
+
libunwind (0.98.3-1) unstable; urgency=low
* New upstream release
diff -u libunwind-0.98.3/debian/rules libunwind-0.98.3/debian/rules
--- libunwind-0.98.3/debian/rules
+++ libunwind-0.98.3/debian/rules
@@ -104,6 +104,7 @@
# d_python
dh_makeshlibs
dh_installdeb
+ ln -sf /lib/libunwind.so.7 debian/libunwind7-dev/usr/lib/libunwind.so
dh_shlibdeps
dh_gencontrol
dh_md5sums
diff -u libunwind-0.98.3/debian/control libunwind-0.98.3/debian/control
--- libunwind-0.98.3/debian/control
+++ libunwind-0.98.3/debian/control
@@ -24,7 +24,7 @@
Package: libunwind7
Section: libs
Architecture: ia64
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, libgcc1 (= 1:3.4.3-2)
Description: A library to determine the call-chain of a program - runtime
The primary goal of this project is to define a portable and efficient C
programming interface (API) to determine the call-chain of a program.
diff -u libunwind-0.98.3/debian/libunwind7.install
libunwind-0.98.3/debian/libunwind7.install
--- libunwind-0.98.3/debian/libunwind7.install
+++ libunwind-0.98.3/debian/libunwind7.install
@@ -1,3 +1,2 @@
-debian/tmp/usr/lib/libunwind.so.* usr/lib/
debian/tmp/usr/lib/libunwind-ia64.so.* usr/lib
debian/tmp/usr/lib/libunwind-generic.so.* usr/lib
only in patch2:
unchanged:
--- libunwind-0.98.3.orig/debian/libunwind7.install.saved
+++ libunwind-0.98.3/debian/libunwind7.install.saved
@@ -0,0 +1,3 @@
+debian/tmp/usr/lib/libunwind.so.* usr/lib/
+debian/tmp/usr/lib/libunwind-ia64.so.* usr/lib
+debian/tmp/usr/lib/libunwind-generic.so.* usr/lib
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
