Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Breno Leitao]

Hi Niels,

On 06/27/2018 05:03 PM, Niels Thykier wrote:

> 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)
> 
>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>in GCC
>(Raised by the GCC maintainer; carried over from stretch)

I am not sure if ppc64el should be here. GCC does have a good ppc64el support
and this is being maintained by some IBM folks.

Can you elaborate a bit more on this concern for ppc64el?

Bug#856809: (no subject)

[Breno Leitao]

There is an upstream fix for this problem, targeting both gcc trunk and GCC-6:

On GCC-6 branch it is id 246509


r246509 | meissner | 2017-03-27 16:35:35 -0300 (Mon, 27 Mar 2017) | 42 lines

[gcc]
2017-03-27  Michael Meissner  

Back port from trunk
2017-03-27  Michael Meissner  

PR target/78543
* config/rs6000/rs6000.md (bswaphi2_extenddi): Combine bswap
HImode and SImode with zero extend to DImode to one insn.
(bswap2_extenddi): Likewise.
(bswapsi2_extenddi): Likewise.
(bswaphi2_extendsi): Likewise.
(bswaphi2): Combine bswap HImode and SImode into one insn.
Separate memory insns from swapping register.
(bswapsi2): Likewise.
(bswap2): Likewise.
(bswaphi2_internal): Delete, no longer used.
(bswapsi2_internal): Likewise.
(bswap2_load): Split bswap HImode/SImode into separate load,
store, and gpr<-gpr swap insns.
(bswap2_store): Likewise.
(bswaphi2_reg): Register only splitter, combine with the splitter.
(bswaphi2 splitter): Likewise.
(bswapsi2_reg): Likewise.
(bswapsi2 splitter): Likewise.
(bswapdi2): If we have the LDBRX and STDBRX instructions, split
the insns into load, store, and register/register insns.
(bswapdi2_ldbrx): Likewise.
(bswapdi2_load): Likewise.
(bswapdi2_store): Likewise.
(bswapdi2_reg): Likewise.

Bug#845751: yadifa FTBFS on ppc64el: internal compiler error: in push_reload, at reload.c:1349

[Breno Leitao]

Hello,

On 11/26/2016 10:57 AM, Adrian Bunk wrote:
> Source: yadifa
> Version: 2.2.2-1
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=yadifa=ppc64el=2.2.2-1=1480164499
> 
> ...
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./include/dnscore -Wdate-time 
> -D_FORTIFY_SOURCE=2 -DNDEBUG -g -DDNSCORE_BUILD -D_THREAD_SAFE -D_REENTRANT 
> -D_FILE_OFFSET_BITS=64 -I/«PKGBUILDDIR»/lib/dnscore 
> -I/«PKGBUILDDIR»/lib/dnscore/include -fno-ident -ansi -pedantic -Wall 
> -Wno-unknown-pragmas -Werror=missing-field-initializers -std=gnu99 
> -mtune=native -DUSES_GCC -DPREFIX=\"/usr\" -DSYSCONFDIR=\"/etc\" 
> -DLOCALSTATEDIR=\"/var\" -DDATAROOTDIR=\"/usr/share\" 
> -DDATADIR=\"/usr/share\" -DLOCALEDIR=\"/usr/share/locale\" 
> -DLOGDIR=\"/var/log/yadifa\" -DTCLDIR=\"\" -DNDEBUG -O3 -g -DCMR -c 
> src/message_print_format_dig.c -o src/message_print_format_dig.o
> src/message_print_format_dig.c: In function 'message_print_format_dig_buffer':
> src/message_print_format_dig.c:304:1: internal compiler error: in 
> push_reload, at reload.c:1349
>  }
>  ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> Preprocessed source stored into /tmp/ccy8l7aF.out file, please attach this to 
> your bugreport.

This is a known issue on GCC as you can see at:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543

I just created a patch to fix this FTBFS on Debian. It is attached to this 
email.

diff -Nru yadifa-2.2.2/debian/changelog yadifa-2.2.2/debian/changelog
--- yadifa-2.2.2/debian/changelog	2016-11-08 06:21:48.0 -0500
+++ yadifa-2.2.2/debian/changelog	2016-11-28 15:12:29.0 -0500
@@ -1,3 +1,9 @@
+yadifa (2.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Avoid compiling with O3 on ppc64el due to a known bug
+
+ -- Breno Leitao <breno.lei...@gmail.com>  Mon, 28 Nov 2016 15:12:29 -0500
+
 yadifa (2.2.2-1) unstable; urgency=medium
 
   * New upstream version 2.2.2 (Closes: #828612)
diff -Nru yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch
--- yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch	1969-12-31 19:00:00.0 -0500
+++ yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch	2016-11-28 15:12:29.0 -0500
@@ -0,0 +1,27 @@
+--- a/m4/eurid.m4	2016-11-08 05:56:43.140600104 -0500
 b/m4/eurid.m4	2016-11-28 15:01:27.0 -0500
+@@ -298,6 +298,9 @@ case "$(uname -m)" in
+ 		CPU_UNKNOWN=0
+ 		cpu_intel_compatible=1
+ 		;;
++	ppc64le)
++		cpu_power_compatible=1
++		;;
+ 	*)
+ 		;;
+ esac
+@@ -625,7 +628,13 @@ then
+ 			CCOPTIMISATIONFLAGS=-O3
+ 		fi
+ 	fi
+-
++ 
++	dnl Move to O2 due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543
++	if [[ $cpu_power_compatible -eq 1 ]]
++	then
++	CCOPTIMISATIONFLAGS=-O2
++	fi
++	
+ AM_CONDITIONAL([USES_ICC], [false])
+ AM_CONDITIONAL([USES_GCC], [true])
+ AM_CONDITIONAL([USES_CLANG], [false])
diff -Nru yadifa-2.2.2/debian/patches/series yadifa-2.2.2/debian/patches/series
--- yadifa-2.2.2/debian/patches/series	2016-11-08 06:21:48.0 -0500
+++ yadifa-2.2.2/debian/patches/series	2016-11-28 15:12:20.0 -0500
@@ -5,3 +5,4 @@
 fix-yadifad-spelling.patch
 fix-yadifarc-manpage.patch
 do-not-use-or-define-the-compile-date.patch
