Re: Bug#920286: gcc-8: Missing conflict/break with binutils-x86-64-linux-gnu:i386 can lead to broken compiler

2019-03-19 Thread Ben Hutchings
On Tue, 2019-03-19 at 15:41 +0100, Helmut Grohne wrote:
[...]
> src:linux Build-Depends binutils-. The binutils patch will
> render these dependencies cross-unsatisfiable. They will need to be
> switched to binutils-for-host or annotated with :any (after checking
> that it doesn't use plugins). Maintainers Cced.

We only do that for hppa, as the standard gcc-8 & binutils packages
only support 32-bit code and we need to build 64-bit kernels there.  We
don't use plugins for binutils.

Ben.

> So the attached patch will break cross building of gcc and linux.  It
> won't break any native stuff and it'll fix the bug at hand.
> 
> Helmut
-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.




signature.asc
Description: This is a digitally signed message part


Bug#925040: gcc-8 FTCBFS: builds idgen.c with the wrong compiler

2019-03-19 Thread Helmut Grohne
Source: gcc-8
Version: 8.3.0-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

gcc-8 fails to cross build from source.

http://crossqa.subdivi.de/build/gcc-8_8.3.0-2_ppc64el_20190301030546.log
| powerpc64le-linux-gnu-g++-8 -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-DHAVE_CONFIG_H -I. -Id -I../../src/gcc -I../../src/gcc/d 
-I../../src/gcc/../include -I../../src/gcc/../libcpp/include 
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd 
-I../libdecnumber -I../../src/gcc/../libbacktrace -o d/idgen.dmdgen.o -MT 
d/idgen.dmdgen.o -MMD -MP -MF d/.deps/idgen.dmdgen.TPo -I../../src/gcc/d 
-I../../src/gcc/d/dfrontend -Id ../../src/gcc/d/dfrontend/idgen.c
| g++-o d/idgen d/idgen.dmdgen.o
| /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21)
| /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21)
| /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21)
| /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21)
| /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21)
| /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21)
| /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21)
| /usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 21)
| /usr/bin/ld: d/idgen.dmdgen.o: error adding symbols: file in wrong format
| collect2: error: ld returned 1 exit status
| make[4]: *** [../../src/gcc/d/Make-lang.in:312: d/idgen] Error 1
| make[4]: Leaving directory '/<>/build/gcc'
| make[3]: *** [Makefile:4305: all-gcc] Error 2
| make[3]: Leaving directory '/<>/build'
| make[2]: *** [Makefile:907: all] Error 2
| make[2]: Leaving directory '/<>/build'

It uses the host architecture compiler to compile idgen.c and then tries
to link it with the build architecture compiler. It really wants to run
idgen, so using the build architecture compiler is correct. The attached
patch fixes that and makes gcc-8 cross buildable. Please consider
applying it.

Helmut
--- gcc-8-8.2.0.orig/src/gcc/d/Make-lang.in
+++ gcc-8-8.2.0/src/gcc/d/Make-lang.in
@@ -315,7 +315,7 @@
 	+$(LINKER_FOR_BUILD) $(BUILD_LINKER_FLAGS) $(BUILD_LDFLAGS) -o $@ $^
 
 d/idgen.dmdgen.o: d/dfrontend/idgen.c
-	$(filter-out -fprofile-%,$(DMD_COMPILE)) $(D_INCLUDES) $<
+	$(filter-out -fprofile-%,$(DMDGEN_COMPILE)) $(D_INCLUDES) $<
 	$(POSTCOMPILE)
 
 d/impcnvgen.dmdgen.o: $(srcdir)/d/dfrontend/impcnvgen.c


Bug#920286: gcc-8: Missing conflict/break with binutils-x86-64-linux-gnu:i386 can lead to broken compiler

2019-03-19 Thread Helmut Grohne
On Thu, Jan 24, 2019 at 04:38:19PM +0100, Helmut Grohne wrote:
> Ultimately, this means that marking binutils- M-A:foreign was
> wrong. It means that binutils plays the same role as ruby, perl, python
> and even make: you can load shared objects into it, but much of the time
> you don't. All of the other examples are M-A:allowed, so I guess
> binutils- needs to become M-A:allowed as well. Given that gcc
> Depends on binutils, binutils is M-A:no, and binutils Depends:
> binutils- without :any, the switch from M-A:foreign to
> M-A:allowed should fix this this bug, but at the same time it would
> break a fair number of use cases. We specifically have binutils-for-host
> to allow using foreign binutils. Likely binutils-for-host should
> Depends: binutils-:any then. On the flip side, that means that
> whenever you need plugins, you cannot use binutils-for-host.
> 
> Now marking anything M-A:allowed is basically irreversible, because
> people are going to use :any and all those deps break when removing
> M-A:allowed. Therefore we should think hard about whether this is the
> right route. I've added debian-cross@l.d.o to Cc to elicit some
> feedback.

