Skip to content
Snippets Groups Projects
New look: Off

Building mingw-w64 is failing intermittently

    • Closed Issue created by Georg Koppen @gk

    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.

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Georg Koppen added TorBrowserTeam201407 component::applications/tor bundles/installation gitian owner::erinn priority::medium resolution::fixed status::closed type::defect labels

      added TorBrowserTeam201407 component::applications/tor bundles/installation gitian owner::erinn priority::medium resolution::fixed status::closed type::defect labels

    • Georg Koppen
      Georg Koppen @gk ·
      Author

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

    • Trac
      Trac @tracbot ·

      Trac:
      Username: michael

      msvb12391-306bbfd_1.diff

    • Trac
      Trac @tracbot ·

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

      Trac:
      Username: michael

    • Trac
      Trac @tracbot ·

      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.)

      Trac:
      Username: michael
      Cc: N/A to michael

    • Trac
      Trac @tracbot ·

      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.

      Trac:
      Username: michael

    • D
      David Fifield @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.

    • Mark Smith
      Mark Smith @mcs ·

      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....

      Trac:
      Cc: michael to michael, mcs

    • Trac
      Trac @tracbot ·

      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.

      Trac:
      Username: michael

    • Georg Koppen
      Georg Koppen @gk ·
      Author

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

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

    • Georg Koppen
      Georg Koppen @gk ·
      Author

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

    • Trac
      Trac @tracbot ·

      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?

      Trac:
      Username: michael

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      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.

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      Trac:
      Keywords: N/A deleted, TorBrowserTeam201407 added

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      Another failure that may happen is described in #12608 (closed). 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|

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

    • Mark Smith
      Mark Smith @mcs ·

      Trac:
      Cc: michael, mcs to michael, mcs, brade

    • D
      David Fifield @dcf ·

      Replying to gk:

      Another failure that may happen is described in #12608 (closed). 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.

    • Mark Smith
      Mark Smith @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.

    • D
      David Fifield @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.

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      Replying to dcf:

      Replying to gk:

      Another failure that may happen is described in #12608 (closed). 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...

    • Mark Smith
      Mark Smith @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.

    • Trac
      Trac @tracbot ·

      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.

      Trac:
      Username: michael

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      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.

      Trac:
      Resolution: N/A to fixed
      Status: new to closed

    • D
      David Fifield @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.

    • Trac closed

      closed

    • Georg Koppen mentioned in issue #12608 (closed)

      mentioned in issue #12608 (closed)

    • Georg Koppen mentioned in issue #12753 (moved)

      mentioned in issue #12753 (moved)

    • cypherpunks mentioned in issue #13654 (moved)

      mentioned in issue #13654 (moved)

    • Georg Koppen mentioned in issue #13654 (moved)

      mentioned in issue #13654 (moved)

    • Trac mentioned in issue tpo/applications/tor-browser#12753 (closed)

      mentioned in issue tpo/applications/tor-browser#12753 (closed)

    Please register or sign in to reply