Broken gcc dependencies #3650

marmarek · Mar 3, 2018

Qubes OS version:

R4.0

Steps to reproduce the behavior:

sudo qubes-dom0-update --enablerepo=qubes*testing

Expected behavior:

Install updates, don't complain about dependencies.

Actual behavior:

Dependencies resolved.
========================================================================================
 Package        Arch          Version                    Repository                Size
========================================================================================
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 cpp            x86_64        6.4.1-1.qubes1.fc25        qubes-dom0-cached        9.0 M
 libgomp        x86_64        6.4.1-1.qubes1.fc25        qubes-dom0-cached        197 k

Transaction Summary
========================================================================================
Skip  2 Packages

General notes:

This is continuation of discussion here and here

Since the problem applies not only to qubes-builder (where we can employ some workarounds), we need a better solution.

@HW42 What about building i686 gcc? Can we cross compile it using the same environment, from the same repository/spec? Do you know how upstream handle it?

marmarek · Mar 3, 2018

@HW42 What about building i686 gcc? Can we cross compile it using the same environment, from the same repository/spec? Do you know how upstream handle it?

@HW42 What about building i686 gcc? Can we cross compile it using the same environment, from the same repository/spec?

A simple setarch i686 rpmbuild --target=i686 failed with errors in some headers. But maybe just some missing dependencies.

Do you know how upstream handle it?

I guess they just have real i686 builders (probably running ob x86_64 capable hardware).

Anyway I looked at the libgcc content:

--- libgcc-6.4.1-1.fc25.x86_64
+++ libgcc-6.4.1-1.qubes1.fc25.x86_64
├── lib64
│ ├── libgcc_s-6.4.1-20170727.so.1
│ │ ├── readelf --wide --notes {}
│ │ │ @@ -1,11 +1,11 @@
│ │ │  
│ │ │  Displaying notes found in: .note.gnu.build-id
│ │ │    Owner                 Data size	Description
│ │ │ -  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)	    Build ID: 4523a29e2c5d4c4ae5cc4ffec27ad8c7cfce310b
│ │ │ +  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)	    Build ID: 16703f6d2d70b618fc62894c76ed4ec8d396be0d
│ │ │  
│ │ │  Displaying notes found in: .note.stapsdt
│ │ │    Owner                 Data size	Description
│ │ │    stapsdt              0x00000034	NT_STAPSDT (SystemTap probe descriptors)	    Provider: libgcc
│ │ │      Name: unwind
│ │ │      Location: 0x0000000000010190, Base: 0x0000000000013354, Semaphore: 0x0000000000000000
│ │ │      Arguments: 8@%rdi 8@%rsi
│ │ ├── readelf --wide --decompress --hex-dump=.gnu_debuglink {}
│ │ │ @@ -1,6 +1,6 @@
│ │ │  
│ │ │  Hex dump of section '.gnu_debuglink':
│ │ │    0x00000000 6c696267 63635f73 2d362e34 2e312d32 libgcc_s-6.4.1-2
│ │ │    0x00000010 30313730 3732372e 736f2e31 2e646562 0170727.so.1.deb
│ │ │ -  0x00000020 75670000 327915fb                   ug..2y..
│ │ │ +  0x00000020 75670000 8baf39f8                   ug....9.

No content change. So we can just use Fedora's libgcc and be done with it. See PR QubesOS/qubes-gcc#1. We can reconsider building for i686 should the need arise for other reasons.

HW42 · Mar 3, 2018

@HW42 What about building i686 gcc? Can we cross compile it using the same environment, from the same repository/spec?

A simple setarch i686 rpmbuild --target=i686 failed with errors in some headers. But maybe just some missing dependencies.

Do you know how upstream handle it?

I guess they just have real i686 builders (probably running ob x86_64 capable hardware).

Anyway I looked at the libgcc content:

--- libgcc-6.4.1-1.fc25.x86_64
+++ libgcc-6.4.1-1.qubes1.fc25.x86_64
├── lib64
│ ├── libgcc_s-6.4.1-20170727.so.1
│ │ ├── readelf --wide --notes {}
│ │ │ @@ -1,11 +1,11 @@
│ │ │  
│ │ │  Displaying notes found in: .note.gnu.build-id
│ │ │    Owner                 Data size	Description
│ │ │ -  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)	    Build ID: 4523a29e2c5d4c4ae5cc4ffec27ad8c7cfce310b
│ │ │ +  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)	    Build ID: 16703f6d2d70b618fc62894c76ed4ec8d396be0d
│ │ │  
│ │ │  Displaying notes found in: .note.stapsdt
│ │ │    Owner                 Data size	Description
│ │ │    stapsdt              0x00000034	NT_STAPSDT (SystemTap probe descriptors)	    Provider: libgcc
│ │ │      Name: unwind
│ │ │      Location: 0x0000000000010190, Base: 0x0000000000013354, Semaphore: 0x0000000000000000
│ │ │      Arguments: 8@%rdi 8@%rsi
│ │ ├── readelf --wide --decompress --hex-dump=.gnu_debuglink {}
│ │ │ @@ -1,6 +1,6 @@
│ │ │  
│ │ │  Hex dump of section '.gnu_debuglink':
│ │ │    0x00000000 6c696267 63635f73 2d362e34 2e312d32 libgcc_s-6.4.1-2
│ │ │    0x00000010 30313730 3732372e 736f2e31 2e646562 0170727.so.1.deb
│ │ │ -  0x00000020 75670000 327915fb                   ug..2y..
│ │ │ +  0x00000020 75670000 8baf39f8                   ug....9.