+fix-ppc64el_ftbfs.patch

Bug#806160: gcc-5: Don't pass --oformat to ld

[Breno Leitao]

Package: gcc-5
Version: 5.2.1-22
Severity: important
Tags: patch

Hello,

There is a cross compilation issue on the wild[1] that is causing kernel kbuild
to fail when cross building on powerpc. The host machine using Debian.  I would
like to know if it is still possible to include this fix on gcc version 5.2.1.

The fix could be found at
https://github.com/gcc-mirror/gcc/commit/0012c439035bc1d5843e5c8e72c6c5fad357d389

[1] https://lkml.org/lkml/2015/11/21/165

Thank you,
Breno
-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: ppc64el (ppc64le)

Kernel: Linux 4.2.0-1-powerpc64le (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-5 depends on:
ii  binutils  2.25.1-7
ii  cpp-5 5.2.1-22
ii  gcc-5-base5.2.1-22
ii  libc6 2.19-22
ii  libcc1-0  5.2.1-22
ii  libgcc-5-dev  5.2.1-22
ii  libgcc1   1:5.2.1-22
ii  libgmp10  2:6.0.0+dfsg-7
ii  libisl13  0.14-2
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.3-1
ii  libstdc++65.2.1-22
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gcc-5 recommends:
ii  libc6-dev  2.19-22

Versions of packages gcc-5 suggests:
pn  gcc-5-doc
pn  gcc-5-locales
pn  libasan2-dbg 
pn  libatomic1-dbg   
pn  libcilkrts5-dbg  
pn  libgcc1-dbg  
pn  libgomp1-dbg 
pn  libitm1-dbg  
pn  liblsan0-dbg 
pn  libmpx0-dbg  
pn  libquadmath-dbg  
pn  libtsan0-dbg 
pn  libubsan0-dbg

-- no debconf information

Bug#755959: ppl: [ftbfs] run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4

[Breno Leitao]

Source: ppl
Version: 1.1-2
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el
User: debian-de...@lists.debian.org
Usertags: autoreconf

Dear Maintainer,

Currently this package FTBFS when compiled in new architectures (as ppc64el)
that is not supported on the outdated package autotools files, mainly because
it fails to understand that the new architectures has support for shared
libraries, as shown below: 

dh_install -s --sourcedir=debian/tmp
dh_install: libppl13 missing files (usr/lib/*/libppl.so.*), aborting
make: *** [binary-arch] Error 255
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
status 2

The full log could be found at 
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/ppl_1.1-2_ppc64el.build

I created this patch that call autoreconf to updates the autotool files during
the build, as suggest by the following wiki:

https://wiki.debian.org/qa.debian.org/FTBFS#A2014-01-21_using_dh-autoreconf_during_the_build

I tested it on ppc64el and it worked.

Thank you,
Breno
Index: ppl-1.1/debian/control
===
--- ppl-1.1.orig/debian/control
+++ ppl-1.1/debian/control
@@ -5,7 +5,7 @@ Maintainer: Debian GCC Maintainers debi
 Uploaders: Michael Tautschnig m...@debian.org, Arthur Loiret aloi...@debian.org, Matthias Klose d...@debian.org
 Standards-Version: 3.9.5
 Build-Depends: debhelper (= 6.0.7~), libgmp-dev, autoconf, libtool, autotools-dev, swi-prolog [!hurd-i386], chrpath,
- libncurses5-dev, libncursesw5-dev
+ libncurses5-dev, libncursesw5-dev, dh-autoreconf
 Build-Depends-Indep: doxygen-latex, graphviz, poppler-utils, ghostscript, texlive-math-extra
 Homepage: http://www.cs.unipr.it/ppl/
 
Index: ppl-1.1/debian/rules
===
--- ppl-1.1.orig/debian/rules
+++ ppl-1.1/debian/rules
@@ -73,8 +73,7 @@ endif
 configure: configure-stamp
 configure-stamp:
 	dh_testdir
-	cp -f /usr/share/misc/config.sub config.sub
-	cp -f /usr/share/misc/config.guess config.guess
+	dh_autoreconf
 	./configure $(confflags) \
 		--prefix=/usr \
 		--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
@@ -114,6 +113,7 @@ build-indep-stamp: configure-stamp
 clean:
 	dh_testdir
 	dh_testroot
+	dh_autoreconf_clean
 	rm -f configure-stamp build-stamp
 	rm -f build-arch-stamp build-indep-stamp
 	[ ! -e Makefile ] || $(MAKE) distclean

GCC version 4.8.3 on Debian

[Breno Leitao]

HI GCC maintainers,

I found that GCC 4.8.3 was released today on GNU website. I am willing to use 
this
newer version on some of my machines.
I am curious on how long it usually takes, on average, to have a newer GCC 
release
on Debian, after it was officially released.

Thanks
Breno


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525ed974.7080...@br.ibm.com