Dockerfile: switch golang image to "buster" variant by thaJeztah · Pull Request #39880 · moby/moby

thaJeztah · 2019-09-07T16:13:01Z

separating from #39549

thaJeztah · 2019-09-09T19:13:43Z

Remaining failure is cross-compiling the windows container utility ; https://ci.docker.com/public/blue/rest/organizations/jenkins/pipelines/moby/branches/PR-39880/runs/2/nodes/248/log/?start=0

Cloning into '/go/src/github.com/docker/windows-container-utility'...
remote: Enumerating objects: 19, done.�
remote: Total 19 (delta 0), reused 0 (delta 0), pack-reused 19�
Unpacking objects:   5% (1/19)   
Unpacking objects:  10% (2/19)   
Unpacking objects:  15% (3/19)   
Unpacking objects:  21% (4/19)   
Unpacking objects:  26% (5/19)   
Unpacking objects:  31% (6/19)   
Unpacking objects:  36% (7/19)   
Unpacking objects:  42% (8/19)   
Unpacking objects:  47% (9/19)   
Unpacking objects:  52% (10/19)   
Unpacking objects:  57% (11/19)   
Unpacking objects:  63% (12/19)   
Unpacking objects:  68% (13/19)   
Unpacking objects:  73% (14/19)   
Unpacking objects:  78% (15/19)   
Unpacking objects:  84% (16/19)   
Unpacking objects:  89% (17/19)   
Unpacking objects:  94% (18/19)   
Unpacking objects: 100% (19/19)   
Unpacking objects: 100% (19/19), done.
Building: bundles/cross/windows/amd64/containerutility.exe
In file included from /usr/x86_64-w64-mingw32/include/minwindef.h:163,
                 from /usr/x86_64-w64-mingw32/include/windef.h:8,
                 from /usr/x86_64-w64-mingw32/include/windows.h:69,
                 from containerutility.h:3,
                 from argumentstream.cpp:1:
/usr/x86_64-w64-mingw32/include/winnt.h:1554:11: fatal error: x86intrin.h: No such file or directory
 # include <x86intrin.h>
           ^~~~~~~~~~~~~
compilation terminated.
In file included from /usr/x86_64-w64-mingw32/include/minwindef.h:163,
                 from /usr/x86_64-w64-mingw32/include/windef.h:8,
                 from /usr/x86_64-w64-mingw32/include/windows.h:69,
                 from containerutility.h:3,
                 from commands.cpp:1:
/usr/x86_64-w64-mingw32/include/winnt.h:1554:11: fatal error: x86intrin.h: No such file or directory
 # include <x86intrin.h>
           ^~~~~~~~~~~~~
compilation terminated.
In file included from /usr/x86_64-w64-mingw32/include/minwindef.h:163,
                 from /usr/x86_64-w64-mingw32/include/windef.h:8,
                 from /usr/x86_64-w64-mingw32/include/windows.h:69,
                 from containerutility.h:3,
                 from containerutility.cpp:1:
/usr/x86_64-w64-mingw32/include/winnt.h:1554:11: fatal error: x86intrin.h: No such file or directory
 # include <x86intrin.h>
           ^~~~~~~~~~~~~
compilation terminated.
In file included from /usr/x86_64-w64-mingw32/include/minwindef.h:163,
                 from /usr/x86_64-w64-mingw32/include/windef.h:8,
                 from /usr/x86_64-w64-mingw32/include/windows.h:69,
                 from containerutility.h:3,
                 from identity.cpp:1:
/usr/x86_64-w64-mingw32/include/winnt.h:1554:11: fatal error: x86intrin.h: No such file or directory
 # include <x86intrin.h>
           ^~~~~~~~~~~~~
compilation terminated.
In file included from /usr/x86_64-w64-mingw32/include/minwindef.h:163,
                 from /usr/x86_64-w64-mingw32/include/windef.h:8,
                 from /usr/x86_64-w64-mingw32/include/windows.h:69,
                 from containerutility.h:3,
                 from version.cpp:1:
/usr/x86_64-w64-mingw32/include/winnt.h:1554:11: fatal error: x86intrin.h: No such file or directory
 # include <x86intrin.h>
           ^~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:6: containerutility.exe] Error 1
