enabling link time optimizations in package builds
Link time optimizations are an optimization that helps with a single digit percent number optimizing both for smaller size, and better speed. These optimizations are available for some time now in GCC. Link time optimizations are also at least turned on in other distros like Fedora, OpenSuse (two years) and Ubuntu (one year). Details at https://wiki.debian.org/ToolChain/LTO The proposal is to turn on LTO by default on most 64bit release architectures. Not proposing to do this on 32bit architectures because of the limited address space at link time, and up to now nobody tested LTO on 32bit archs. In test rebuilds, there were 373 packages (dd-list in the wiki page) found not to build with link time optimizations for various reasons. These range from easily fixable issues in symbols files to some upstream issues. The idea is to fix as many of these as possible, and then change the packaging for the others to just turn off LTO in the package build. To explicitly turn on LTO for a package build: export DEB_BUILD_MAINT_OPTIONS=optimize=+lto to explicitly disable LTO: export DEB_BUILD_MAINT_OPTIONS=optimize=-lto The idea is to file wishlist bug reports for those 373 packages and then see how far we get, and if it's feasible to already turn on LTO for bookworm. If not, it should be turned on by default for the following release. Matthias
Bug#994035: gcc-11 ftbfs on kfreebsd-*, strange tar behavior
Package: src:gcc-11 Version: 11.2.0-5 Severity: important X-Debbugs-CC: debian-bsd@lists.debian.org gcc-11 ftbfs on kfreebsd-*, strange tar behavior: [...] mkdir -p debian/tmp-jit/usr/lib/x86_64-kfreebsd-gnu mkdir -p debian/tmp-jit/usr/lib/gcc/x86_64-kfreebsd-gnu/11/include mv debian/tmp-jit/usr/include/libgccjit*.h \ debian/tmp-jit/usr/lib/gcc/x86_64-kfreebsd-gnu/11/include/. mv debian/tmp-jit/usr/lib/libgccjit.so* \ debian/tmp-jit/usr/lib/x86_64-kfreebsd-gnu/. cd debian/tmp-jit tar cvfJ ../../installed-jit.tar.xz \ usr/lib/gcc/x86_64-kfreebsd-gnu/11/include/libgccjit*.h \ usr/lib/x86_64-kfreebsd-gnu/libgccjit.so* \ usr/share/info/libgccjit* usr/lib/gcc/x86_64-kfreebsd-gnu/11/include/libgccjit++.h usr/lib/gcc/x86_64-kfreebsd-gnu/11/include/libgccjit.h usr/lib/x86_64-kfreebsd-gnu/libgccjit.so usr/lib/x86_64-kfreebsd-gnu/libgccjit.so.0 usr/lib/x86_64-kfreebsd-gnu/libgccjit.so.0.0.1 tar: usr/lib/x86_64-kfreebsd-gnu/libgccjit.so.0.0.1: file changed as we read it usr/share/info/libgccjit.info make[1]: *** [debian/rules2:1402: stamps/05-build-jit-stamp] Error 1 make[1]: Leaving directory '/PKGBUILDDIR' make: *** [debian/rules:53: build-arch] Error 2
Bug#978513: kfreebsd-10: non-standard gcc/g++ used for build (gcc-9)
Package: kfreebsd-10 Severity: important Tags: sid bullseye User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-9, gcc-9-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-10/g++-10. If the package cannot be built with GCC 10 because of a compiler bug, please file a report for gcc-10. Please keep this report open until the package uses the default compiler version (or gcc-10) 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.
Re: Porter roll call for Debian Bullseye
On 12/1/20 5:02 AM, YunQiang Su wrote: > I am sorry for the later response. >Hi, > > I am an active porter for the following architectures and I intend > to continue this for the lifetime of the Bullseye release (est. end > of 2024): > > For mipsel and mips64el, I > - test most packages on this architecture > - run a Debian testing or unstable system on port that I use regularly > - fix toolchain issues great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in testing ... > - triage arch-specific bugs > - fix arch-related bugs any help with #972269 ?
GCC and binutils plans for bullseye
Debian bullseye will be based on a gcc-10 package taken from the gcc-10 upstream branch, and binutils based on a binutils package taken from the 2.35 branch. I'm planning to make gcc-10 the default after gcc-10 (10.2.0) is available (upstream targets mid July). binutils will be updated before making the GCC switch. The GCC 10 switch involves some minor library transitions for D, gccgo, M2, which should be no-brainers. The gnat transition will be handled separately by the debian Ada maintainers. binutils should be pretty stable until the bullseye release, not planning an update to 2.36. GCC 10 should be updated to 10.3, or close to 10.3 (the release date is not yet known, could be Feb 2021). I'd like to get rid off GCC 8 and GCC 9 for the bullseye release. Matthias
Bug#957516: makefs: ftbfs with GCC-10
Package: src:makefs Version: 20190105-1 Severity: normal Tags: sid bullseye User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The severity of this report will be raised before the bullseye release, so nothing has to be done for the buster release. The full build log can be found at: http://people.debian.org/~doko/logs/gcc10-20200225/makefs_20190105-1_unstable_gcc10.log The last lines of the build log are at the end of this report. To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-10/porting_to.html [...] x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wformat -Wno-unused-but-set-variable -Wno-unused-result -flto=jobserver -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wreturn-type -Wcast-qual -Wpointer-arith -Wwrite-strings -Wswitch -Wshadow -Wdate-time -D_FORTIFY_SOURCE=2 -D'__IDSTRING(x,y)=static const char x[] __attribute__((__used__)) = y' -D'__RCSID(x)=__IDSTRING(rcsid,x)' -D'__SCCSID(x)=__IDSTRING(sccsid,x)' -D'__KERNEL_RCSID(x,y)=__IDSTRING(kernelrcsid_ ## x,y)' -D'__dead=__attribute__((__noreturn__))' -D'_DIAGASSERT(x)=' -D'bswap16=__bswap_16' -D'bswap32=__bswap_32' -D'bswap64=__bswap_64' -DHAVE_STRUCT_STATVFS_F_IOSIZE=0 -DHAVE_STRUCT_STAT_ST_MTIMENSEC=0 -DHAVE_STRUCT_STAT_ST_FLAGS=0 -DHAVE_STRUCT_STAT_ST_GEN=0 -DS_ISTXT=S_ISVTX -DLIBC_SCCS -DHAVE_STRUCT_STAT_BIRTHTIME=0 -DHAVE_NBTOOL_CONFIG_H=0 -DHAVE_NETDB_H=1 -DHAVE_PWCACHE_USERDB=0 -DHAVE_STRSUFTOLL=0 -I/<>/builddir/usr.sbin/makefs -I/<>/builddir/usr.sbin/makefs/nbsrc/sbin/mknod -I/<>/builddir/usr.sbin/makefs/nbsrc/usr.sbin/mtree -I/<>/builddir/usr.sbin/makefs/nbsrc/sys/fs/cd9660 -I/<>/builddir/usr.sbin/makefs/nbsrc/sys -I/<>/builddir/sbin/mknod -I/<>/builddir/usr.sbin/mtree -I/<>/builddir/sys -I/<>/builddir/sys/isofs/cd9660 -I/<>/builddir/usr.sbin/makefs/nbsrc/lib/libc/gen -I/<>/builddir/usr.sbin/makefs/nbsrc/lib/libc/stdlib -D_GNU_SOURCE -DGNUPORT -I/<>/builddir/include -DOUTSIDE_OF_LIBKERN -DNEED_STRLFUN_PROTOS -DL_strlcpy -DL_strlcat -c /<>/builddir/usr.sbin/makefs/ffs/buf.c x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wformat -Wno-unused-but-set-variable -Wno-unused-result -flto=jobserver -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wreturn-type -Wcast-qual -Wpointer-arith -Wwrite-strings -Wswitch -Wshadow -Wdate-time -D_FORTIFY_SOURCE=2 -D'__IDSTRING(x,y)=static const char x[] __attribute__((__used__)) = y' -D'__RCSID(x)=__IDSTRING(rcsid,x)' -D'__SCCSID(x)=__IDSTRING(sccsid,x)' -D'__KERNEL_RCSID(x,y)=__IDSTRING(kernelrcsid_ ## x,y)' -D'__dead=__attribute__((__noreturn__))' -D'_DIAGASSERT(x)=' -D'bswap16=__bswap_16' -D'bswap32=__bswap_32' -D'bswap64=__bswap_64' -DHAVE_STRUCT_STATVFS_F_IOSIZE=0 -DHAVE_STRUCT_STAT_ST_MTIMENSEC=0 -DHAVE_STRUCT_STAT_ST_FLAGS=0 -DHAVE_STRUCT_STAT_ST_GEN=0 -DS_ISTXT=S_ISVTX -DLIBC_SCCS -DHAVE_STRUCT_STAT_BIRTHTIME=0 -DHAVE_NBTOOL_CONFIG_H=0 -DHAVE_NETDB_H=1 -DHAVE_PWCACHE_USERDB=0 -DHAVE_STRSUFTOLL=0 -I/<>/builddir/usr.sbin/makefs -I/<>/builddir/usr.sbin/makefs/nbsrc/sbin/mknod -I/<>/builddir/usr.sbin/makefs/nbsrc/usr.sbin/mtree -I/<>/builddir/usr.sbin/makefs/nbsrc/sys/fs/cd9660 -I/<>/builddir/usr.sbin/makefs/nbsrc/sys -I/<>/builddir/sbin/mknod -I/<>/builddir/usr.sbin/mtree -I/<>/builddir/sys -I/<>/builddir/sys/isofs/cd9660 -I/<>/builddir/usr.sbin/makefs/nbsrc/lib/libc/gen -I/<>/builddir/usr.sbin/makefs/nbsrc/lib/libc/stdlib -D_GNU_SOURCE -DGNUPORT -I/<>/builddir/include -DOUTSIDE_OF_LIBKERN -DNEED_STRLFUN_PROTOS -DL_strlcpy -DL_strlcat -c /<>/builddir/usr.sbin/makefs/ffs/mkfs.c x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wformat -Wno-unused-but-set-variable -Wno-unused-result -flto=jobserver -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wreturn-type -Wcast-qual -Wpointer-arith -Wwrite-strings -Wswitch -Wshadow -Wdate-time -D_FORTIFY_SOURCE=2 -D'__IDSTRING(x,y)=static const char x[] __attribute__((__used__)) = y' -D'__RCSID(x)=__IDSTRING(rcsid,x)'
Bug#957380: istgt: ftbfs with GCC-10
Package: src:istgt Version: 0.4~20111008-3 Severity: normal Tags: sid bullseye User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The severity of this report will be raised before the bullseye release, so nothing has to be done for the buster release. The full build log can be found at: http://people.debian.org/~doko/logs/gcc10-20200225/istgt_0.4~20111008-3_unstable_gcc10.log The last lines of the build log are at the end of this report. To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-10/porting_to.html [...] 4632 |int mdlen, mt, dsp, bdlen; |^ istgt_lu_tape.c:4679:19: warning: variable ‘dsp’ set but not used [-Wunused-but-set-variable] 4679 |int mdlen, mt, dsp, bdlen; | ^~~ istgt_lu_tape.c:4679:15: warning: variable ‘mt’ set but not used [-Wunused-but-set-variable] 4679 |int mdlen, mt, dsp, bdlen; | ^~ istgt_lu_tape.c:4679:8: warning: variable ‘mdlen’ set but not used [-Wunused-but-set-variable] 4679 |int mdlen, mt, dsp, bdlen; |^ istgt_lu_tape.c:5138:16: warning: variable ‘partition’ set but not used [-Wunused-but-set-variable] 5138 |int bt, cp, partition; |^ istgt_lu_tape.c:5138:8: warning: variable ‘bt’ set but not used [-Wunused-but-set-variable] 5138 |int bt, cp, partition; |^~ istgt_lu_tape.c:5304:13: warning: variable ‘rest’ set but not used [-Wunused-but-set-variable] 5304 |uint64_t rest; | ^~~~ gcc -DHAVE_CONFIG_H -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -DDEBUG -fno-strict-aliasing -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Winline -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -Wdate-time -D_FORTIFY_SOURCE=2 -I.. -I. -c -o istgt_lu_pass.o istgt_lu_pass.c gcc -DHAVE_CONFIG_H -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -DDEBUG -fno-strict-aliasing -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Winline -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -Wdate-time -D_FORTIFY_SOURCE=2 -I.. -I. -c -o istgt_lu_ctl.o istgt_lu_ctl.c istgt_lu_ctl.c: In function ‘istgt_uctl_cmd_refresh’: istgt_lu_ctl.c:974:8: warning: variable ‘arg’ set but not used [-Wunused-but-set-variable] 974 | char *arg; |^~~ istgt_lu_ctl.c: In function ‘istgt_uctl_cmd_reset’: istgt_lu_ctl.c:1079:19: warning: variable ‘llp’ set but not used [-Wunused-but-set-variable] 1079 | ISTGT_LU_LUN_Ptr llp; | ^~~ gcc -DHAVE_CONFIG_H -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -DDEBUG -fno-strict-aliasing -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Winline -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -Wdate-time -D_FORTIFY_SOURCE=2 -I.. -I. -c -o istgt_log.o istgt_log.c gcc -DHAVE_CONFIG_H -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -DDEBUG -fno-strict-aliasing -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Winline -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -Wdate-time -D_FORTIFY_SOURCE=2 -I.. -I. -c -o istgt_conf.o istgt_conf.c gcc -DHAVE_CONFIG_H -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -DDEBUG -fno-strict-aliasing -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Winline -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -Wdate-time -D_FORTIFY_SOURCE=2 -I.. -I. -c -o istgt_sock.o istgt_sock.c gcc -DHAVE_CONFIG_H -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -DDEBUG -fno-strict-aliasing
Bug#957230: freebsd-buildutils: ftbfs with GCC-10
Package: src:freebsd-buildutils Version: 10.3~svn296373-7 Severity: normal Tags: sid bullseye User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can be built in a follow-up test rebuild. The package fails to build in a test rebuild on at least amd64 with gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The severity of this report will be raised before the bullseye release, so nothing has to be done for the buster release. The full build log can be found at: http://people.debian.org/~doko/logs/gcc10-20200225/freebsd-buildutils_10.3~svn296373-7_unstable_gcc10.log The last lines of the build log are at the end of this report. To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t=experimental install g++ Common build failures are new warnings resulting in build failures with -Werror turned on, or new/dropped symbols in Debian symbols files. For other C/C++ related build failures see the porting guide at http://gcc.gnu.org/gcc-10/porting_to.html [...] x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -D_GNU_SOURCE -pipe -Wall -DMACHINE_ARCH='"amd64"' -DMACHINE_MULTIARCH='"x86_64-linux-gnu"' -I/<>/build-tree/src/sys -isystem /usr/include/freebsd -fPIC -Wdate-time -D_FORTIFY_SOURCE=2-std=gnu99 -fstack-protector -c file2c.c -o file2c.o --- file2c.1.gz --- gzip -cn -9 file2c.1 > file2c.1.gz --- file2c --- x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -D_GNU_SOURCE -pipe -Wall -DMACHINE_ARCH='"amd64"' -DMACHINE_MULTIARCH='"x86_64-linux-gnu"' -I/<>/build-tree/src/sys -isystem /usr/include/freebsd -fPIC -Wdate-time -D_FORTIFY_SOURCE=2-std=gnu99 -fstack-protector -Wl,-z,relro -Wl,-z,now -o file2c file2c.o -lbsd CFLAGS="-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -D_GNU_SOURCE -pipe -Wall -DMACHINE_ARCH='\"amd64\"' -DMACHINE_MULTIARCH='\"x86_64-linux-gnu\"' -I/<>/build-tree/src/sys -isystem /usr/include/freebsd -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 " MAKEFLAGS=-j4 NO_WERROR=1 NOGCCERROR=1 NOSHARED=NO NO_SHARED=NO NO_PROFILE=1 bmake CC=x86_64-linux-gnu-gcc -m /<>/src/share/mk -C build-tree/src/usr.bin/brandelf --- objwarn --- Warning: Object directory not changed from original /<>/build-tree/src/usr.bin/brandelf --- brandelf.o --- --- brandelf.1.gz --- --- brandelf.o --- x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -D_GNU_SOURCE -pipe -Wall -DMACHINE_ARCH='"amd64"' -DMACHINE_MULTIARCH='"x86_64-linux-gnu"' -I/<>/build-tree/src/sys -isystem /usr/include/freebsd -fPIC -Wdate-time -D_FORTIFY_SOURCE=2-std=gnu99 -fstack-protector -c brandelf.c -o brandelf.o --- brandelf.1.gz --- gzip -cn -9 brandelf.1 > brandelf.1.gz --- brandelf --- x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -D_GNU_SOURCE -pipe -Wall -DMACHINE_ARCH='"amd64"' -DMACHINE_MULTIARCH='"x86_64-linux-gnu"' -I/<>/build-tree/src/sys -isystem /usr/include/freebsd -fPIC -Wdate-time -D_FORTIFY_SOURCE=2-std=gnu99 -fstack-protector -Wl,-z,relro -Wl,-z,now -o brandelf brandelf.o -lbsd CFLAGS="-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -D_GNU_SOURCE -pipe -Wall -DMACHINE_ARCH='\"amd64\"' -DMACHINE_MULTIARCH='\"x86_64-linux-gnu\"' -I/<>/build-tree/src/sys -isystem /usr/include/freebsd -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 " MAKEFLAGS=-j4 NO_WERROR=1 NOGCCERROR=1 NOSHARED=NO NO_SHARED=NO NO_PROFILE=1 bmake CC=x86_64-linux-gnu-gcc -m /<>/src/share/mk -C build-tree/src/sys/dev/aic7xxx/aicasm --- objwarn --- Warning: Object directory not changed from original /<>/build-tree/src/sys/dev/aic7xxx/aicasm --- aicasm_gram.c --- --- aicasm_macro_gram.c --- --- aicasm_scan.c --- --- aicasm_macro_scan.c --- --- aicasm_gram.c --- byacc -b aicasm_gram -d -o aicasm_gram.c aicasm_gram.y --- aicasm_macro_gram.c --- byacc -b aicasm_macro_gram -p mm -d -o aicasm_macro_gram.c aicasm_macro_gram.y --- aicasm_scan.c --- lex -oaicasm_scan.c aicasm_scan.l --- aicasm_macro_scan.c --- lex -Pmm -oaicasm_macro_scan.c aicasm_macro_scan.l --- aicasm.o --- --- aicasm_symbol.o --- --- aicasm.o --- x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -D_GNU_SOURCE -pipe -Wall -DMACHINE_ARCH='"amd64"' -DMACHINE_MULTIARCH='"x86_64-linux-gnu"' -I/<>/build-tree/src/sys -isystem /usr/include/freebsd -fPIC -Wdate-time -D_FORTIFY_SOURCE=2-D_GNU_SOURCE -isystem /usr/include/freebsd
Re: Bug#954831: RM: gcc-8, superseded by gcc-9
On 3/24/20 1:13 PM, Scott Kitterman wrote: > On Tue, 24 Mar 2020 08:33:55 +0100 Matthias Klose wrote: >> Package: ftp.debian.org >> >> Please remove gcc-8, gcc-8-cross and gcc-8-cross-ports. superseded by gcc-9 >> >> > Removed gcc-8-cross and gcc-8-cross-ports, however gcc-8 itself still has > quite some rdepends that need to be resolved before it can be removed. > Please > remove the moreinfo tag once that's been taken care of. > > Checking reverse dependencies... > # Broken Depends: > gcc-7: lib32gcc-7-dev [amd64] >lib64gcc-7-dev [i386] >libgcc-7-dev [amd64 i386] >libx32gcc-7-dev [amd64 i386] will be gone after the gcc-7 removal. > gcc-8-cross-mipsen: gdc-8-mips64-linux-gnuabi64 [amd64 i386] > gdc-8-mipsisa32r6-linux-gnu [amd64 i386] > gdc-8-mipsisa32r6el-linux-gnu [amd64 i386] > gdc-8-mipsisa64r6-linux-gnuabi64 [amd64 i386] > gdc-8-mipsisa64r6el-linux-gnuabi64 [amd64 i386] please remove as well. > ghdl: ghdl-gcc [amd64 arm64 armel armhf i386 mips64el mipsel s390x] > ghdl-llvm [amd64 arm64 armel armhf i386 mips64el mipsel s390x] > ghdl-mcode [amd64 i386] Marked for autoremoval on 06 April: #952110, #952324 > gprbuild: libgpr18 [mipsel] > libgpr2-dev [mipsel] > libgnatcoll: libgnatcoll17 [mipsel] > libgnatcoll17-dev [mipsel] > libgnatcoll-bindings: libgnatcoll-gmp17-dev [mipsel] > libgnatcoll-gmp18 [mipsel] > libgnatcoll-iconv17-dev [mipsel] > libgnatcoll-iconv18 [mipsel] > libgnatcoll-python17 [mipsel] > libgnatcoll-python17-dev [mipsel] > libgnatcoll-readline17-dev [mipsel] > libgnatcoll-readline18 [mipsel] > libgnatcoll-syslog1 [mipsel] > libgnatcoll-syslog1-dev [mipsel] > libgnatcoll-db: libgnatcoll-sql1 [mipsel] > libgnatcoll-sql1-dev [mipsel] > libgnatcoll-sqlite-bin [mipsel] > libgnatcoll-sqlite17-dev [mipsel] > libgnatcoll-sqlite18 [mipsel] > libgnatcoll-xref18 [mipsel] > libgnatcoll-xref18-dev [mipsel] > libxmlada: libxmlada-dom5 [mipsel] >libxmlada-dom8-dev [mipsel] >libxmlada-input5 [mipsel] >libxmlada-input8-dev [mipsel] >libxmlada-sax5 [mipsel] >libxmlada-sax8-dev [mipsel] >libxmlada-schema5 [mipsel] >libxmlada-schema8-dev [mipsel] >libxmlada-unicode5 [mipsel] >libxmlada-unicode8-dev [mipsel] CCing mips maintainers, and Ada maintainers. Please can we drop mipsel as a release architecture? > llvm-toolchain-8: clang-8 > libclang-8-dev > llvm-toolchain-9: clang-9 > libclang-9-dev CCing LLVM maintainers. > # Broken Build-Depends: > gcc-7: gcc-8-base > gcc-8-cross-mipsen: g++-8 > gcc-8-source (>= 8.3.0-7~) > gccgo-8 > gdc-8 > gnat-8 see above, gcc-7 can be removed. > gcc-mingw-w64: g++-8 >gcc-8-source (>= 8.3.0-10) >gnat-8 Stephen, please can you upload the package from experimental to unstable? maybe after building the binutils mingw64 package first. > ghdl: gcc-8-source > gnat-8 see above. > godot: libgcc-8-dev >libstdc++-8-dev has a RC issue, see #954608 > kfreebsd-10: gcc-8 CCed KFreebsd maintainers. > mysql-workbench: g++-8 other RC issues > open-ath9k-htc-firmware: gcc-8-source Marked for autoremoval on 06 April: #951891 > openjdk-8: g++-8 I'll fix that one. > openzwave: g++-8 >gcc-8 CCed Debian IoT
Re: Bug#945133: gcc-9: __has_attribute(ifunc) false positive on hurd and kfreebsd
Forwarded ... On 20.11.19 11:43, Fabian Kloetzl wrote: > Package: gcc-9 > Version: 9.2.1-17 > Severity: normal > > Dear Maintainer, > > Recently, the build of one of my packages failed on hurd-i386 and > kfreebsd-* due to unsupported ifuncs [1]. However, I had that code guarded > by __has_attribute(ifunc) which, unfortunately, evaluates to 1 on said > platforms. A minimal testcase is attached. > > Best, > Fabian > > 1: https://buildd.debian.org/status/package.php?p=phylonium >
Bug#944170: kfreebsd-10: non-standard gcc/g++ used for build (gcc-8)
Package: kfreebsd-10 Severity: important Tags: sid bullseye User: debian-...@lists.debian.org Usertags: non-standard-compiler, gcc-8, gcc-8-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-9/g++-9. Please keep this report open until the package uses the default compiler version (or gcc-9) 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-8 package can be removed for the release.
Same procedure as every year: GCC defaults change (GCC 9)
GCC 9 was released earlier this year, it is now available in Debian testing/unstable. I am planning to do the defaults change in mid August, around the time of the expected first GCC 9 point release (9.2.0). There are only soname changes for rather unused shared libraries (libgo) involved, and the gnat defaults change will be handled separately by the Debian Ada maintainers. The fortran module changes look ok according to Alastair McKinstry. The gcc-9 package still ftbfs on kfreebsd-*. We still have local patches for at least the various mips, kfreebsd and hurd targets. Please forward these upstream and make sure that these are applied upstream. powerpcspe support is removed upstream. I will keep pointing the default to GCC 8 for this target. Matthias
gcc-8 and gcc-9 builds using pgo and lto optimization
The recent gcc-8 and gcc-9 uploads to unstable are now built using pgo and lto optimization. Not on all architectures, see debian/rules.defs. On the plus side the compilers are 7-10% faster, however the build time of the compiler is much longer, adding 10-20 hours. If people feel that this isn't worth the extra build time, please file an issue for the package to disable those optimizations. Matthias
python3.8 ftbfs on the Hurd and KFreeBSD
Package: src:python3.8 Version: 3.8.0~b2-4 Severity: important The hurd-i386 and kfreebsd-* builds had some missing symbols, seen in https://buildd.debian.org/status/fetch.php?pkg=python3.8=hurd-i386=3.8.0%7Eb2-1=1562346528=0 https://buildd.debian.org/status/fetch.php?pkg=python3.8=kfreebsd-amd64=3.8.0%7Eb1-2=1560770610=0 trying to fix with the kfreebsd-hurd-fix.diff patch. However these now fail differently. Please could somebody have a look at these: https://buildd.debian.org/status/package.php?p=python3.8 Thanks, Matthias
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 13.04.19 17:01, Joerg Jaspert wrote: > On 15371 March 1977, Aurelien Jarno wrote: > >>> How is the move to debian-ports supposed to happen? I won't have the >>> time to do anything about it within the 2 weeks. > >> The process to inject all packages to debian-ports is to get all the >> deb, udeb and buildinfo files from the archives (main and debug) and >> associate them with the .changes files that are hosted on coccia. We'll >> also need to fetch all the associated GPG keys used to sign the changes >> files. Then we can inject that in the debian-ports archive. > >> It would be nice to have a bit more than 2 weeks to do all of that. > > Ok. How much? Is 6 or 8 weeks better? I don't think, given how long this > is on the table already, it doesn't make much difference if its 2 or 8. > Just something thats clear defined and not some random, non-clear > "sometime in the future" point. well, please go back in history to see the same short notice for the hppa removal, and then do the exercise how long it took to integrate that architecture on debian-ports. >
Bug#922496: GCC 9: gnat ftbs on kfreebsd-*
Package: src:gcc-9 Version: 9-20190216-2 Tags: important Severity: sid bullseye ftbfs, and we still have local, not forwarded patches for kfreebsd. s-tpopmo.adb:61:25: expected private type "System.Os_Interface.clockid_t" s-tpopmo.adb:61:25: found type universal integer s-tpopmo.adb:76:34: expected private type "System.Os_Interface.clockid_t" s-tpopmo.adb:76:34: found type universal integer ../gcc-interface/Makefile:299: recipe for target 'a-dispat.o' failed make[8]: *** [a-dispat.o] Error 1 make[8]: Leaving directory '/<>/build/gcc/ada/rts' gcc-interface/Makefile:622: recipe for target 'gnatlib' failed make[7]: *** [gnatlib] Error 2 make[7]: Leaving directory '/<>/build/gcc/ada' gcc-interface/Makefile:714: recipe for target 'gnatlib-shared-dual' failed make[6]: *** [gnatlib-shared-dual] Error 2 make[6]: Leaving directory '/<>/build/gcc/ada' gcc-interface/Makefile:811: recipe for target 'gnatlib-shared' failed make[5]: *** [gnatlib-shared] Error 2 make[5]: Leaving directory '/<>/build/gcc/ada' Makefile:104: recipe for target 'gnatlib-shared' failed make[4]: *** [gnatlib-shared] Error 2
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
GCC and binutils updates for buster
GCC 8 is available in testing/unstable, and upstream is approaching the first point release. I am planning to make GCC 8 the default at the end of the week (gdc and gccgo already point to GCC 8). Most runtime libraries built from GCC are already used in the version built from GCC 8, so I don't expect runtime incompatibilities anymore. There is one more transistion involved, bumping the libgfortran version. A pre-release version of binutils 2.31 is in testing now, and the final 2.31 release in unstable. These are the major versions for the upcoming buster release, still planning updates to a potential GCC 8.3.0 (estimated Jan 2019) release and binutils 2.31.1 release, or doing equivalent updates from the release branches. There are still a bunch of build failures triggered by GCC 8 [1], so fixing these should get some priority now. See [2] for changes in GCC 8, and the porting guide [3]. I'll be at DebCamp for the second half of the week, and at DebConf, so if there is interest for bug squashing sessions, feel free to grab me, and we can schedule such sessions on a short notice. GCC 5 and GCC 6 are going away, and I am planning the same with GCC 7 as soon as there are upstream kernel and glibc releases which are released after the GCC 8.1.0 release from April. The Debian release team lists toolchain support for our release architectures, and according to [4], the amd64, i386, armel, armhf, arm64 architectures are supported as primary architectures, and s390x is supported as a secondary architectures. Some notes on other candidates for release architectures: - armel: The armv4t default isn't used very much anymore, and we had issues in the past. - armhf: While arm-linux-gnueabihf is not explicitly listed as a primary architecture, I'm told that the arm-linux-armeabi triplet covers the hard float variants as well. - ppc64el: Not documented as primary architecture, but according to the backend maintainers the powerpc64-linux-gnu triplet includes the le variant. - mips*: There is no support for any mips-linux target either as a primary or secondary release architecture (only bare metal), which matches the experience with mips specific issues for the past Debian releases. I understand that port maintainers want to have their port included as a release architecture, however it becomes a burden if neither the upstream nor the Debian port maintainers can keep up with the general upstream development. Maybe we need something in between the alternatives of being a release arch or not, having the benefit of packages in testing/stable, but not being supported in a release. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-8;users=debian-...@lists.debian.org [2] https://gcc.gnu.org/gcc-8/changes.html [3] https://gcc.gnu.org/gcc-8/porting_to.html [4] https://gcc.gnu.org/gcc-8/criteria.html signature.asc Description: OpenPGP digital signature
preparing for binutils-2.31
According to [1], binutils 2.31 (currently in experimental) will branch in about a week, and I'll plan to upload the branch version to unstable. Test results are reported to [2], these look reasonable, except for the various mips targets, however as seen in the past, it doesn't make a difference if you wait with the introduction of a new binutils version early or later with the release. These tend to be only fixed as Debian porters report them. Matthias [1] https://sourceware.org/ml/binutils/2018-06/msg00158.html [2] https://sourceware.org/ml/binutils/2018-06/msg00170.html
GCC 7 build failures on armel, i386-gnu and kfreebsd-*
Apparently X-Debbugs-CC doesn't add up, so the ports lists didn't get a notification yet ... Please see #845159 [i| | ] [src:gcc-7] gcc-7: gnat fails to build on kfreebsd-* #861734 [i| | ] [src:gcc-7] gcc-7 fails to build gnattools on armel #861735 [i| | ] [src:gcc-7] gcc-7 fails to build gnat on the Hurd #861737 [i| | ] [src:gcc-7] gcc-7 fails to build gnat on KFreeBSD
Bug#852006: kfreebsd-10: non-standard gcc/g++ used for build (gcc-5)
Package: src:kfreebsd-10 Version: 10.3~svn300087-2 Severity: serious 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#845159: gcc-7: gnat fails to build on kfreebsd-*
Package: src:gcc-7 Severity: important Tags: sid buster X-Debbugs-CC: debian-bsd@lists.debian.org KFreeBSD maintainers, please fix and submit patches upstream. /bin/bash ./libtool --tag=CC --mode=compile /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -B/usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/bin/ -B/usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/lib/ -isystem /usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/include -isystem /usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../src/libssp-Wall -g -O2 -m32 -MT stpcpy-chk.lo -MD -MP -MF .deps/stpcpy-chk.Tpo -c -o stpcpy-chk.lo ../../../../src/libssp/stpcpy-chk.c /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -B/usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/bin/ -B/usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/lib/ -isystem /usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/include -isystem /usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/sys-include-c -DIN_GCC -W -Wall -g -O2 -g -O2 -fexceptions -DIN_RTS -DHAVE_GETIPINFO -fpic \ -iquote . -iquote .. -iquote ../.. -iquote /«PKGBUILDDIR»/src/gcc/ada -iquote /«PKGBUILDDIR»/src/gcc -I/«PKGBUILDDIR»/src/include -I./../.. terminals.c -o terminals.o libtool: compile: /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -B/usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/bin/ -B/usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/lib/ -isystem /usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/include -isystem /usr/lib/gcc-snapshot/x86_64-kfreebsd-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../src/libssp -Wall -g -O2 -m32 -MT stpcpy-chk.lo -MD -MP -MF .deps/stpcpy-chk.Tpo -c ../../../../src/libssp/stpcpy-chk.c -fPIC -DPIC -o .libs/stpcpy-chk.o terminals.c:1068:13: fatal error: termio.h: No such file or directory # include ^~ compilation terminated. ../gcc-interface/Makefile:292: recipe for target 'terminals.o' failed make[9]: *** [terminals.o] Error 1
Re: Enabling PIE by default for Stretch
[CCing porters, please also leave feedback in #835148 for non-release architectures] On 29.09.2016 21:39, Niels Thykier wrote: > Hi, > > As brought up on the meeting last night, I think we should try to go for > PIE by default in Stretch on all release architectures! > * It is a substantial hardening feature > * Upstream has vastly reduced the performance penalty for x86 > * The majority of all porters believe their release architecture is >ready for it. > * We have sufficient time to solve any issues or revert if it turns out >to be too problematic. > > As agreed on during the [meeting], if there are no major concerns to > this proposal in general within a week, I shall file a bug against GCC > requesting PIE by default on all release architectures (with backing > porters). please re-use #835148 > If there are only major concerns with individual architectures, I will > simply exclude said architectures in the "PIE by default" request. > > * Deadline for major concerns: Fri, 7th of October 2016. > > Fall-out > > > There will be some possible fall-out from this change: > > * There will be some FTBFS caused by some packages needing a rebuild >before reverse dependencies can enable PIE. These are a subset of >the bugs filed in the [pie+bindnow] build tests. > > * Some packages may not be ready for PIE. These will have to disable >it per package. A notable case being ghc (#712228), where we can >reuse the patch from Ubuntu to work around the issue. > > * A possible issue from Matthias was that no one has done a large scale >"PIE by default" on "arm* mips*". > > * There was concern about whether the 32bit arm architectures would be >notably affected by the PIE slow down (like x86 used to be). >It is not measured, but two arm porters did mention a possible >slowdown > > * It was questioned whether it made sense to invest time and effort in >enabling PIE for architectures which would not be included in Buster >(armel?). Personally, I do not see an issue, if the porters are >ready to put in the effort required. > > Thanks, > ~Niels > > [meeting]: > http://meetbot.debian.net/debian-release/2016/debian-release.2016-09-28-19.00.html > > [pie+bindnow]: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pie-bindnow-20160906=balint%40balintreczey.hu;dist=unstable > > > >
Re: Porter roll call for Debian Stretch
On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote: > On 09/20/2016 11:16 PM, Niels Thykier wrote: >>- powerpc: No porter (RM blocker) > > I'd be happy to pick up powerpc to keep it for Stretch. I'm already > maintaining powerpcspe which is very similar to powerpc. No, you are not maintaining powerpcspe as a release architecture, and that's something different than building packages for some of the ports architectures. If you can get powerpcspe accepted as a release architecture, then maybe you gain some credibility to maintain another release architecture ;) Matthias
Re: The (uncalled for) toolchain maintainers roll call for stretch
On 15.09.2016 22:43, Helge Deller wrote: > Hi Matthias, > > On 10.09.2016 00:48, Matthias Klose wrote: >> While the Debian Release team has some citation about the quality of the >> toolchain on their status page, it is not one of the release criteria >> documented >> by the release team. I'd like to document the status how I do understand it >> for >> some of the toolchains available in Debian. > >> Java/OpenJDK >> >> >> For the stretch release openjdk-8 will be fine as the default java >> implementation. For buster, gcj (to be removed in GCC 7) won't be available >> anymore, and we'll end up with architectures without a java implementation. >> At >> the same time I'd like to consider to stop providing OpenJDK zero builds, >> leaving powerpc and mips* without a java implementation as well (currently >> not >> building for openjdk-9). armhf (not armel) and s390x have Hotspot ports >> underway. > > Can you explain the reason why you consider stopping OpenJDK zero builds? the zero builds usually break on various architectures when the hotspot version is updated. So the zero ports require extra work and hinder migration of the packages to testing when they ftbfs. Afaiu the security team also doesn't care about these ports when they fail to build for security updates. > I'm asking, because on hppa we currently use gcj and we don't have any > OpenJDK port yet. > My hope was to fix at some point in future the old existing OpenJDK zero port > patches to get some newer > JDK even if it's slower. With your intention to stop zero builds, we probably > won't have any > JDK at all... I can't care for all ports which are not release architectures. Feel free to - send patches for the openjdk-8 package - look at the openjdk-9 build failures and send patches for the openjdk-9 package - Prepare to get these patches into openjdk-10, do regular builds of openjdk-10 when it becomes open for development, and continue to do so as long as you want to have it building. Matthias
Re: The (uncalled for) toolchain maintainers roll call for stretch
On 10.09.2016 09:59, Paul Gevers wrote: > Hi, > > On 10-09-16 00:48, Matthias Klose wrote: >> - fpc not available on powerpc anymore (may have changed recently) > > For whatever it is worth, this was finally fixed this week. It is > missing on mips*, ppc64el and s390x though, while at least some form of > MIPS is supported upstream. the trunk/3.1 works at least for ppc64el too.
The (uncalled for) toolchain maintainers roll call for stretch
While the Debian Release team has some citation about the quality of the toolchain on their status page, it is not one of the release criteria documented by the release team. I'd like to document the status how I do understand it for some of the toolchains available in Debian. I appreciate that the release criteria are somehow "reset" for the stretch release, and not copied from previous release decisions. GNU toolchain (GCC / binutils) -- GCC upstream has the notation of primary and secondary platforms, with the commitment to fix issues on these platforms [1], [2]. Debian architectures within the set of these platforms are: - aarch64-none-linux-gnu (starting with GCC 7) - arm-linux-gnueabi - i686-pc-linux-gnu - powerpc64-unknown-linux-gnu - x86_64-unknown-linux-gnu - s390x-linux-gnu Release architectures missing in the primary and secondary platforms: - armhf - mips* - powerpc - ppc64el As you see with arm64, new architectures become primary or secondary platforms only after a while, so that may explain the absence of powerpc64le-unknown-linux-gnu. The arm-linux-gnueabi is not that well defined, so it may include the hard float variant as well. However Debian default to armv4t, while the default configuration for upstream is armv5. However with the selected defaults Debian's libstdc++::future module is not complete and causes build failures on this architecture (same for sparc). Uncovered by the upstream primary and secondary platforms are the mips* architectures and powerpc. For the uncovered archs I would expect somehow more and pro-active Debian maintenance, however I fail to see this happen. - see the history of ftbfs on the buildd page of the gcc-snapshot package - see the status of the gcc-6 package for the pre-release uploads - see the number of RC issues for binutils which came up with 2.27, some still open. - Toolchain packages are not watched by porters, and I can't track every regression myself, however this is not done well by porters. On the recent Porter's call I didn't see any toolchain support for the powerpc architecture. For the mips* architectures we apparently have five or more active toolchain maintainers. I very much doubt that view. From my point of view these architecture would be perfect candidates for partial architectures, and until then should be removed from the set of the release architectures. For mips* that shouldn't be no news; please see my comments regarding both the toolchain and buildd status since at least DebConf 12 (release meetings during DebConfs). Java/OpenJDK For the stretch release openjdk-8 will be fine as the default java implementation. For buster, gcj (to be removed in GCC 7) won't be available anymore, and we'll end up with architectures without a java implementation. At the same time I'd like to consider to stop providing OpenJDK zero builds, leaving powerpc and mips* without a java implementation as well (currently not building for openjdk-9). armhf (not armel) and s390x have Hotspot ports underway. Other toolchains - clang/llvm not available on armel since 3.8. - fpc not available on powerpc anymore (may have changed recently) - mono not available more on powerpc Being demoted as a release architecture certainly is not a nice thing, and looking at past demotions, these were not done very coordinated, not allowing builds in the ports archive for some months. It would be good to find some middle-ground such that a port's demotion isn't a final thing, and it has a chance to become a release architecture again, maybe even as a partial architecture if we can define the meaning of such a thing. Matthias [1] https://gcc.gnu.org/gcc-6/criteria.html [2] https://gcc.gnu.org/gcc-7/criteria.html
Bug#835950: kfreebsd-10: non-standard gcc/g++ used for build (gcc-5)
Package: kfreebsd-10 Version: 10.3~svn300087-1 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.
Re: Bug#833829: libgcc-6-dev: Missing crtfastmath.o
Control: severity -1 important Control: tags -1 + help On 09.08.2016 09:12, Christian Marillat wrote: > Package: libgcc-6-dev > Version: 6.1.1-11 > Severity: grave > > I'm unable to build a package because crtfastmath.o is missing from this > package. Architecture is kfreebsd-i386. I don't see this bug on the > kfreebsd-amd64 > > , > | cc -Wall -DPIC -O2 -pipe -fno-tree-dominator-opts -fno-tree-pre > -ffast-math -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -g -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -fPIC -pthreadluma.c -o luma > | /usr/bin/ld: cannot find crtfastmath.o: No such file or directory > ` https://buildd.debian.org/status/fetch.php?pkg=gcc-6=kfreebsd-i386=6.1.1-11=1470331624 looks like this is never built, and the install step succeeds despite it complains about not finding this file.
Re: Bug#811063: gcc-6: FTBFS on kfreebsd-amd64 and kfreebsd-i386
On 18.01.2016 13:34, Svante Signell wrote: This file is for GNU/Hurd, the kFreeBSD file to patch is src/gcc/ada/s-osinte- kfreebsd-gnu.ads. my bad. now applied.
Re: openjdk-8 ftbfs again on kfreebsd
On 21.10.2015 23:23, Steven Chamberlain wrote: Control: tags -1 + patch Hi, Matthias Klose wrote: /usr/lib/jvm/java-8-openjdk-kfreebsd-amd64/include/jni.h:45:20: fatal error: jni_md.h: No such file or directory compilation terminated. the header is now included in include/bsd instead of include/linux. Was this an intended change? Please either fix it, or revert it. That was not intentional, but something changed upstream that we need to patch. The attached patch hunk appended to kfreebsd-support-jdk.diff will fix this. I've tested that the resulting openjdk-8 can be used as a build dependency to successfully build itself again. thanks, for the current security update I just copied the bsd directory to linux. will apply this later. 8u65-b17 and 8u72-b04 required more changes. Now I see that the kfreebsd-jdk-support patch is not in a shape to be applied for other builds as well. In same places it just replaces linux with bsd, and doesn't extend it, e.g. Awt2dLibraries.gmk. So pretty please take the time to move these patches to openjdk-9, sign the OCA, and submit these upstream. Matthias
Bug#801954: openjdk-8 ftbfs again on kfreebsd
Package: src:openjdk-8 Version: 8u66-b01-6 Severity: important /usr/lib/jvm/java-8-openjdk-kfreebsd-amd64/include/jni.h:45:20: fatal error: jni_md.h: No such file or directory compilation terminated. the header is now included in include/bsd instead of include/linux. Was this an intended change? Please either fix it, or revert it.
Re: Defaulting to i686 for the Debian i386 architecture
question to the Hurd and KFreeBSD maintainers ... change that on these platforms too? On 28.09.2015 23:14, Ben Hutchings wrote: We propose to drop support for i386 processors older than 686-class in the current release cycle. This would include folding libc6-i686 into libc6, changing the default target for gcc, and changing the 586 kernel flavour to 686 (non-PAE). Since the 686-class, introduced with the Pentium Pro, is now almost 20 years old, we believe there are few Debian systems still running that have 586-class or hybrid processors. The only such processors apparently still available for sale are the DM Vortex86 family, Intel Quark and Xeon Phi, of which we currently only support the Vortex86. Indeed, the likely reasons for users to choose i386 over amd64 today are to reduce memory consumption or to run i386 binaries for which the source is not available - not because they're using 32-bit processors. The older processors would of course continue to be supported in jessie until at least 2018, and until 2020 if i386 is included in jessie LTS. Maintaining support for these older processors hurts the Debian i386 architecture in several ways: * Prevents optimisation for 686-class without run-time checks or multiple library builds * Divergence from upstream code in various packages which often assume at least 686-class processors * Can require user intervention to install optimised library packages e.g. debootstrap does not install libc6-i686 - Ben Hutchings - Aurelien Jarno - Matthias Klose
Re: Bug#761067: openjdk-8 kfreebsd patches need updates and upstreaming
any update on this? debian-java currently thinks about moving forward with openjdk-8.
Re: Bug#797324: gcc-5: please support multiarch path to kfreebsd-kernel-headers
On 08/31/2015 03:42 PM, Steven Chamberlain wrote:
> Hi,
>
> YunQiang Su wrote:
>> +ifeq ($(DEB_TARGET_ARCH_OS),kfreebsd)
>> : # multilib builds without b-d on gcc-multilib (used in
>> FLAGS_FOR_TARGET)
>> +ln -sf /usr/include/$(DEB_TARGET_MULTIARCH) $(builddir)/sys-include
>> +else
>> if [ -d /usr/include/$(DEB_TARGET_MULTIARCH)/asm ]; then \
>>mkdir -p $(builddir)/sys-include; \
>>ln -sf /usr/include/$(DEB_TARGET_MULTIARCH)/asm
>> $(builddir)/sys-include/asm; \
>> fi
>> +endif
>>
>>
>> Why not do the same things like Linux?
>> aka, only link the headers really needed.
>
> I tried this at first, but the list became quite long:
>
> : # multilib builds without b-d on gcc-multilib (used in
> FLAGS_FOR_TARGET)
> for d in asm machine machine-i386 x86 sys osreldate.h; do \
> if [ -e /usr/include/$(DEB_TARGET_MULTIARCH)/$$d ]; then \
> mkdir -p $(builddir)/sys-include; \
> ln -sf /usr/include/$(DEB_TARGET_MULTIARCH)/$$d
> $(builddir)/sys-include/$$d; \
> fi \
> done
>
> This seems fragile and it could break build when kernel headers are
> next updated.
>
> Having all of /usr/include/$(DEB_TARGET_MULTIARCH) in the include
> search path would be much simpler, and doesn't seem harmful to me; the
> include search path already includes /usr/include and *all* our kernel
> headers are located there.
>
>> +
>> +ifeq ($(DEB_TARGET_ARCH_OS),kfreebsd)
>> +: # multilib builds without b-d on gcc-multilib (used in
>> FLAGS_FOR_TARGET)
>> +ln -sf /usr/include/$(DEB_TARGET_MULTIARCH) $(builddir_jit)/sys-include
>> +endif
>> +
>
> I'm glad you asked about this, thanks.
>
> The comment is misleading here (copy+pasted from the other patch hunk),
> and I should remove it. This is not for multilib builds, but to build
> the native jit compiler after we have moved kernel headers to a
> multiarch path.
why is this needed for the jit build?
>> Build-deps on gcc-multilib should be a better choice.
>> You can link the needed headers in libc6-dev-{i386,amd64} multilib libraries.
>
> Maybe I don't understand fully, but I don't think multilib is as
> powerful as moving kernel headers into multiarch paths; and we may
> need to move our headers anyway.
>
> We'd like to be able to cross-build glibc next, for linux-amd64 target
> from a kfreebsd-amd64 build system (and then amd64<->arm and others).
> This requires linux-libc-dev:amd64 to be installable alongside
> kfreebsd-kernel-headers (because it is build-essential).
at least for stretch, I'd like to avoid any build dependencies on foreign
architectures, for both the native and the cross compiler. It's too new, not
yet completely supported.
this might be a long term goal, however for now I would prefer using the
standalone approach like done in cross-toolchain-base.
> Since many kernel headers have the same names, one (or both) packages
> need to move headers into multiarch paths.
>
>> I think making kfreebsd have the similar way to work should be ideal.
>
> Or rather, it seems ideal if someday linux kernel headers could move
> too, and eventually multilib would become obsolete?
I mentioned this to Aurelian too, but I think this would need testing first,
what it will break ... and my guess is that this will be a lot.
Matthias
Bug#782444: libgccjit tests fail on kfreebsd and hang the buildds
Package: src:gcc-5 Version: 5-20150410-1 Severity: important the libgccjit tests fail on kfreebsd, hang the buildds, and get killed with a timeout. Please see the build logs. As a workaround, I'll disable running these on these targes, so please find the build logs at https://buildd.debian.org/status/logs.php?pkg=gcc-5arch=kfreebsd-i386 https://buildd.debian.org/status/logs.php?pkg=gcc-5arch=kfreebsd-amd64 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/552a5838.3090...@debian.org
Bug#781424: GCC 5 needs an update for gnat on kfreebsd
Package: src:gcc-5 Version: 5-20150327-1 Severity: important Tags: stretch sid https://buildd.debian.org/status/package.php?p=gcc-5suite=experimental s-taprop.adb:749:17: clock_getres is undefined ../gcc-interface/Makefile:305: recipe for target 's-taprop.o' failed make[8]: *** [s-taprop.o] Error 1 make[8]: Leaving directory '/«PKGBUILDDIR»/build/gcc/ada/rts' gcc-interface/Makefile:2583: recipe for target 'gnatlib' failed make[7]: *** [gnatlib] Error 2 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/551733f4.7090...@debian.org
Re: Bug#761067: openjdk-8 kfreebsd patches need updates and upstreaming
On 03/19/2015 11:25 PM, Steven Chamberlain wrote: Matthias Klose wrote: I forwarded this upstream. Many thanks for that. I can't find this in the bug tracker or public mailing lists, but if they need anything before the patches can be merged, please let me know. I was told, that your name can be found at http://www.oracle.com/technetwork/community/oca-486395.html#c I don't know when this was added. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/550b4e7d.6050...@ubuntu.com
binutils test failures on kfreebsd
Package: src:binutils Version: 2.24.90.20141014-1 Severity: important The testsuite shows around 190 test failures on both i386 and amd64. Please could a porter have a look? -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544111c3.7020...@debian.org
Re: kFreeBSD port in Jessie
Am 25.09.2014 um 23:10 schrieb Jonathan Wiltshire: Hi, The results of the final architecture qualification will soon be published. In there is reference to a number of concerns about the kFreeBSD port and its place in Jessie. We want to recognise that you have put in a lot of work recently, and even some personal expense, to keep the kFreeBSD port viable. However, we're greatly concerned that there remain only one, maybe two active porters in recent months and our criteria for Jessie states unambiguously that 5 is an absolute minimum. The rationale for this is that being part of a stable release involves, as you already know, at least three years committment to maintaining stable and oldstable, on top of continuing development in sid. It has implications for DSA, the security team, the release team and others. The problem with lack of manpower is borne out in reports such as #756464, which has been open at critical severity since July and was last updated getting on for a month ago. There's a stated aim to remove the kernel version 9 from Jessie, which hasn't happened yet. Some RC bugs are fixed in experimental but those fixes haven't been uploaded to sid. How is this different than mips/mipsel? The list of porters lists buildd admins as well, which don't act as porters. Please count the numbers of porters again, after removing the buildd admins. Meanwhile, please take this mail as a courtesy in advance of publication of the architecture qualification, and we encourage you to keep in touch about your status and plans over the next few weeks. Is this an issue for kfreebsd? Instead you are waiving the mips/mipsel hardware support for the third release in a row, still listening on the promised fixes ... these didn't happen now for more than three years, why still waiting for those? It looks like the kfreebsd and mips ports aren't measured the same way. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542ab6fc.3070...@debian.org
Re: Bug#761277: gdc uninstallable on kfreebsd because of missing dep. libphobos-4.9-dev
Control: severity -1 important Am 12.09.2014 um 12:47 schrieb Thibaut Paumard: Package: gdc Version: 4.9.1-4 Severity: grave Hi, gdc currently depends on libphobos-4.9-dev, including on kfreebsd-*, but libphobos-4.9-dev is not beeing built on these architectures. It may be that the bug is that libphobos should be built on kfreebsd. From the gcc-4.9 build log: -Dlibphobos_archs=amd64 armel armhf i386 x32 kfreebsd-amd64 kfreebsd-i386 but Will not build the phobos D runtime library: disabled for system kfreebsd-gnu please can the kfreebsd maintainers have a look, if phobos can be built? -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5412e5c4.3020...@debian.org
Re: Bug#761277: gdc uninstallable on kfreebsd because of missing dep. libphobos-4.9-dev
Am 12.09.2014 um 15:13 schrieb Thibaut Paumard: While it's your prerogative to decrease the severity, please note that this bug means that all the packages that build-depend on gdc (22 packages in jessie) are currently in an FTBFS-state on kfreebsd. sure, and they still will ftbfs without libphobos. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54132eac.2010...@debian.org
Bug#761067: openjdk-8 kfreebsd patches need updates and upstreaming
Package: src:openjdk-8 Version: 8u40~b04-2 Severity: important see the buildd logs SetupNativeCompilation(BUILD_LIBATTACH) [2] LIBRARY := attach [3] OUTPUT_DIR := /«PKGBUILDDIR»/build/jdk/lib/amd64 [4] SRC := /«PKGBUILDDIR»/src/jdk/src/solaris/native/sun/tools/attach [5] EXCLUDE_FILES := SolarisVirtualMachine.c LinuxVirtualMachine.c BsdVirtualMachine.c AixVirtualMachine.c [6] LANG := C [7] OPTIMIZATION := LOW [8] CFLAGS := -W -Wall -Wno-unused -Wno-unused-parameter -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LITTLE_ENDIAN -DBSD -D_ALLBSD_SOURCE -DNDEBUG -DARCH='amd64' -Damd64 -DRELEASE='1.8.0_40-internal' -I/«PKGBUILDDIR»/build/jdk/include -I/«PKGBUILDDIR»/build/jdk/include/bsd -I/«PKGBUILDDIR»/src/jdk/src/share/javavm/export -I/«PKGBUILDDIR»/src/jdk/src/solaris/javavm/export -I/«PKGBUILDDIR»/src/jdk/src/share/native/common -I/«PKGBUILDDIR»/src/jdk/src/solaris/native/common -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fPIC -I/«PKGBUILDDIR»/build/jdk/gensrc_headers [9] CFLAGS_windows := /Gy [10] MAPFILE := /«PKGBUILDDIR»/src/jdk/make/mapfiles/libattach/mapfile-bsd [11] VERSIONINFO_RESOURCE := /«PKGBUILDDIR»/src/jdk/src/windows/resource/version.rc [12] RC_FLAGS := -D JDK_FNAME=attach.dll -D JDK_INTERNAL_NAME=attach -D JDK_FTYPE=0x2L [13] LDFLAGS := -Xlinker -z -Xlinker relro -Xlinker -Bsymbolic-functions -Xlinker --hash-style=both -shared -L/«PKGBUILDDIR»/build/jdk/lib/amd64 -L/«PKGBUILDDIR»/build/jdk/lib/amd64/server -Xlinker -z -Xlinker origin -Xlinker -rpath -Xlinker \$$ORIGIN [14] LDFLAGS_solaris := -ldoor [15] LDFLAGS_windows := /ORDER:@/«PKGBUILDDIR»/src/jdk/make/mapfiles/libattach/reorder-windows-x86_64 [16] LDFLAGS_SUFFIX := -ljava -ljvm [17] LDFLAGS_SUFFIX_windows := /«PKGBUILDDIR»/build/jdk/objs/libjava/java.lib advapi32.lib psapi.lib [18] OBJECT_DIR := /«PKGBUILDDIR»/build/jdk/objs/libattach [19] DEBUG_SYMBOLS := true lib/ServiceabilityLibraries.gmk:49: *** No sources found for BUILD_LIBATTACH when looking inside the dirs /«PKGBUILDDIR»/src/jdk/src/solaris/native/sun/tools/attach. Stop. make[3]: Leaving directory '/«PKGBUILDDIR»/src/jdk/make' make[2]: *** [libs-only] Error 2 BuildJdk.gmk:70: recipe for target 'libs-only' failed make[2]: Leaving directory '/«PKGBUILDDIR»/src/jdk/make' make[1]: *** [jdk-only] Error 2 /«PKGBUILDDIR»/src//make/Main.gmk:115: recipe for target 'jdk-only' failed make[1]: Leaving directory '/«PKGBUILDDIR»/build' debian/rules:1242: recipe for target 'stamps/build' failed make: *** [stamps/build] Error 1 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54104676.9070...@debian.org
Re: Bug#759558: gcj-4.9-jdk: broken symlinks for j{awt,ni}{,_md}.h
Am 28.08.2014 um 18:08 schrieb Steven Chamberlain: reassign 759558 gcj-4.9-jdk found 759558 gcc-4.9/4.9.1-9 thanks gcj-4.9-jdk isn't a source package, so the BTS seems a little confused about who to mail about this bug; I don't think the maintainers were notified. The original bug report is here: https://bugs.debian.org/759558#5 fixed in the VCS. Thanks, nice to know about this. FWIW I'd prefer openjdk-7 as kfreebsd's default JDK. We may see kfreebsd-specific issues in openjdk-7 or gcj-4.9-jdk from time to time, but increasingly, if other architectures have switched over to openjdk-7, we'll see more issues like this which are FTBFS/broken on kfreebsd but actually due to gcj and not the architecture itself. And AIUI gcj is sort of deprecated within the GCC project now? The good thing about gcj is that it doesn't break with upgrades, while openjdk-7 does on KFreeBSD. We had several months periods where the debian-bsd maintainers didn't care about updating their patches and were blocking the Debian project with this kind of attitude. See several emails from my side to the debian-bsd and debian-java ML's. Apparently this didn't change with OpenJDK-8, the current packages fail to build. No effort was made to get the kfreebsd port upstream. I agree it would be good to switch to OpenJDK-7 for kfreebsd as well, but I can't see any action from the KfreeBSD people how to bring the kfreebsd changes upstream and keep up with the openjdk packages in Debian, and not blocking current Debian development instead. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ffada0.7080...@debian.org
Bug#751309: freebsd-glue: non-standard gcc/g++ used for build (gcc-4.7)
Package: freebsd-glue Version: 0.2.16 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-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wuoo9-0002pf...@ravel.debian.org
Bug#751316: kfreebsd-10: non-standard gcc/g++ used for build (gcc-4.7)
Package: kfreebsd-10 Version: 10.0-6 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-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wuoog-0002qi...@ravel.debian.org
Bug#750668: python3.4 ftbfs on kfreebsd, clock() returning -1
Package: python3.4
Version: 3.4.1-3
Severity: serious
Tags: sid jessie
BEGIN pystone static
cd /«PKGBUILDDIR»/build-static ./python ../Lib/test/pystone.py
Traceback (most recent call last):
File ../Lib/test/pystone.py, line 277, in module
main(loops)
File ../Lib/test/pystone.py, line 68, in main
benchtime, stones = pystones(loops)
File ../Lib/test/pystone.py, line 75, in pystones
return Proc0(loops)
File ../Lib/test/pystone.py, line 96, in Proc0
starttime = clock()
RuntimeError: the processor time used is not available or its value cannot be
represented
debian/rules:543: recipe for target 'stamps/stamp-pystone' failed
make: *** [stamps/stamp-pystone] Error 1
Modules/timemodule.c has
static PyObject *
floatclock(_Py_clock_info_t *info)
{
clock_t value;
value = clock();
if (value == (clock_t)-1) {
PyErr_SetString(PyExc_RuntimeError,
the processor time used is not available
or its value cannot be represented);
return NULL;
}
Is this supposed to work on kfreebsd? It is easy to disable the pybench run
itself.
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53907fb1.30...@debian.org
removal of upstream gnat support for KFreeBSD
Hi, in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56274 Arnaud Charlet proposes to remove the KFreeBSD Ada support upstream, unless somebody cares about the port. Please can the Debian gnat maintainers or the Debian KFreeBSD porters forward the KFreeBSD changes upstream? It currently builds in 4.9. Thanks, Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/537dcb1f.5060...@debian.org
Re: preparing for GCC 4.9
sorry, can't help with this. setting up a pbuilder or sbuild, and start building packages from the base system? Matthias Am 13.05.2014 03:26, schrieb David Gosselin: I'm in the same boat as Patrick, except with a PowerMac G5. Please let us know how to begin. Thanks, Dave On May 12, 2014, at 16:02, Patrick Baggett baggett.patr...@gmail.com wrote: Hi Matthias et al, I'd like to try to do some of this using my sparc box and see how far I get. Is there a link that explains how to set up these steps? Others seem to just know what to do, but I haven't the slightest idea of where to begin. I have a box with gcc-4.9, plenty of disk space, and electricity to burn. Where do I start? Patrick On Thu, May 8, 2014 at 10:25 AM, Matthias Klose d...@debian.org wrote: With gcc-4.9 now available in testing, it is time to prepare for the change of the default to 4.9, for a subset of architectures or for all (release) architectures. The defaults for the gdc, gccgo, gcj and gnat frontends already point to 4.9 and are used on all architectures. Issue #746805 tracks the gfortran default change, including the change of the Fortran 90 module version change. The Debian archive was rebuilt twice on amd64, once in February, resulting in bug submissions for GCC and feedback for the porting guide [1], a second time in March to file issues for packages failing to build with GCC 4.9 [2]. Another test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any other compiler regressions on these architectures. I would like to see some partial test rebuilds (like buildd or minimal chroot packages) for other architectures. Any possibility to setup such a test rebuild for some architectures by the porters? Afaics the results for the GCC testsuite look okish for every architecture. I'll work on fixing the build failures in [2], help is of course appreciated. Almost all build failures are analyzed and should be easy to fix (exceptions e.g. #746883). Patches for the ones not caused by the Debian packaging may be found in distributions already using GCC 4.9 as the default compiler (e.g. Fedora 21). If anything goes well, and a large amount of build failures are fixed, I plan to make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end of May, beginning of June. Bugs reports for packages building with a legacy version of GCC (4.6, 4.7, 4.8) will be filed. Matthias [1] http://gcc.gnu.org/gcc-4.9/porting_to.html [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org -- To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536ba1ce.9070...@debian.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5371fb4e.9090...@debian.org
Bug#747981: kfreebsd-8: non-standard gcc/g++ used for build (gcc-4.6)
Package: kfreebsd-8 Version: 8.3-6+deb7u1 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-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wkbor-0002yd...@ravel.debian.org
Bug#747983: kfreebsd-9: non-standard gcc/g++ used for build (gcc-4.6)
Package: kfreebsd-9 Version: 9.0-10+deb70.6 9.2-2 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-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wkbos-0002yq...@ravel.debian.org
preparing for GCC 4.9
With gcc-4.9 now available in testing, it is time to prepare for the change of the default to 4.9, for a subset of architectures or for all (release) architectures. The defaults for the gdc, gccgo, gcj and gnat frontends already point to 4.9 and are used on all architectures. Issue #746805 tracks the gfortran default change, including the change of the Fortran 90 module version change. The Debian archive was rebuilt twice on amd64, once in February, resulting in bug submissions for GCC and feedback for the porting guide [1], a second time in March to file issues for packages failing to build with GCC 4.9 [2]. Another test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any other compiler regressions on these architectures. I would like to see some partial test rebuilds (like buildd or minimal chroot packages) for other architectures. Any possibility to setup such a test rebuild for some architectures by the porters? Afaics the results for the GCC testsuite look okish for every architecture. I'll work on fixing the build failures in [2], help is of course appreciated. Almost all build failures are analyzed and should be easy to fix (exceptions e.g. #746883). Patches for the ones not caused by the Debian packaging may be found in distributions already using GCC 4.9 as the default compiler (e.g. Fedora 21). If anything goes well, and a large amount of build failures are fixed, I plan to make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end of May, beginning of June. Bugs reports for packages building with a legacy version of GCC (4.6, 4.7, 4.8) will be filed. Matthias [1] http://gcc.gnu.org/gcc-4.9/porting_to.html [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536ba1ce.9070...@debian.org
Re: Bug#743131: FTBFS if default-jdk is gcj-jdk
Am 31.03.2014 19:50, schrieb Steven Chamberlain: tags 743131 + patch jessie sid clone 743131 -1 reassign -1 src:eclipse-cdt found -1 eclipse-cdt/8.3.0-1 thanks Hi, On 31/03/14 17:49, Sébastien Villemot wrote: Therefore, would that be an acceptable course of action for you if I restrict the architecture set of glpk-java to those were the default JDK is openjdk, and then downgrade the present bug to severity important? A better way seems to be: Build-Depends: default-jdk (= 2:1.6) which is satisfied only by arches having openjdk-6 or openjdk-7 as default currently. That way, if kfreebsd (or any other architecture) switches to openjdk as default in the future, your package can be built again without changes. (Although - I'm hoping kfreebsd, along with all release architectures, might be able to use openjdk-7 for jessie, greatly simplifying things and making this change unnecessary). In the meantime, the outdated kfreebsd binaries could be removed by ftpmaster if you'd like the package to migrate. Steven, the kfreebsd port was backported from OpenJDK 8 by Damien. In the past we had to wait for several months for updated kfreebsd patches to get the openjdk-7 built again on these architectures, despite pinging the kfreebsd porters. How did that change? How can you make sure that this won't repeat again? I'm not in favour defaulting that again to openjdk-7 or openjdk-6. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5339b169.10...@debian.org
Re: Roll call for porters of architectures in sid and testing
Am 16.01.2014 13:31, schrieb Aníbal Monsalve Salazar: For mips/mipsel, I - fix toolchain issues together with other developers at ImgTec It is nice to see such a commitment, however in the past I didn't see any such contributions. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52de6b8b.2060...@debian.org
Re: Bug#732282: stop building java for sparc, sparc64, s390, kfreebsd-any
Am 16.12.2013 11:34, schrieb Matthias Klose: Package: java-common Version: 0.50 Severity: serious Tags: jessie, sid openjdk-7 currently ftbfs on sparc, sparc64, s390, kfreebsd-any. So please either remove the default-* packages on these archs, or fall back to gcj. - the hotspot port for linux sparc isn't maintained anymore by upstream. If a porter is interested, maybe investigate how to build the zero vm on these architectures. - s390 needs an update of the s390 debian specific patch. Not working on this myself. - the debian kfreebsd patches need an update. I don't think it's feasible to burden the openjdk maintainers or the security team with patch maintenance. I understand that the bsd support is found upstream in openjdk-8, so maybe try that again for the next upstream version. ia64, sparc, sparc64, kfreebsd-i386 and kfreebsd-amd64 are now demoted to gcj on the VCS. Had to demote ia64 too, and don't want to investigate anymore. I'll upload java-common later this week. The good news is that arm64, mips, mipsel, powerpcspe, ppc64el and x32 are now promoted to use openjdk-7. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d24e65.5000...@debian.org
libcilkrts for kfreebsd and the Hurd fails to build
Package: gcc-4.9 Severity: important Disabling libcilkrts for kfreebsd and the Hurd for now. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d13096.7010...@debian.org
gcc-4.9 uploaded to experimental
gcc-4.9 is uploaded to experimental, asking the porters to watch for build failures and corresponding patches. See https://buildd.debian.org/status/package.php?p=gcc-4.9suite=experimental These are already fixed in the vcs. - fixed the gospec.c ftbfs on archs without ld.gold - fixed the g++ b-d on armel/armhf Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52cfd843.1010...@debian.org
Removing openjdk-7 for kfreebsd and sparc
please see http://bugs.debian.org/732282 Is there anybody who wants to maintain openjdk for these architectures? If not, I'll go ahead and make gcj-jdk the default again on those architectures and request removal of the kfreebsd and sparc binaries. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bf3db0.9040...@ubuntu.com
Re: Bits from the Release Team (Jessie freeze info)
Am 29.10.2013 17:48, schrieb Ian Jackson: (Mind you, I have my doubts about a process which counts people promising to do work - it sets up some rather unfortunate incentives. I guess it's easier to judge and more prospective than a process which attempts to gauge whether the work has been done well enough.) As an example I remember having received several complains from e.g. the GCC maintainers in regards to the state of gcc on various ports[1]. Here I would suspect a patch would be sufficient without needing to actually NMU gcc to get the fix in. There are also stuff like the port concerns from DSA that attention. Right. that's not enough. GCC has some primary and some secondary release architectures. Toolchain support for primary architectures in Debian should be waived, for the secondary and other architectures, Debian needs somebody who is maintaining the relationship between Debian and upstream. Surprisingly this is the case for many non-release Debian architectures like kfreebsd, the Hurd, alpha, hppa, m68k, but not for Debian release architectures like s390, sparc, ia64 and mips*. So we really need somebody to care about this, where the port is considered a secondary citizen or no citizen, or we should demote a port to the ports archive. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527c2170.8020...@debian.org
Re: default-jdk change on kfreebsd
Am 17.08.2013 16:21, schrieb Christoph Egger: Moin! Steven Chamberlain ste...@pyro.eu.org writes: On 16/08/13 13:15, Christoph Egger wrote: I talked to rene here at DebConf. The problems did show up in the past when running the testsuite (hangs). Rene tried with current OpenJDK on falla -- in current kfreebsd sid -- and it does now works as well as anywhere on !linux-x86 which means we should be fine from this side. Should we treat this as a transition co-ordinated with the release team, so that all rdepends are rebuilt? I'd actually prefer this in any case; it would fix some past build failures such as eclipse. And possibly libjogl-java, leading to scilab and more being built. (But perhaps these packages should also have had tighter Build-Depends if gcj is insufficient.) I've been talking with Julien from the release team and Damien, the openjdk maintainer here at DebConf. Switching could -- as far as I understand -- work as follows: * Make openjdk-7 default. No other actions needed and should work for a start it is nice that openjdk now builds on kfreebsd. thanks very much for getting this done, everybody involved. however I'm a bit sceptical that people will be able to keep up with hotspot changes. Is there any commitment from the kfreebsd side to keep this building with newer hotspot versions? Ideally that would mean to have the kfreebsd port is integrated upstream and tested with openjdk8 on an ongoing basis. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52167a2a.80...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 13.06.2013 21:47, schrieb Thorsten Glaser: Matthias Klose dixit: The Java and D frontends now default to 4.8 on all architectures, the Go frontend stays at 4.7 until 4.8 get the complete Go 1.1 support. I’d like to have gcj at 4.6 in gcc-defaults for m68k please, until the 4.8 one stops FTBFSing. please send a patch. From me nothing against switching C/C++ to 4.8 for m68k at this point, but I’d like to hear at least Wouter’s opinion on that, and possibly Mikael since he’s not just doing work upstream on gcc but also using it (for ColdFire) heavily. same as well, please send a patch. For Ada, I’d like to see a successful build of gnat-4.8 (from src:gcc-4.8, if I understand the recent changes right) first; gnat-4.6 mostly works at the moment, but I’m not sure about the upstream situation wrt. patches from Mikael. try it and send a patch please. thanks for your cooperation, Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51baf88c.3080...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 13.06.2013 16:46, schrieb Steven Chamberlain: Hi, On 13/06/13 13:51, Matthias Klose wrote: GCC 4.8 is now the default on all x86 architectures, and on all ARM architectures (the latter confirmed by the Debian ARM porters). I did not get any feedback from other port maintainers, so unless this does change and port maintainers get involved with toolchain maintenance, the architectures staying at 4.6 or 4.7 shouldn't be considered for a successful release (re-)qualification. I trust these are the architectures that are okay so far: | gcc48_archs = amd64 armel armhf arm64 i386 x32 kfreebsd-amd64 kfreebsd-i386 hurd-i386 no, they are probably not ok, and there surely are yet undiscovered regressions, but at least the ARM porters did agree to address these. Same seems to be true for the kfreebsd and hurd porters. They did change GCC defaults usually at the same time as this was done for the x86 linux archs. So the following would be the architectures for which some response is requested urgently from port maintainers, to confirm they are ready for GCC 4.8 as default: Release arches: ia64 mips mipsel powerpc s390 s390x sparc All the above have built gcc-4.8.1-2 or higher. and nobody committing to scan the bts for architecture specific issues, nobody to prepare test cases, nobody to forward these. Other ports: alpha hppa* m68k powerpcspe ppc64 sh4* sparc64* * these ports don't appear to have successfully built GCC 4.8 yet. afaics, alpha, powerpcspe and ppc64 did build. Note that you cannot trust the hppa status, this port is still denied access to ports.debian.org and is kept in another place. So yes, some of these ports are in better shape than the ports released with wheezy. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51bafa9e.5080...@debian.org
Re: Current and upcoming toolchain changes for jessie
Am 07.05.2013 15:25, schrieb Matthias Klose: The decision when to make GCC 4.8 the default for other architectures is left to the Debian port maintainers. [...] Information on porting to GCC 4.8 from previous versions of GCC can be found in the porting guide http://gcc.gnu.org/gcc-4.8/porting_to.html It is planned to only keep GCC 4.8 and the upcoming GCC 4.9, and to remove 4.4, 4.6 and 4.7 from jessie. GCC 4.8 is now the default on all x86 architectures, and on all ARM architectures (the latter confirmed by the Debian ARM porters). I did not get any feedback from other port maintainers, so unless this does change and port maintainers get involved with toolchain maintenance, the architectures staying at 4.6 or 4.7 shouldn't be considered for a successful release (re-)qualification. The Java and D frontends now default to 4.8 on all architectures, the Go frontend stays at 4.7 until 4.8 get the complete Go 1.1 support. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b9c05f.8050...@debian.org
Re: [Openjdk] Bug#708818: Updated kFreeBSD support
Am 30.05.2013 14:05, schrieb Christoph Egger: Most of them probably only get fixed once openjdk-7 is default-jdk and there seems to unfortunately still be the hang on kfreebsd-i386 during the build, or the check target? Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a742cd.5020...@ubuntu.com
changing the java default to java7, and dropping java support for some architectures
It's time to change the Java default to java7, and to drop java support on
architectures with non-working java7.
Patches for the transition to Java7 should be available in the BTS, mostly
submitted by James Page. Some may be still lurking around as diffs in Ubuntu
packages, apologies for that. There are a few cases, where Java7 is not yet an
alternative to Java6, so the transition should not be blocked on these missing
bits. However it should be clear that this is an interim solution, and OpenJDK 6
will be removed for jessie.
Currently java bindings/packages are built for all architectures, however some
architectures still use gcj as the (only available) Java implementation, and
some OpenJDK zero ports are non-functional at this point, and Debian porters
usually don't care about that. So the architectures to drop java support would
be
kfreebsd-any, hurd-i386, mips, mipsel, s390, ia64
- kfreebsd may gain java 7 support at some time, however this shouldn't
be relied on yet.
- hurd never had openjdk support, and afaik, nobody is working on that.
- openjdk support for mips and mipsel is currently broken, with several
requests for help on debian-mips left unanswered.
- I fixed openjdk on s390 for the release, however this architecture is
time comsuming to maintain, and again no answers on debian-s390 asking
for help.
- same experience on ia64, however the zero ports seems to work there.
The list of java archs is a bit changing, and to avoid hardcoding this list into
every source package, I propose to something similiar like done for the gcj
architectures (/usr/share/gcj/debian_defaults). Let the packages be still
architecture any, and decide whether to build arch dependent packages on a make
macro java_archs.
Build dependencies would still need hard-coding of the architecture list, so
another idea would be to keep the default-{jre,jdk} packages on all
architectures and only use them if the architecture is found in java_archs.
Matthias
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5187bca6.3010...@debian.org
python3.3 build failure on kfreebsd and the hurd
python3.3 build failure on kfreebsd and the hurd, please could somebody have a look and propose a patch? thanks, Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50996763.3090...@debian.org
Re: Bug#686702: unblock: gcc-4.6/4.6.3-9
On 05.10.2012 09:59, Julien Cristau wrote: On Tue, Sep 4, 2012 at 23:10:16 +0200, Matthias Klose wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock this should go to wheezy, because - wrong code gen fixes - the ARM vector alignment fix - some fixes for cross builds please ignore the Linaro changes, these are not used for the Debian ARM builds. Unfortunately, 4.6.3-10 failed to build on kfreebsd-amd64 and mipsen, so this can't go to wheezy yet. Any idea what's going on there? disabled in -11 the libstdc++ testsuite for mips*, as already done in 4.7. the kfreebsd build failure is not reproducible on the porter box asdfasdf.debian.net, this pops up in various builds, same for the current gnat-4.6 upload. now building again manually, as already done with -9. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50715ce7.9000...@debian.org
Re: Bug#637236: FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998
On 07.10.2012 18:29, Steven Chamberlain wrote: Hi, The Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998, seen sometimes on kFreeBSD, seems to be here: [...] checked in both changes. will wait until -11 migrates, or if not, upload -12 to unstable. thanks, Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50721478.2050...@debian.org
binutils 2.23 branch build failure for kfreebsd
binutils 2.23 in experimental fails to build on kfreebsd for some time. please could some of the ports look at the build failures and submit patches upstream? thanks, Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50321861.20...@debian.org
python3.3 in experimental ftbfs on kfreebsd
Please could somebody look at the python3.3 build for kfreebsd, and provide the missing patches? thanks, Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fedbd3c.30...@debian.org
GCC 4.7 is now the default for x86 architectures
GCC 4.7 is now the default for x86 architectures for all frontends except the D frontends, including KFreeBSD and the Hurd. There are still some build failures which need to be addressed. Out of the ~350 bugs filed, more than the half are fixed, another quarter has patches available, and the remaining quarter isn't blocking any other 4.7 build failures. Many thanks to the patch submitters and NMUers, including Cyril Brulebois, Gregor Herrmann, Paul Tagliamonte for the fixes. This will add one more transition for x86 (libobjc3 - libobjc4), which needs starting with uploads of some GNUstep base packages. The D v2 frontend is likely to be updated to 4.7 before the freeze (no build dependencies). Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa7ffd8.9010...@debian.org
Re: GCC 4.7 is now the default for x86 architectures
On 07.05.2012 19:35, Thorsten Glaser wrote: Matthias Klose dixit: GCC 4.7 is now the default for x86 architectures for all frontends except the D frontends, including KFreeBSD and the Hurd. How are the plans for other architectures? I don't have plans to change any other architectures. If a port is not a release architectures (and port maintainers don't plan to make it a release architecture), people can change the default at any time from my point of view. As for gcc-4.7 in general: a friend (authoring an ObjC framework _and_ runtime) told me that it dropped support for an old method of doing things while not fulfilling the promise to get the new method of doing it (don’t exactly remember what it was, /msg js on freenode for details) fixed, with the effect that gobjc-4.7 is virtually useless/broken. This is hearsay, but ask him for details, and check them against reality. I didn't rely on hearsay, but did ask the GNUstep maintainers for feedback. Please join the Debian GNUstep package maintainers ML if you want to add something, or review the past discussion. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa80a89.8070...@debian.org
defaulting to GCC-4.7 for kfreebsd and the hurd?
Hi, I'm now planning to default to GCC 4.7 for amd64 and i386. Should kfreebsd and the hurd do change at the same time, or should these stay with 4.6? Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f9a9194.2020...@debian.org
Re: defaulting to GCC-4.7 for kfreebsd and the hurd?
On 27.04.2012 14:44, Samuel Thibault wrote: Matthias Klose, le Fri 27 Apr 2012 14:31:16 +0200, a écrit : I'm now planning to default to GCC 4.7 for amd64 and i386. Should kfreebsd and the hurd do change at the same time, or should these stay with 4.6? I have actually already commited the switch to gcc4.7 for the hurd package. I believe it is ok to switch to 4.7 in general. are you committed to forward and fix issues for all other archs? I can't say that from myself. I'll chat with the ARM porters, but didn't plan to do so for other ports. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f9a9a00.4060...@debian.org
Re: defaulting to GCC-4.7 for kfreebsd and the hurd?
On 27.04.2012 15:03, Steven Chamberlain wrote: On 27/04/12 13:31, Matthias Klose wrote: I'm now planning to default to GCC 4.7 for amd64 and i386. Should kfreebsd and the hurd do change at the same time, or should these stay with 4.6? In case it is relevant to this decision: gcc-4.6 has been failing to build on kfreebsd-* since the enable-gnu-unique-object configure option was enabled (from 4.6.3-2) : Error: symbol type gnu_unique_object is supported only by GNU targets Whereas gcc-4.7 has built okay since that option was disabled on kfreebsd-* and hurd-i386 (from 4.7.0~rc2-1). thanks, fixed in the vcs. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f9ab953.7090...@debian.org
Re: Bug#654783: python2.7: FTBFS(kfreebsd): testsuite hang
On 06.04.2012 04:03, Steven Chamberlain wrote: reopen 654783 debian-bsd@lists.debian.org notfixed 654783 python2.7/2.7.3~rc2-2 found 654783 python2.7/2.7.3~rc2-2 thanks Log of the latest kfreebsd build failure is: https://buildd.debian.org/status/fetch.php?pkg=python2.7arch=kfreebsd-amd64ver=2.7.3~rc2-2stamp=1333657799 I mentioned today that test_socket hangs, but only moments before this was uploaded to unstable. sorry, already had the binaries built :/ In the past few hours I've managed to reproduce a hang of test_io on kfreebsd-i386, so that is apparently still an issue (but not always). Also I've run into hangs of test_threading and test_gdb for the first time. test_threading has issues on other architectures as well. I tend to disable these too for kfreebsd-*. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7f3fee.5060...@debian.org
targeting GCC 4.7.0 as the wheezy default for some architectures
GCC-4.7 packages are now available in testing and unstable; thanks to Lucas' test rebuild, bug reports are now filed for these ~330 packages which fail to build with the new version [1]. Hints how to address the vast majority of these issues can be found at [2]. I'm planning to work on these issues (help is welcome) in April, and then decide at the of April to change the default for some architectures; input from port maintainers is welcome if and when to change the default for any other archs. The current rebuild was done on amd64 only, any other (maybe partial) rebuild test on other architectures is welcome. The Java and Go frontends already default to 4.7, the D frontend may be updated for 4.7 in time (currently unused, as all D packages are built using gdc-v1). As I understand Ludovic, the Ada frontend will stay with 4.6. GCC-4.4 will stay in wheezy (D v1 frontend, somehow broken gcj-4.6 on release architectures like sparc). GCC-4.5 should be removed before the freeze. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.7;users=debian-...@lists.debian.org [2] http://gcc.gnu.org/gcc-4.7/porting_to.html -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7bfdac.4040...@debian.org
Bug#654738: kfreebsd-8: non-standard gcc/g++ used for build (gcc-4.4)
Package: kfreebsd-8 Version: 8.2-15 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-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1riobx-0001lw...@ravel.debian.org
Bug#654739: kfreebsd-9: non-standard gcc/g++ used for build (gcc-4.4)
Package: kfreebsd-9 Version: 9.0~svn227451-7 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-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rioby-0001m2...@ravel.debian.org
please update patches / investigate build failures for gcc-4.7 snapshot builds
Please have a look at the gcc-4.7 package in experimental, update patches (hurd, kfreebsd, ARM is fixed in svn), and investigate the build failures (currently ia64, but more will appear). Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eee7d60.9000...@debian.org
gcc-4.6/gcj-4.6 build failures on kfreebsd-amd64 are back again
looks like bug #637236 is back again. is this a buildd issue again? can the package be built locally? Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ea99301.6060...@debian.org
Re: Bug#637236: FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998
On 08/19/2011 11:03 AM, Christoph Egger wrote: Hi! Christoph Eggerchrist...@debian.org writes: Matthias Klosed...@debian.org writes: afaik, this is a buildd issue. any comments? On 08/09/2011 08:44 PM, Ludovic Brenta wrote: From the buildd logs on kfreebsd-amd64[1]: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998 I got this error also when building gnat-4.6 on a different buildd[2], but not on asdfasdf.debian.net, the porter box, where the package builds fine. Could this error be specific to the two buildd machines? [1] https://buildd.debian.org/status/fetch.php?pkg=gcc-4.6arch=kfreebsd-amd64ver=4.6.1-6stamp=1312911887 [2] https://buildd.debian.org/status/fetch.php?pkg=gnat-4.6arch=kfreebsd-amd64ver=4.6.1-3stamp=1312911422 At least it happens reproducibly on both buildds. Let me see what happens if I build it locally. Hm locally it builds (untill something that looks like a race in the debian/rules part of install will recover that log later). And running the build on the same buildd that failed in the same chroot just by hand and not through buildd also gets way past the failure. Any suggestions on why it does break from any side welcome ;) gcc-4.6 4.6.1-9 failed again; please give it a manual try again. thanks, Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e648072.2050...@debian.org
please update and check the multiarch patches for gcc-4.5
A re-worked multiarch patch for gcc-4.5 is in the packaging repository, currently lacking support for the hurd and kfreebsd. Please update the support, as soon as possible, and check the implementation on mips*. Basically either MULTIARCH_DIRNAME or MULTILIB_OSDIRNAMES has to be set accordingly in gcc/config/*/t-something, maybe introducing new t-files. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e4d7f03.9010...@debian.org
Re: Bug#637236: FTBFS on kfreebsd-amd64: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998
afaik, this is a buildd issue. any comments? On 08/09/2011 08:44 PM, Ludovic Brenta wrote: Package: src:gcc-4.6 Version: 4.6.1-3 Severity: serious Tags: help From the buildd logs on kfreebsd-amd64[1]: gengtype: Internal error: abort in get_output_file_with_visibility, at gengtype.c:1998 I got this error also when building gnat-4.6 on a different buildd[2], but not on asdfasdf.debian.net, the porter box, where the package builds fine. Could this error be specific to the two buildd machines? [1] https://buildd.debian.org/status/fetch.php?pkg=gcc-4.6arch=kfreebsd-amd64ver=4.6.1-6stamp=1312911887 [2] https://buildd.debian.org/status/fetch.php?pkg=gnat-4.6arch=kfreebsd-amd64ver=4.6.1-3stamp=1312911422 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e4ad3fe.5020...@debian.org
Re: Bug#630101: gdc-4.4: FTBFS: tries to build 32bit executable on 64bit system
On 06/11/2011 12:04 AM, Christoph Egger wrote: If you have further questions please mail debian-bsd@lists.debian.org yes, please attach a patch. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df2c51f.4060...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 04/17/2011 09:33 PM, Adam D. Barratt wrote: On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). It looks like kfreebsd-* also made the switch and there's been a request to switch for mips and mipsel. Looking through the bug list for src:gcc-4.5, none of the open issues seem to be specific to the remaining release architectures which haven't switched yet - i.e. ia64, s390 and sparc. Are you aware of any issues which would preclude switching the default on those architectures? Has there been any discussion with the port maintainers regarding switching? At this point, pretty well after the GCC 4.6.0 release, I would like to avoid switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce maintenance efforts on the debian-gcc side, even before the multiarch changes go into unstable. I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. GCC 4.6 apparently will be used for the next Fedora and OpenSuse releases, and a test rebuild of Ubuntu natty doesn't look too bad (mostly adding new easily fixable C++ build failures). A test rebuild of the unstable archive is still outstanding, but these build failures will have to be fixed anyway. From my point of view it's important to expose GCC 4.6 early in the release cycle to fix issues like #617628 (which are issues in the packages itself) now. With GCC 4.6 comes one soname change, bumping the libobjc version from 2 to 3, which is not easily detachable from the GCC version change. However this change only affects GNUstep, which can be dealt with NMU's, or migration to a new GNUstep version. It's unlikely that GCC 4.5 will be released with wheezy, as the Debian Ada and D maintainers are already working on GCC 4.6 support. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6dea5.5010...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 04/26/2011 05:31 PM, Konstantinos Margaritis wrote: On 26 April 2011 18:03, Matthias Klosed...@debian.org wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. Could you include armhf in the list as well? yes, forgot about that. with GCC 4.6, armhf is built again from the 4.6 fsf branch, and lets us drop the GCC 4.5 Linaro variant. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db6eb11.2080...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 04/26/2011 09:28 PM, Kurt Roeckx wrote: On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote: On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote: I'll make GCC 4.6 the default after the release of GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and powerpc. If you do the switch, please also add mips and mipsel, that would avoid you to have to complain in two weeks that these architectures have not yet been switched. Is there a reason not to switch the remaining (release) arches (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too? I don't know, and I will not invest time to check. If you did check, and if you are confident to fix issues on these architectures, then please tell here. At least for other ports this seems to be possible (s390: Bastian Blank, kfreebsd-*: Aurelian, Petr). I assume you want to release with at least 4.6 on all arches as the default, so I see no point in waiting with switching if there are no known issues. I will not work on toolchain issues specific to these architectures for the wheezy release, so if nobody steps forward, then at least I will not change the default for these architectures. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db73b0c.4000...@debian.org
gcc-4.6 kfreebsd build failure
Apparently gcc-4.5 is not good enough as a bootstrap compiler for gcc-4.6. Please could somebody check/confirm that using gcc-4.4 as the bootstrap compiler works around the build failure? thanks, Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db2ab47.9010...@debian.org
Re: gcj-4.4-jdk misses jni_md.h on kfreebsd platform
reassign 621878 db5.1
thanks
you have to include both java_home/include and java_home/include/linux.
On 04/20/2011 07:20 AM, Ondřej Surý wrote:
Just a quick note, the difference in gcj version between successful and
unsuccessfull build is 4.4.5-9 vs 4.4.5-14
Ondřej Surý
On 20.4.2011, at 0:59, Ondřej Surýond...@sury.org wrote:
On Tue, Apr 19, 2011 at 23:34, Matthias Klosed...@debian.org wrote:
On 04/19/2011 11:11 PM, Ondřej Surý wrote:
reopen 621878
reassign 621878 gcj-4.4-jdk
retitle 621878 gcj-4.4-jdk misses jni_md.h on kfreebsd
affects 621878 +db4.6 db4.7 db4.8 db
thank you
Dear Debian GCC Team please look at http://bugs.debian.org/621878, it
looks like jni_md.h header is missing there which is causing FTBFSes
for dbX.Y packages.
You can find failed build logs here:
https://buildd.debian.org/status/fetch.php?pkg=dbarch=kfreebsd-i386ver=5.1.25-2stamp=1302733739
https://buildd.debian.org/status/fetch.php?pkg=dbarch=kfreebsd-amd64ver=5.1.25-2stamp=1302733541
is this a kfreebsd issue?
Version 5.1.25-1 built fine:
https://buildd.debian.org/status/fetch.php?pkg=dbarch=kfreebsd-amd64ver=5.1.25-1stamp=1297388366
Version 5.1.25-2 started to fail on kfreebsd-{amd64,amd32}. The buildd
failures on ia64, mips, s390 and sparc are of different nature.
The error from 5.1.25-2 build is:
libtool: compile: gcc -c -I. -I../src -I/usr/include/tcl8.5
-D_GNU_SOURCE -D_REENTRANT -I/usr/lib/jvm/default-java/include -Wall
-g -O2 -I/usr/lib/jvm/default-java/include -fno-strict-aliasing
../lang/java/libdb_java/db_java_wrap.c -fPIC -DPIC -o
.libs/db_java_wrap.o
In file included from ../lang/java/libdb_java/db_java_wrap.c:137:0:
/usr/lib/jvm/default-java/include/jni.h:52:20: fatal error: jni_md.h:
No such file or directory
The same line compiles with lots of warnings, but compiles. So
something must have changed on gcj side between the two builds which
broke it.
looks more like you are assuming that the default
version of gcc matches the one for gcj. please reassign back.
Could you please elaborate? Are you trying to say that calling:
gcc -c -I. -I../src -I/usr/include/tcl8.5 -D_GNU_SOURCE -D_REENTRANT
-I/usr/lib/jvm/default-java/include -Wall -g -O2
-I/usr/lib/jvm/default-java/include -fno-strict-aliasing
../lang/java/libdb_java/db_java_wrap.c -fPIC -DPIC -o .libs/db_java_wrap.o
is wrong when gcc is different version than gcj? Well the build log
say gcc-4.4 and gcj-4.4-*, so there should be nothing wrong.
O.
--
Ondřej Surýond...@sury.org
db_5.1.25-1..2.diff.gz
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4daeabd4.9060...@debian.org
Re: gcj-4.4-jdk misses jni_md.h on kfreebsd platform
On 04/19/2011 11:11 PM, Ondřej Surý wrote: reopen 621878 reassign 621878 gcj-4.4-jdk retitle 621878 gcj-4.4-jdk misses jni_md.h on kfreebsd affects 621878 +db4.6 db4.7 db4.8 db thank you Dear Debian GCC Team please look at http://bugs.debian.org/621878, it looks like jni_md.h header is missing there which is causing FTBFSes for dbX.Y packages. You can find failed build logs here: https://buildd.debian.org/status/fetch.php?pkg=dbarch=kfreebsd-i386ver=5.1.25-2stamp=1302733739 https://buildd.debian.org/status/fetch.php?pkg=dbarch=kfreebsd-amd64ver=5.1.25-2stamp=1302733541 is this a kfreebsd issue? looks more like you are assuming that the default version of gcc matches the one for gcj. please reassign back. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dadffdb.3070...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 02.03.2011 07:36, Konstantinos Margaritis wrote: On 2 March 2011 03:34, Matthias Klose d...@debian.org wrote: I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). As the maintainer file for the ports in GCC is a bit outdated, I'd like to ask which architectures should do the switch together with the four architectures mentioned above, and which not, and which ones should be better delayed, or dropped. Could you add armhf to the list? keeping armhf to build from the linaro branch? Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6e5293.8060...@debian.org
Re: GCC-4.5 as the default for (at least some) architectures
On 02.03.2011 17:54, Martin Guy wrote: On 2 March 2011 02:34, Matthias Klose d...@debian.org wrote: armel (although optimized for a different processor) Hi For which processor (/architecture) is it optimized, and do you mean optimized-for, or only-runs-on? I ask in case this would mean dumping all the armv4t systems that are using Debian armel. I didn't propose changing the minimum required processor for armel. I said that 4.5 looks ok, although I can only say that for another processor default (armv7-a). Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6e787c.9090...@debian.org
GCC-4.5 as the default for (at least some) architectures
I'll make gcc-4.5 the default for (at least some) architectures within the next two weeks before more transitions start. GCC-4.5 is already used as the default compiler for almost any other distribution, so there shouldn't be many surprises on at least the common architectures. About 50% of the build failures exposed by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel (although optimized for a different processor) and powerpc (some object files linked into shared libs had to be built as pic). As the maintainer file for the ports in GCC is a bit outdated, I'd like to ask which architectures should do the switch together with the four architectures mentioned above, and which not, and which ones should be better delayed, or dropped. Matthias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.5;users=debian-...@lists.debian.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6d9e89.8080...@debian.org
Re: Bug#615826: gcc-4.6: FTBFS on kfreebsd-*: os_dep.c:20:30: fatal error: linux/version.h: No such file or directory
severity 615826 important thanks On 28.02.2011 11:21, Cyril Brulebois wrote: Source: gcc-4.6 Version: 4.6-20110227-1 Severity: serious Justification: FTBFS User: debian-bsd@lists.debian.org Usertags: kfreebsd Hi, your package FTBFS on kfreebsd-* with: | /bin/bash ./libtool --tag=CC --mode=compile /build/buildd-gcc-4.6_4.6-20110227-1-kfreebsd-amd64-qdxe8p/gcc-4.6-4.6-20110227/build/./gcc/xgcc -B/build/buildd-gcc-4.6_4.6-20110227-1-kfreebsd-amd64-qdxe8p/gcc-4.6-4.6-20110227/build/./gcc/ -B/usr/x86_64-kfreebsd-gnu/bin/ -B/usr/x86_64-kfreebsd-gnu/lib/ -isystem /usr/x86_64-kfreebsd-gnu/include -isystem /usr/x86_64-kfreebsd-gnu/sys-include-DHAVE_CONFIG_H -I. -I../../../src/libgfortran -iquote../../../src/libgfortran/io -I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config -I../../../src/libgfortran/../libquadmath -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT set_exponent_r8.lo -MD -MP -MF .deps/set_exponent_r8.Tpo -c -o set_exponent_r8.lo `test -f '../../../src/libgfortran/generated/set_exponent_r8.c' || echo '../../../src/libgfortran/'`../../../ sr c/libgfortran/generated/set_exponent_r8.c | ../../../src/boehm-gc/os_dep.c:20:30: fatal error: linux/version.h: No such file or directory | compilation terminated. Full build logs: https://buildd.debian.org/status/package.php?p=gcc-4.6suite=experimental I'm x-d-cc-ing debian-bsd@. wasn't built before. It would better help to send a fix. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6b853c.4000...@debian.org
Re: Bug#615826: gcc-4.6: FTBFS on kfreebsd-*: os_dep.c:20:30: fatal error: linux/version.h: No such file or directory
On 28.02.2011 12:49, Cyril Brulebois wrote: Matthias Klose d...@debian.org (28/02/2011): wasn't built before. strictly speaking, yes. But since we're talking about a gcc package, that *could* be considered as a regression from previous versions… But what a hairy reasoning! maybe, but then, it's an indication that the port is not maintained. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6b8c46.1050...@debian.org
Re: DSO linking changes for wheezy
On 16.11.2010 10:42, Roger Leigh wrote: On Tue, Nov 16, 2010 at 01:14:09AM +0100, Matthias Klose wrote: On 14.11.2010 13:19, Julien Cristau wrote: On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. I think it is. Besides fixing potential bugs, else you'll never be able to use gold as the linker. See the already filed bug reports. This change is one I can agree with on technical grounds, though it will cause a great deal of pain in the short term. Have we got any estimates on exactly how much breakage will result before the change gets made? see http://wiki.debian.org/ToolChain/DSOLinking#Furtherinformation referenced in the first email of this thread. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce2c7c5.5040...@debian.org
Re: DSO linking changes for wheezy
On 15.11.2010 07:16, Roland McGrath wrote: mattst88 airlied_, does Fedora use --as-needed by default? Fedora 14 too? airlied_ mattst88: yes The naming of the options makes people easily confused. --no-add-needed is the only option Fedora's gcc passes. yes, OpenSuse is using --as-needed, but not --no-add-needed. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1acb3.1090...@debian.org
Re: DSO linking changes for wheezy
On 14.11.2010 16:06, Roger Leigh wrote: While I understand the rationale for --no-copy-dt-needed-entries for preventing encapsulation violations via indirect linking, I don't agree with the use of --as-needed *at all*. If a library has been explicitly linked in, it shouldn't be removed. This is an issue for fixing in individual packages, not in the toolchain. I can understand on using it on a per-package basis, but not in the actual toolchain defaults. The compiler and linker *should not be second-guessing the user*. This can break perfectly legitimate code making use of ELF constructors and other features which won't be picked out just by looking at symbol usage. People have been claiming that constructors or init section are a possible problem. I have yet to see an example where it breaks. It's not a very widely used feature. I'm sure it's trivial to make such a test case. Portable software tends not to make use of ELF- specific features like this, but that's not an excuse for breaking perfectly legitimate code. But whether or not there are real life examples, --as-needed is *fundamentally wrong*. It's deliberately *not doing what the user requested*, and to make that misfeature the system-wide default would be entirely inappropriate. If a package wishes to make use of such a feature after understanding the implications, then they are free to do so. But to make it the default--I don't think that's a technically sound decision. maybe, and fix it in N - ~100 packages? Or fix the ~100 packages? The point of injection is for discussion. I would prefer having this set in dpkg-buildflags, and then disabled by these ~100 packages. Note that this is probably the same like modifying the N - ~100 packages, as almost no package respects dpkg-buildflags yet. Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1ae11.2010...@debian.org
Re: DSO linking changes for wheezy
On 14.11.2010 13:19, Julien Cristau wrote: On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. I think it is. Besides fixing potential bugs, else you'll never be able to use gold as the linker. See the already filed bug reports. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce1ccd1.8010...@debian.org
