Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#12391 closed defect (fixed)

Building mingw-w64 is failing intermittently

Reported by: gk Owned by: erinn
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Keywords: gitian, TorBrowserTeam201407
Cc: michael, mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

For unknown reason building the nightly fails:

The directory that should contain system headers does not exist:
  /home/ubuntu/install/mingw-w64/i686-w64-mingw32/sys-include
echo timestamp > stmp-fixinc
/bin/bash ../gcc-4.6.3/gcc/../mkinstalldirs /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/include
mkdir -p -- /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/include
rm -rf /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/include-fixed
mkdir /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/include-fixed
chmod a+rx /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/include-fixed
(cd `${PWDCMD-pwd}`/include ; \
	 tar -cf - .; exit 0) | (cd /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/include; tar xpf - )
(cd `${PWDCMD-pwd}`/include-fixed ; \
	 tar -cf - .; exit 0) | (cd /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/include-fixed; tar xpf - )
files=`cd /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/include-fixed; find . -type l -print 2>/dev/null`; \
	if [ $? -eq 0 ]; then \
	  dir=`cd include-fixed; ${PWDCMD-pwd}`; \
	  for i in $files; do \
	    dest=`ls -ld /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/include-fixed/$i | sed -n 's/.*-> //p'`; \
	    if expr "$dest" : "$dir.*" > /dev/null; then \
	      rm -f /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/include-fixed/$i; \
	      ln -s `echo $i | sed "s|/[^/]*|/..|g" | sed 's|/..$||'``echo "$dest" | sed "s|$dir||"` /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/include-fixed/$i; \
	    fi; \
	  done; \
	fi
/bin/bash ../gcc-4.6.3/gcc/../mkinstalldirs /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/install-tools/include
/bin/bash ../gcc-4.6.3/gcc/../mkinstalldirs /home/ubuntu/install/mingw-w64/libexec/gcc/i686-w64-mingw32/4.6.3/install-tools
/usr/bin/install -c -m 644 ../gcc-4.6.3/gcc/gsyslimits.h \
	  /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/install-tools/gsyslimits.h
/usr/bin/install -c -m 644 macro_list /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/install-tools/macro_list
/usr/bin/install -c -m 644 fixinc_list /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/install-tools/fixinc_list
set -e; for ml in `cat fixinc_list`; do \
	  multi_dir=`echo ${ml} | sed -e 's/^[^;]*;//'`; \
	  /bin/bash ../gcc-4.6.3/gcc/../mkinstalldirs /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/install-tools/include${multi_dir}; \
	  /usr/bin/install -c -m 644 include-fixed${multidir}/limits.h /home/ubuntu/install/mingw-w64/lib/gcc/i686-w64-mingw32/4.6.3/install-tools/include${multi_dir}/limits.h; \
	done
/usr/bin/install: cannot stat `include-fixed/limits.h': No such file or directory
make[1]: *** [install-mkheaders] Error 1
make[1]: Leaving directory `/home/ubuntu/build/gcc/gcc'
make: *** [install-gcc] Error 2

I verified that on an own machine.

Child Tickets

Attachments (1)

msvb12391-306bbfd_1.diff (1.1 KB) - added by michael 6 years ago.
Silly nonsense blocks that nonetheless provide information and even a manual workaround if applied at the right time

Download all attachments as: .zip

Change History (22)

comment:1 Changed 6 years ago by gk

Using maint-3.6 with the versions file seems fine, hmm...

Changed 6 years ago by michael

Attachment: msvb12391-306bbfd_1.diff added

Silly nonsense blocks that nonetheless provide information and even a manual workaround if applied at the right time

comment:2 Changed 6 years ago by michael

Cc: michael added

It would probably make sense to find the last nightly that didn't fail, and compare the build logic (GCC version, checksums, build-script, gcc/Makefile.in) with the next nightly that failed.

Or compare maint-3.6 (fine according to gk) with master (broken in my case after checking out tbb-3.6.2-build6.)