You can find the patch for binutils attached. binutils- will
become Multi-Arch: allowed. With this patch applied there are the
following ways to depend on binutils:

 A Source package.
   A.A You want binutils for the host architecture -> binutils-for-host
   A.A You want binutils for the build architecture -> binutils-for-build
 B Binary package of architecture $ARCH.
   B.A You want binutils targeting the $ARCH.
 B.A.A Your package contains a plugin to load into binutils ->
   binutils-$ARCH
 B.A.B No plugin -> binutils-$ARCH:any
   B.B You want binutils targeting some executable architecture.
 B.B.A Your package contains a plugin to load into binutils ->
   binutils
 B.B.B No plugin -> binutils-for-build

In #895251, I requested that gcc use triplet-prefixed tools to allow
coinstalling binutils. It also made the architecture of binutils opaque
(which is what this bug is about). After causing repeated problems, the
relevant change was finally reverted via #915194. Now gcc uses
unprefixed tools again. But it still prefers prefixed tools in
/usr/ (which is what this bug is about). We'll should change
that using triplet-prefixed tools explicitly at some point.  gcc-8
presently Depends on "binutils". gcc-8- will have to Depends
binutils- without a :any. With the patch, binutils will Depends:
binutils- without :any, so using gcc-8:amd64 with
binutils-x86-64-linux-gnu:i386 will no longer be possible. So on the gcc
side, the attached patch will work.

src:arch-test uses binutils-, but it is Architecure: all, so it
pretty much doesn't matter whether the dependencies are annotated or
not.

src:cross-toolchain-base{,-port} conflicts with a number of
binutils-. That will continue to work.

src:gcc-8-cross (and similar packages) Build-Depends binutils-.
The binutils patch will render these dependencies cross-unsatisfiable.
They will need to be annotated :any or switched to binutils-for-host if
we want to cross build gcc-8-cross. Matthias, will you handle these?

src:linux Build-Depends binutils-. The binutils patch will
render these dependencies cross-unsatisfiable. They will need to be
switched to binutils-for-host or annotated with :any (after checking
that it doesn't use plugins). Maintainers Cced.

So the attached patch will break cross building of gcc and linux.  It
won't break any native stuff and it'll fix the bug at hand.

Helmut
diff --minimal -Nru binutils-2.31.1/debian/changelog 
binutils-2.31.1/debian/changelog
--- binutils-2.31.1/debian/changelog2019-02-27 22:30:21.0 +0100
+++ binutils-2.31.1/debian/changelog2019-03-19 14:25:35.0 +0100
@@ -1,3 +1,13 @@
+binutils (2.31.1-15.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+
+  * Demote binutils- from Multi-Arch: foreign to Multi-Arch: allowed.
+(Closes: #920286)
+  * Let binutil-for-host Depends: binutils-:any.
+
+ -- Helmut Grohne   Tue, 19 Mar 2019 14:25:35 +0100
+
 binutils (2.31.1-15) unstable; urgency=high
 
   * Fix PR ld/24276, taken from the trunk. Closes: #923246.
diff --minimal -Nru binutils-2.31.1/debian/control 
binutils-2.31.1/debian/control
--- binutils-2.31.1/debian/control  2019-02-19 13:39:31.0 +0100
+++ binutils-2.31.1/debian/control  2019-03-19 14:25:22.0 +0100
@@ -34,7 +34,7 @@
 
 Package: binutils-for-host
 Architecture: any
-Depends: ${binutils:native} (>= ${binutils:minver}),
+Depends: ${binutils:native}:any (>= ${binutils:minver}),
   binutils-common (= ${binary:Version}),
 Multi-Arch: same
 Description: GNU assembler, linker and binary utilities for the host 
architecture
@@ -192,7 +192,7 @@
 Package: binutils-x86-64-linux-gnu
 Priority: optional
 Architecture: amd64 arm64 i386 ppc64el x32
-Multi-Arch: foreign
+Multi-Arch: allowed
 Depends: binutils-common (= ${binary:Version}),
   

Twój Sklep firmowy na PrestaShop

2019-03-19 Thread Twój Sklep Internetowy

Dzień dobry, 

budowanie *SKLEPÓW* internetowych w oparciu o 
*PrestaShop* to nasz pasja.

 Od lat z powodzeniem realizujemy projekty dla 
grona zadowolonych klientów. 

 Jeśli chcecie Państwo otrzymać niezobowiązującą 
propozycję na ten temat, uprzejmie proszę o odpowiedź na tego maila, wysyłając 
słowo*TAK.*

Z pozdrowieniami,
Dominik Raczek