script returned exit code 2

thaJeztah · 2020-01-07T11:17:59Z

The compile error looks to be coming from this file; https://github.com/git-for-windows/git-sdk-32/blob/6e3f4d823b1aaf6f41ad30425e3e45168374412f/usr/include/w32api/winnt.h#L1554

(not sure if that's the source repo or a copy)

thaJeztah · 2020-01-07T11:43:08Z

On debian stretch:

find / -name x86intrin.h
/usr/lib/gcc/x86_64-linux-gnu/6/include/x86intrin.h
/usr/lib/gcc/x86_64-w64-mingw32/6.3-posix/include/x86intrin.h
/usr/lib/gcc/x86_64-w64-mingw32/6.3-win32/include/x86intrin.h

On debian buster:

find / -name x86intrin.h
/usr/lib/gcc/x86_64-linux-gnu/8/include/x86intrin.h
/usr/lib/gcc/x86_64-linux-gnu/7/include/x86intrin.h
/usr/lib/gcc/x86_64-w64-mingw32/8.3-posix/include/x86intrin.h
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/include/x86intrin.h

and without the gcc packages I added for testing;

find / -name x86intrin.h
/usr/lib/gcc/x86_64-linux-gnu/8/include/x86intrin.h
/usr/lib/gcc/x86_64-w64-mingw32/8.3-posix/include/x86intrin.h
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/include/x86intrin.h


find / -name winnt.h
/usr/share/mingw-w64/include/winnt.h
/usr/x86_64-w64-mingw32/include/winnt.h

thaJeztah · 2020-01-07T12:32:14Z

Ah! Think I found the culprit: https://github.com/docker/windows-container-utility/blob/e004a1415a433447369e315b9d7df357102be0d2/Makefile#L3

CFLAGS=-nostdinc -fno-exceptions -I/usr/x86_64-w64-mingw32/include -I/usr/lib/gcc/x86_64-w64-mingw32/6.3-win32/include -std=c++11 -static -DUNICODE -municode

The makefile hardcodes gcc 6.3-win32

thaJeztah · 2020-01-07T13:54:21Z

hack/make/containerutility

I was wondering why these paths have to be specified manually, because these paths should be known already;

x86_64-w64-mingw32-g++ -print-search-dirs install: /usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/ programs: =/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/:/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/8.3-win32/:/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/../../../../x86_64-w64-mingw32/bin/ libraries: =/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/:/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/8.3-win32/:/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/../../../../x86_64-w64-mingw32/lib/

Looking further, I noticed that the makefile sets -nostdinc, which disables MinGW searching in the standard paths;

Without specifying any path manually, and with -nostdinc set;

x86_64-w64-mingw32-g++ -nostdinc -v -fno-exceptions -std=c++11 -static -DUNICODE -municode -O3 -s -o containerutility.exe argumentstream.cpp commands.cpp containerutility.cpp identity.cpp version.cpp GNU C++11 (GCC) version 8.3-win32 20190406 (x86_64-w64-mingw32) compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 #include "..." search starts here: #include <...> search starts here: End of search list. GNU C++11 (GCC) version 8.3-win32 20190406 (x86_64-w64-mingw32) compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: ae7a3589826a0028176d9a8a3489295b In file included from identity.cpp:1: containerutility.h:3:21: error: no include path in which to search for windows.h #include <windows.h> ^

Removing that option makes compilation succeed without any manual path specified;

x86_64-w64-mingw32-g++ -fno-exceptions -std=c++11 -static -DUNICODE -municode -O3 -s -o containerutility.exe argumentstream.cpp commands.cpp containerutility.cpp identity.cpp version.cpp echo $? 0

So, the only path not included in the defaults is /usr/x86_64-w64-mingw32/include. That one looks to be containing symlinks to /usr/share/mingw-w64/include/

ls -la /usr/x86_64-w64-mingw32/include | more total 136 drwxr-xr-x 10 root root 69632 Jan 7 11:40 . drwxr-xr-x 5 root root 4096 Jan 7 11:40 .. drwxr-xr-x 2 root root 4096 Jan 7 11:40 GL lrwxrwxrwx 1 root root 42 Nov 11 2018 _bsd_types.h -> ../../share/mingw-w64/include/_bsd_types.h lrwxrwxrwx 1 root root 39 Nov 11 2018 _cygwin.h -> ../../share/mingw-w64/include/_cygwin.h lrwxrwxrwx 1 root root 38 Nov 11 2018 _dbdao.h -> ../../share/mingw-w64/include/_dbdao.h lrwxrwxrwx 1 root root 38 Nov 11 2018 _mingw.h -> ../../share/mingw-w64/include/_mingw.h lrwxrwxrwx 1 root root 47 Nov 11 2018 _mingw_dxhelper.h -> ../../share/mingw-w64/include/_mingw_dxhelper.h

Removing the -nostdinc, but adding that path will make it compile, but looks like the path will be ignored because it overlaps with a system directory;

x86_64-w64-mingw32-g++ -v -fno-exceptions -I/usr/x86_64-w64-mingw32/include -std=c++11 -static -DUNICODE -municode -O3 -s -o containerutility.exe argumentstream.cpp commands.cpp containerutility.cpp identity.cpp version.cpp GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/../../../../x86_64-w64-mingw32/sys-include" ignoring duplicate directory "/usr/x86_64-w64-mingw32/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/include/c++ /usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/include/c++/x86_64-w64-mingw32 /usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/include/c++/backward /usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/include /usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/include-fixed /usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/../../../../x86_64-w64-mingw32/include End of search list.

thaJeztah · 2020-01-07T14:31:10Z

opened ~~docker-archive/windows-container-utility#1~~ docker-archive/windows-container-utility#2 to fix the Makefile

``` ---> Making bundle: .integration-daemon-stop (in bundles/test-integration) ++++ cat bundles/test-integration/docker.pid +++ kill 13137 +++ /etc/init.d/apparmor stop Leaving: AppArmorNo profiles have been unloaded. Unloading profiles will leave already running processes permanently unconfined, which can lead to unexpected situations. To set a process to complain mode, use the command line tool 'aa-complain'. To really tear down all profiles, run 'aa-teardown'." script returned exit code 255 ``` Signed-off-by: Sebastiaan van Stijn <[email protected]>

… packages The btrfs-tools was a transitional package, and no longer exists: > Package btrfs-tools > stretch (oldstable) (admin): transitional dummy package > 4.7.3-1: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x It must be replaced either by `btrfs-progs` or `libbtrfs-dev` (which has just the development headers) > Package: libbtrfs-dev (4.20.1-2) > Checksumming Copy on Write Filesystem utilities (development headers) Note that the `libbtrfs-dev` package is not available on Debian stretch (only in stretch-backports) Signed-off-by: Sebastiaan van Stijn <[email protected]>

CI runs on Ubuntu 16.04 machines, which use iptables (legacy), but Debian buster uses nftables. Because of this, DNS resolution does not work if the daemon configures iptables. Signed-off-by: Sebastiaan van Stijn <[email protected]>

The makefile for this binary has version 6.3 hardcoded, which causes compilation on 8.3 to fail: ``` Building: bundles/cross/windows/amd64/containerutility.exe In file included from /usr/x86_64-w64-mingw32/include/minwindef.h:163, from /usr/x86_64-w64-mingw32/include/windef.h:8, from /usr/x86_64-w64-mingw32/include/windows.h:69, from containerutility.h:3, from argumentstream.cpp:1: /usr/x86_64-w64-mingw32/include/winnt.h:1554:11: fatal error: x86intrin.h: No such file or directory # include <x86intrin.h> ^~~~~~~~~~~~~ compilation terminated. ``` Signed-off-by: Sebastiaan van Stijn <[email protected]>

cpuguy83

LGTM

SamWhited · 2020-01-09T20:08:26Z

hack/make/containerutility

 	git checkout -q "$CONTAINER_UTILITY_COMMIT"

+	# TODO remove this temporary fix once https://github.com/docker/windows-container-utility/pull/2 is merged
+	sed -i \


nit: Would it make more sense to create a patch for this file and then apply the patch instead? This way if something changes upstream the patch might start failing instead of sed just silently replacing something it's not supposed to, or not changing something it doesn't find.

It'll likely be merged soon; some discussion was still happening, but this should go away soon

Merged the fix in the windows-container-utility repo, and opened a PR to revert this temporary fix: #40526

tianon

LGTM 👍

thaJeztah added status/2-code-review process/cherry-pick labels Sep 7, 2019

GordonTheTurtle added the status/0-triage label Sep 7, 2019

thaJeztah changed the title ~~Dockerfile: switch golang image to "buster" variant~~ [WIP] Dockerfile: switch golang image to "buster" variant Sep 7, 2019

thaJeztah removed the status/0-triage label Sep 9, 2019

thaJeztah requested a review from tianon as a code owner September 9, 2019 17:37

thaJeztah mentioned this pull request Sep 11, 2019

Bump go 1.13.0 #39549

Merged

6 tasks

thaJeztah force-pushed the buster_or_bust branch from 1607114 to ef75635 Compare October 21, 2019 22:57

thaJeztah force-pushed the buster_or_bust branch from ef75635 to 12fe4a5 Compare January 7, 2020 10:31

thaJeztah force-pushed the buster_or_bust branch from 12fe4a5 to 2646633 Compare January 7, 2020 13:07

thaJeztah commented Jan 7, 2020

View reviewed changes

thaJeztah mentioned this pull request Jan 7, 2020

Fix compilation on gcc-mingw-w64 8.3 (debian buster) docker-archive/windows-container-utility#1

Closed

thaJeztah changed the title ~~[WIP] Dockerfile: switch golang image to "buster" variant~~ Dockerfile: switch golang image to "buster" variant Jan 7, 2020

thaJeztah mentioned this pull request Jan 7, 2020

Use standard include paths instead of hard-coding docker-archive/windows-container-utility#2

Merged

thaJeztah force-pushed the buster_or_bust branch from 2646633 to ce4c3de Compare January 7, 2020 15:36

thaJeztah mentioned this pull request Jan 7, 2020

Bump golang 1.16.5 #40353

Merged

20 tasks

thaJeztah added 4 commits January 9, 2020 18:52

thaJeztah force-pushed the buster_or_bust branch from ce4c3de to 25a1bf5 Compare January 9, 2020 17:52

cpuguy83 approved these changes Jan 9, 2020

View reviewed changes

SamWhited reviewed Jan 9, 2020

View reviewed changes

tianon approved these changes Jan 9, 2020

View reviewed changes

thaJeztah merged commit f706531 into moby:master Jan 9, 2020

thaJeztah deleted the buster_or_bust branch January 9, 2020 21:46

thaJeztah mentioned this pull request Feb 14, 2020

Update windows container utility to fix compilation on gcc-mingw-w64 8.3 #40526

Merged

thaJeztah mentioned this pull request Feb 22, 2020

[19.03 backport] various dockerfile changes and update to buster variant #40558

Merged

thaJeztah added process/cherry-picked and removed process/cherry-pick labels Feb 22, 2020

thaJeztah added this to the 20.03.0 milestone Apr 2, 2020

thaJeztah mentioned this pull request Jun 24, 2020

Switch all Dockerfiles to use "buster" variant #41150

Merged

Conversation

thaJeztah commented Sep 7, 2019

Uh oh!

thaJeztah commented Sep 9, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thaJeztah commented Jan 7, 2020

Uh oh!

thaJeztah commented Jan 7, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thaJeztah commented Jan 7, 2020

Uh oh!

thaJeztah Jan 7, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thaJeztah Jan 7, 2020

Choose a reason for hiding this comment

Uh oh!

thaJeztah Jan 7, 2020

Choose a reason for hiding this comment

Uh oh!

thaJeztah commented Jan 7, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cpuguy83 left a comment

Choose a reason for hiding this comment

Uh oh!

SamWhited Jan 9, 2020

Choose a reason for hiding this comment

Uh oh!

thaJeztah Jan 9, 2020

Choose a reason for hiding this comment

Uh oh!

thaJeztah Feb 14, 2020

Choose a reason for hiding this comment

Uh oh!

tianon left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

thaJeztah commented Sep 9, 2019 •

edited

Loading

thaJeztah commented Jan 7, 2020 •

edited

Loading

thaJeztah Jan 7, 2020 •

edited

Loading

thaJeztah commented Jan 7, 2020 •

edited

Loading