comment:3 Changed 6 years ago by michael

Just to clarify (since the title indicates mingw-w64), the logic causing this flaw is not in mingw-w64-svn-snapshot.zip but rather in gcc.tar.bz2 as msvb12391-306bbfd_1.diff shows.

comment:4 Changed 6 years ago by dcf

A workaround that works for me is to run the build again after it fails the first time; i.e., run "make build-alpha" twice.

comment:5 in reply to:  4 Changed 6 years ago by mcs

Cc: mcs added

Replying to dcf:

A workaround that works for me is to run the build again after it fails the first time; i.e., run "make build-alpha" twice.

I had basically the same experience a few days ago: I was experimenting with gcc 4.8.3 and it failed just as described in this ticket. At first I thought the newer gcc was to blame, but building a second time succeeded. I wonder what the root cause is....

comment:6 Changed 6 years ago by michael

One guess (needs more review) of the root cause is that the stmp-fixinc Makefile target is correctly called during building, but during installing (install-gcc) it is called again although it shouldn't be. This renames the needed file limits.h to 'syslimits.h' before the install script can find and copy limits.h.

Grep the Makefile.in for 'stmp-fixinc' and you'll find the logic in question.

comment:7 Changed 6 years ago by gk

Summary: Building mingw-w64 in a nightly build is broken.Building mingw-w64 if failing intermittently during |make install|

I can't reproduce that reliably on my machines. If somebody finds steps to do so I am all ears.

comment:8 Changed 6 years ago by gk

Summary: Building mingw-w64 if failing intermittently during |make install|Building mingw-w64 is failing intermittently during |make install|

comment:9 in reply to:  7 ; Changed 6 years ago by michael

Replying to gk:

I can't reproduce that reliably on my machines. If somebody finds steps to do so I am all ears.

Reproduce what? You mean you can't reproduce the workaround that dcf suggested, you can't find the Makefile.in with the stmp-fixinc target, or something else? Does running 'make build' from the host a second time work for you?

comment:10 in reply to:  9 Changed 6 years ago by gk

Replying to michael:

Replying to gk:

I can't reproduce that reliably on my machines. If somebody finds steps to do so I am all ears.

Reproduce what?

The build failure.

comment:11 Changed 6 years ago by gk

Keywords: TorBrowserTeam201407 added

comment:12 Changed 6 years ago by gk

Summary: Building mingw-w64 is failing intermittently during |make install|Building mingw-w64 is failing intermittently

Another failure that may happen is described in #12608. I have a branch that is fixing both, bug_12391_v1 in my public tor-browser-bundle repo. It still needs testing in a KVM environment different from mine. To test
0) make sure you don't have old Windows related *gbuilt.zip files that might interfere
1) check out the aforementioned branch
2) |./fetch-inputs.sh ../../gitian-builder/inputs versions.alpha|
3) |./mkbundle-windows.sh versions.alpha|

comment:13 Changed 6 years ago by mcs

Cc: brade added

comment:14 in reply to:  12 ; Changed 6 years ago by dcf

Replying to gk:

Another failure that may happen is described in #12608. I have a branch that is fixing both, bug_12391_v1 in my public tor-browser-bundle repo. It still needs testing in a KVM environment different from mine. To test
0) make sure you don't have old Windows related *gbuilt.zip files that might interfere
1) check out the aforementioned branch
2) |./fetch-inputs.sh ../../gitian-builder/inputs versions.alpha|
3) |./mkbundle-windows.sh versions.alpha|

I had a successful windows build of bug_12391_v1 on KVM.