No content change. So we can just use Fedora's libgcc and be done with it. See PR QubesOS/qubes-gcc#1. We can reconsider building for i686 should the need arise for other reasons.

Ok, that worked. There is still "broken" libgcc-6.4.1-1.qubes1.fc25.x86_64 package in testing repository, but can be safely ignored since nothing depends on it. I'll remove it from there.

marmarek · Mar 4, 2018

Ok, that worked. There is still "broken" libgcc-6.4.1-1.qubes1.fc25.x86_64 package in testing repository, but can be safely ignored since nothing depends on it. I'll remove it from there.

@andrewdavidwong / @marmarek Please reopen; based on testing described further in #3707 and a couple mailing list comments this does not appear to be resolved in qubes-builder although I see QubesOS/updates-status#442 is in stable.

Did a git pull in qubes-builder, followed by make dist-clean and rerunning ./setup. After many hours of gcc building, this is the output:

make[1]: Entering directory '/home/user/qubes-builder'
sudo chroot /home/user/qubes-builder/chroot-fc25 dnf install -y gcc-6.4.1-1.qubes1.fc25.x86_64 libgcc.x86_64
Qubes OS Builder Repository                      19 kB/s | 257  B     00:00    
No package gcc-6.4.1-1.qubes1.fc25.x86_64 available.
Package libgcc-6.4.1-1.fc25.x86_64 is already installed, skipping.
Error: Unable to find a match.
make[1]: *** [qubes-src/vmm-xen/Makefile.builder:27: workaround-gcc-upgrade-fc25] Error 1
make[1]: Leaving directory '/home/user/qubes-builder'
make: *** [Makefile:224: vmm-xen-dom0] Error 1

awokd · Mar 17, 2018

@andrewdavidwong / @marmarek Please reopen; based on testing described further in #3707 and a couple mailing list comments this does not appear to be resolved in qubes-builder although I see QubesOS/updates-status#442 is in stable.

Did a git pull in qubes-builder, followed by make dist-clean and rerunning ./setup. After many hours of gcc building, this is the output:

make[1]: Entering directory '/home/user/qubes-builder'
sudo chroot /home/user/qubes-builder/chroot-fc25 dnf install -y gcc-6.4.1-1.qubes1.fc25.x86_64 libgcc.x86_64
Qubes OS Builder Repository                      19 kB/s | 257  B     00:00    
No package gcc-6.4.1-1.qubes1.fc25.x86_64 available.
Package libgcc-6.4.1-1.fc25.x86_64 is already installed, skipping.
Error: Unable to find a match.
make[1]: *** [qubes-src/vmm-xen/Makefile.builder:27: workaround-gcc-upgrade-fc25] Error 1
make[1]: Leaving directory '/home/user/qubes-builder'
make: *** [Makefile:224: vmm-xen-dom0] Error 1

Verified my qubes-src/gcc/gcc.spec appears to have both commits applied:

Summary: Various compilers (C, C++, Objective-C, Java, ...)
Name: gcc
Version: %{gcc_version}
Release: %{gcc_release}.qubes2%{?dist}
%global release_non_qubes %{gcc_release}%{?dist}
# libgcc, libgfortran, libgomp, libstdc++ and crtstuff have
# GCC Runtime Exception.

awokd · Mar 17, 2018

Verified my qubes-src/gcc/gcc.spec appears to have both commits applied:

Summary: Various compilers (C, C++, Objective-C, Java, ...)
Name: gcc
Version: %{gcc_version}
Release: %{gcc_release}.qubes2%{?dist}
%global release_non_qubes %{gcc_release}%{?dist}
# libgcc, libgfortran, libgomp, libstdc++ and crtstuff have
# GCC Runtime Exception.

Looks like QubesOS/qubes-vmm-xen@b79f692 needs to be reverted. @awokd can you test it?

marmarek · Mar 17, 2018

Looks like QubesOS/qubes-vmm-xen@b79f692 needs to be reverted. @awokd can you test it?

Yes, definitely. Is there a faster way that doesn't involve the 12 hour GCC rebuild?

awokd · Mar 17, 2018

Yes, definitely. Is there a faster way that doesn't involve the 12 hour GCC rebuild?

You don't need to rebuild gcc, just xen.

marmarek · Mar 17, 2018

You don't need to rebuild gcc, just xen.

Backed out QubesOS/qubes-vmm-xen@b79f692 by hand, and make vmm-xen is now building instead of failing immediately. I'll kick off a full make qubes after this completes to make sure the rest of the process is good too, but that was probably it. Thanks!

awokd · Mar 17, 2018

Backed out QubesOS/qubes-vmm-xen@b79f692 by hand, and make vmm-xen is now building instead of failing immediately. I'll kick off a full make qubes after this completes to make sure the rest of the process is good too, but that was probably it. Thanks!

Build and ISO completed successfully. Needed to specify WHONIX_TBB_VERSION as current is newer than template's default setting- will document separately.

awokd · Mar 19, 2018

Build and ISO completed successfully. Needed to specify WHONIX_TBB_VERSION as current is newer than template's default setting- will document separately.

Thanks!

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

marmarek · Mar 19, 2018

Thanks!

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

Automated announcement from builder-github

The package xen_4.8.3-4+deb10u1 has been pushed to the r4.0 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing buster-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

QubesOS/qubes-issues

Join GitHub today

Broken gcc dependencies #3650

Comments

marmarek commented Mar 3, 2018

Qubes OS version:

Steps to reproduce the behavior:

Expected behavior:

Actual behavior:

General notes:

marmarek added bug C: other labels Mar 3, 2018

marmarek added this to the Release 4.0 milestone Mar 3, 2018

This comment has been minimized.

marmarek commented Mar 3, 2018

This comment has been minimized.

HW42 commented Mar 3, 2018

This comment has been minimized.

marmarek commented Mar 4, 2018

marmarek closed this Mar 4, 2018

awokd referenced this issue Mar 17, 2018

This comment has been minimized.

awokd commented Mar 17, 2018

andrewdavidwong reopened this Mar 17, 2018

This comment has been minimized.

awokd commented Mar 17, 2018

This comment has been minimized.

marmarek commented Mar 17, 2018

This comment has been minimized.

awokd commented Mar 17, 2018

This comment has been minimized.

marmarek commented Mar 17, 2018

This comment has been minimized.

awokd commented Mar 17, 2018

This comment has been minimized.

awokd commented Mar 19, 2018

This comment has been minimized.

marmarek commented Mar 19, 2018

marmarek closed this in marmarek/qubes-vmm-xen@967b9f0 Mar 19, 2018

This comment has been minimized.

qubesos-bot commented Mar 21, 2018

qubesos-bot added the r4.0-buster-cur-test label Mar 21, 2018

qubesos-bot referenced this issue in QubesOS/updates-status Mar 21, 2018

qubesos-bot added the r4.0-jessie-cur-test label Mar 21, 2018

This comment has been minimized.

qubesos-bot commented Mar 21, 2018

qubesos-bot added the r4.0-stretch-cur-test label Mar 21, 2018

This comment has been minimized.

qubesos-bot commented Mar 21, 2018

qubesos-bot added the r4.0-fc26-cur-test label Mar 21, 2018

This comment has been minimized.

qubesos-bot commented Mar 21, 2018

qubesos-bot added the r4.0-dom0-cur-test label Mar 21, 2018

This comment has been minimized.

qubesos-bot commented May 3, 2018

qubesos-bot added the r4.0-centos7-cur-test label May 3, 2018

This comment has been minimized.

qubesos-bot commented May 16, 2018

qubesos-bot added r4.0-centos7-stable and removed r4.0-centos7-cur-test labels May 16, 2018

This comment has been minimized.

qubesos-bot commented May 16, 2018

qubesos-bot added r4.0-fc26-stable r4.0-buster-stable r4.0-jessie-stable and removed r4.0-fc26-cur-test r4.0-buster-cur-test r4.0-jessie-cur-test labels May 16, 2018

This comment has been minimized.

qubesos-bot commented May 21, 2018

qubesos-bot added r4.0-stretch-stable and removed r4.0-stretch-cur-test labels May 21, 2018

This comment has been minimized.

qubesos-bot commented Jun 12, 2018

qubesos-bot added r4.0-dom0-stable and removed r4.0-dom0-cur-test labels Jun 12, 2018

marmarek closed this in `marmarek/qubes-vmm-xen@967b9f0` Mar 19, 2018