Generating report
14df1302dc5b85f24b4a12e73bff813c36dd7f94d038c0b34341c4634fc77584  torbrowser-install-4.0-alpha-1_ar.exe
dfeaf17382490d8b2c2b1ad571fbbe4ef34df68b28e21eb5a3f55cf52f7b06f8  torbrowser-install-4.0-alpha-1_de.exe
27f84c7df198ddc5928f91008ad19de70301767c63cf21c7ff3f74a90e04bab2  torbrowser-install-4.0-alpha-1_en-US.exe
0bbf22e649d33cf73a75f968e041f95d72956a5392035cca682b4a60dab1ec71  torbrowser-install-4.0-alpha-1_es-ES.exe
7dd2fcfec885969eb247a84526071844faf9eedb8630a498c2b32908ca787265  torbrowser-install-4.0-alpha-1_fa.exe
6b3c71e13e1e883154deab3166ceee8c0dfd2b6ce5c15f97bf81708f78d1892a  torbrowser-install-4.0-alpha-1_fr.exe
b7569090e7d729085b4c39accef40762f2c5fc38e5548325cc01e5283f669418  torbrowser-install-4.0-alpha-1_it.exe
858548a319481697d4c2170c9cd3b36d0f9794b1b271e2d2c519b1a233da7e51  torbrowser-install-4.0-alpha-1_ko.exe
b35699fe7ec65642969c892ddafc2d7581c584a145c94659c859da63007978b4  torbrowser-install-4.0-alpha-1_nl.exe
bdc00f598f4ca1181eb370f4cc8b479ef28d57ea9fe48b597ae29e46a2734bbb  torbrowser-install-4.0-alpha-1_pl.exe
f6b84710c4ac5f7e13316cf3832e17593981aa417e9e4f1214e8438c4263e411  torbrowser-install-4.0-alpha-1_pt-PT.exe
be226bf80249126a6567299f89b2ff8f0ddc1f3aa5f5800539d93eb1152586f3  torbrowser-install-4.0-alpha-1_ru.exe
e585e377468a105ab1f1289cdfe813c8a79b6cf6d2c5be2a1036c64408c160a5  torbrowser-install-4.0-alpha-1_tr.exe
8f43dedc2703af5c3f7ebb0d4b79f6c83a982ab14f2041a6b76ca1489219b488  torbrowser-install-4.0-alpha-1_vi.exe
ede08637a6a9b3af99416af9a7a4529f2f28bdca4a9b0e38fee48d15dc2b2016  torbrowser-install-4.0-alpha-1_zh-CN.exe
49304e8aff7aab5295291f2e70fd9d3ff41b53d221ca620513bf5476def2c002  bundle-windows-res.yml

I can upload these files if you need me to.

comment:15 Changed 6 years ago by mcs

Kathy Brade and I started a completely clean build on a 14.04 LTS system. It got past the Windows utils step on the first try (which has never happened before for me since the recent mingw-w64 upgrade). Unfortunately, it failed during the PT portion of the build:

****** Starting Pluggable Transports Component of Windows Bundle (4/5 for Windows) ******

sha256sum: wine-wrappers: Is a directory
--- Building pluggable-transports-windows for precise i386 ---
Stopping target if it is up
Making a new image copy
Formatting 'target-precise-i386.qcow2', fmt=qcow2 size=11811160064 backing_file='base-precise-i386.qcow2' encryption=off cluster_size=65536 lazy_refcounts=off
Starting target
Checking if target is up
Preparing build environment
Updating apt-get repository (log in var/install.log)
Installing additional packages (log in var/install.log)
Grabbing package manifest
Creating build script (var/build-script)
Running build script (log in var/build.log)
./bin/gbuild:21:in `system!': failed to run on-target setarch i386 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError)
        from ./bin/gbuild:122:in `build_one_configuration'
        from ./bin/gbuild:224:in `block (2 levels) in <main>'
        from ./bin/gbuild:219:in `each'
        from ./bin/gbuild:219:in `block in <main>'
        from ./bin/gbuild:217:in `each'
        from ./bin/gbuild:217:in `<main>'
make: *** [build-alpha] Error 1

I do not think we have done a TBB build since meek was added. Here is the tail of var/build.log:

# Building compilers and Go bootstrap tool for host, linux/386.
lib9
In file included from /usr/include/inttypes.h:26:0,
                 from /home/ubuntu/build/go/include/u.h:59,
                 from /home/ubuntu/build/go/src/lib9/await.c:30:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directoryIn file included from /usr/include/inttypes.h:26:0,
                 from /home/ubuntu/build/go/include/u.h:59,
                 from /home/ubuntu/build/go/src/lib9/_exits.c:26:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
compilation terminated.

compilation terminated.
In file included from /usr/include/inttypes.h:26:0,
                 from /home/ubuntu/build/go/include/u.h:59,
                 from /home/ubuntu/build/go/src/lib9/atoi.c:26:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
compilation terminated.
In file included from /usr/include/inttypes.h:26:0,
                 from /home/ubuntu/build/go/include/u.h:59,
                 from /home/ubuntu/build/go/src/lib9/_p9dir.c:26:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
compilation terminated.
go tool dist: FAILED: gcc -Wall -Wstrict-prototypes -Wextra -Wunused -Wuninitialized -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -Wno-unknown-pragmas -Wno-switch -Wno-comment -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe -O2 -c -m32 -DPLAN9PORT -I /home/ubuntu/build/go/include -I /home/ubuntu/build/go/src/lib9 -o $WORK/_exits.o /home/ubuntu/build/go/src/lib9/_exits.c
go tool dist: FAILED: gcc -Wall -Wstrict-prototypes -Wextra -Wunused -Wuninitialized -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -Wno-unknown-pragmas -Wno-switch -Wno-comment -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe -O2 -c -m32 -DPLAN9PORT -I /home/ubuntu/build/go/include -I /home/ubuntu/build/go/src/lib9 -o $WORK/atoi.o /home/ubuntu/build/go/src/lib9/atoi.c
go tool dist: FAILED: gcc -Wall -Wstrict-prototypes -Wextra -Wunused -Wuninitialized -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -Wno-unknown-pragmas -Wno-switch -Wno-comment -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe -O2 -c -m32 -DPLAN9PORT -I /home/ubuntu/build/go/include -I /home/ubuntu/build/go/src/lib9 -o $WORK/await.o /home/ubuntu/build/go/src/lib9/await.c
go tool dist: FAILED: gcc -Wall -Wstrict-prototypes -Wextra -Wunused -Wuninitialized -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -Wno-unknown-pragmas -Wno-switch -Wno-comment -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe -O2 -c -m32 -DPLAN9PORT -I /home/ubuntu/build/go/include -I /home/ubuntu/build/go/src/lib9 -o $WORK/_p9dir.o /home/ubuntu/build/go/src/lib9/_p9dir.c

Has anyone seen this before? Maybe the cause is similar (libfaketime interference). I restarted the build and it got past the PT phase on the second try.

comment:16 in reply to:  15 ; Changed 6 years ago by dcf

Replying to mcs:

I do not think we have done a TBB build since meek was added. Here is the tail of var/build.log:

# Building compilers and Go bootstrap tool for host, linux/386.
lib9
In file included from /usr/include/inttypes.h:26:0,
                 from /home/ubuntu/build/go/include/u.h:59,
                 from /home/ubuntu/build/go/src/lib9/await.c:30:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directoryIn file included from /usr/include/inttypes.h:26:0,
                 from /home/ubuntu/build/go/include/u.h:59,
                 from /home/ubuntu/build/go/src/lib9/_exits.c:26:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
compilation terminated.

compilation terminated.
In file included from /usr/include/inttypes.h:26:0,
                 from /home/ubuntu/build/go/include/u.h:59,
                 from /home/ubuntu/build/go/src/lib9/atoi.c:26:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
compilation terminated.
In file included from /usr/include/inttypes.h:26:0,
                 from /home/ubuntu/build/go/include/u.h:59,
                 from /home/ubuntu/build/go/src/lib9/_p9dir.c:26:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
compilation terminated.
go tool dist: FAILED: gcc -Wall -Wstrict-prototypes -Wextra -Wunused -Wuninitialized -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -Wno-unknown-pragmas -Wno-switch -Wno-comment -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe -O2 -c -m32 -DPLAN9PORT -I /home/ubuntu/build/go/include -I /home/ubuntu/build/go/src/lib9 -o $WORK/_exits.o /home/ubuntu/build/go/src/lib9/_exits.c
go tool dist: FAILED: gcc -Wall -Wstrict-prototypes -Wextra -Wunused -Wuninitialized -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -Wno-unknown-pragmas -Wno-switch -Wno-comment -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe -O2 -c -m32 -DPLAN9PORT -I /home/ubuntu/build/go/include -I /home/ubuntu/build/go/src/lib9 -o $WORK/atoi.o /home/ubuntu/build/go/src/lib9/atoi.c
go tool dist: FAILED: gcc -Wall -Wstrict-prototypes -Wextra -Wunused -Wuninitialized -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -Wno-unknown-pragmas -Wno-switch -Wno-comment -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe -O2 -c -m32 -DPLAN9PORT -I /home/ubuntu/build/go/include -I /home/ubuntu/build/go/src/lib9 -o $WORK/await.o /home/ubuntu/build/go/src/lib9/await.c
go tool dist: FAILED: gcc -Wall -Wstrict-prototypes -Wextra -Wunused -Wuninitialized -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -Wno-unknown-pragmas -Wno-switch -Wno-comment -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe -O2 -c -m32 -DPLAN9PORT -I /home/ubuntu/build/go/include -I /home/ubuntu/build/go/src/lib9 -o $WORK/_p9dir.o /home/ubuntu/build/go/src/lib9/_p9dir.c

Has anyone seen this before? Maybe the cause is similar (libfaketime interference). I restarted the build and it got past the PT phase on the second try.

I haven't seen this error through many builds that included golang. However I have only tried building on Ubuntu 12.04.

I found some references to the "bits/predefs.h" error:

The sources say to try installing either libc6-dev-i386 or gcc-multilib. What does apt-get build-dep golang say inside the VM? It could be that we just need to add a new dependency in the descriptor.

comment:17 in reply to:  14 Changed 6 years ago by gk

Replying to dcf:

Replying to gk:

Another failure that may happen is described in #12608. I have a branch that is fixing both, bug_12391_v1 in my public tor-browser-bundle repo. It still needs testing in a KVM environment different from mine. To test
0) make sure you don't have old Windows related *gbuilt.zip files that might interfere
1) check out the aforementioned branch
2) |./fetch-inputs.sh ../../gitian-builder/inputs versions.alpha|
3) |./mkbundle-windows.sh versions.alpha|

I had a successful windows build of bug_12391_v1 on KVM.

Generating report
14df1302dc5b85f24b4a12e73bff813c36dd7f94d038c0b34341c4634fc77584  torbrowser-install-4.0-alpha-1_ar.exe
dfeaf17382490d8b2c2b1ad571fbbe4ef34df68b28e21eb5a3f55cf52f7b06f8  torbrowser-install-4.0-alpha-1_de.exe
27f84c7df198ddc5928f91008ad19de70301767c63cf21c7ff3f74a90e04bab2  torbrowser-install-4.0-alpha-1_en-US.exe
0bbf22e649d33cf73a75f968e041f95d72956a5392035cca682b4a60dab1ec71  torbrowser-install-4.0-alpha-1_es-ES.exe
7dd2fcfec885969eb247a84526071844faf9eedb8630a498c2b32908ca787265  torbrowser-install-4.0-alpha-1_fa.exe
6b3c71e13e1e883154deab3166ceee8c0dfd2b6ce5c15f97bf81708f78d1892a  torbrowser-install-4.0-alpha-1_fr.exe
b7569090e7d729085b4c39accef40762f2c5fc38e5548325cc01e5283f669418  torbrowser-install-4.0-alpha-1_it.exe
858548a319481697d4c2170c9cd3b36d0f9794b1b271e2d2c519b1a233da7e51  torbrowser-install-4.0-alpha-1_ko.exe
b35699fe7ec65642969c892ddafc2d7581c584a145c94659c859da63007978b4  torbrowser-install-4.0-alpha-1_nl.exe
bdc00f598f4ca1181eb370f4cc8b479ef28d57ea9fe48b597ae29e46a2734bbb  torbrowser-install-4.0-alpha-1_pl.exe
f6b84710c4ac5f7e13316cf3832e17593981aa417e9e4f1214e8438c4263e411  torbrowser-install-4.0-alpha-1_pt-PT.exe
be226bf80249126a6567299f89b2ff8f0ddc1f3aa5f5800539d93eb1152586f3  torbrowser-install-4.0-alpha-1_ru.exe
e585e377468a105ab1f1289cdfe813c8a79b6cf6d2c5be2a1036c64408c160a5  torbrowser-install-4.0-alpha-1_tr.exe
8f43dedc2703af5c3f7ebb0d4b79f6c83a982ab14f2041a6b76ca1489219b488  torbrowser-install-4.0-alpha-1_vi.exe
ede08637a6a9b3af99416af9a7a4529f2f28bdca4a9b0e38fee48d15dc2b2016  torbrowser-install-4.0-alpha-1_zh-CN.exe
49304e8aff7aab5295291f2e70fd9d3ff41b53d221ca620513bf5476def2c002  bundle-windows-res.yml

I can upload these files if you need me to.

Not necessary, thanks. These builds are matching mine, so I plan to merge my fix within the next days (unless someone is showing up with a non-matching build) in order to get a alpha release out next week after the usual TBB update dance...

comment:18 in reply to:  16 ; Changed 6 years ago by mcs

Replying to dcf:

I haven't seen this error through many builds that included golang. However I have only tried building on Ubuntu 12.04.

I found some references to the "bits/predefs.h" error:

Thanks for the info. But it does not make sense to me that the build would succeed the second time (after I restarted it).

The sources say to try installing either libc6-dev-i386 or gcc-multilib. What does apt-get build-dep golang say inside the VM? It could be that we just need to add a new dependency in the descriptor.

I had to add some deb-src lines to /etc/apt/sources.list in order to successfully run the 'apt-get build-dep golang' command. The output includes:

The following NEW packages will be installed:
  bison bsdmainutils debhelper dh-apparmor ed gettext groff-base html2text
  intltool-debian libbison-dev man-db po-debconf

One more thing: deleting pluggable-transports-win32-gbuilt.zip and re-running the build does not reproduce the failure. Maybe the failure only happens rarely; I will try a few more times.

comment:19 Changed 6 years ago by michael

Linked to this bug in the Gitian building document since it includes a section on installing gcc-multilib in a KVM guest to work around architecture flawed logic.

comment:20 Changed 6 years ago by gk

Resolution: fixed
Status: newclosed

Okay, calling this one closed with dcf's matching bundles and commit 5b71d6072028e0d582ad7405597fd615586a0734. Please, open new tickets for bugs found during investigating/fixing/... this bug. And, of course, reopen if it turns out that the workaround is not sufficient.

Last edited 6 years ago by gk (previous) (diff)

comment:21 in reply to:  18 Changed 6 years ago by dcf

Replying to mcs:

Replying to dcf:

I haven't seen this error through many builds that included golang. However I have only tried building on Ubuntu 12.04.

I found some references to the "bits/predefs.h" error:

Thanks for the info. But it does not make sense to me that the build would succeed the second time (after I restarted it).

michael's notes in doc/TorBrowser/BuildingWithGitian#AssemblyErrorsinMismatchedArchitectureCode link the bits/predefs.h error to x86cpuid.s Err: invalid instruction suffix for `push' in openssl. I have definitely seen the "invalid instruction suffix" error before, when kvm was running for the wrong architecture. Killing the kvm process and restarting the build has worked to resolve that problem. It's possible that you saw the error first in golang and not in openssl, if you were using an already built gitian-utils step.

Note: See TracTickets for help on using tickets.