Skip to content
Snippets Groups Projects
New look: Off

Clean up mingw-w64 project

    • Closed (moved) Issue created by Georg Koppen @gk

    We switched to mingw-w64-clang for the Firefox project and should now clean up the mingw-w64 as it still contains cruft related to our spec hack etc.

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

    Child items ...

    • Activity

    • Trac
      Trac @tracbot ·

      Trac:
      Parent Ticket: #30322 (moved)

    • Georg Koppen added GeorgKoppen201909 TorBrowserTeam201909R actualpoints::2 component::applications/tor browser ff68-esr owner::tbb-team parent::30322 points::1 priority::medium resolution::fixed severity::normal status::closed tbb-9.0-must-alpha tbb-rbm type::task labels

      added GeorgKoppen201909 TorBrowserTeam201909R actualpoints::2 component::applications/tor browser ff68-esr owner::tbb-team parent::30322 points::1 priority::medium resolution::fixed severity::normal status::closed tbb-9.0-must-alpha tbb-rbm type::task labels

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      Note, we might bump the GCC version to something supported while we are at it. Likely 8.3.0 as we do use elsewhere.

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      Move must-nightly items to must-alpha ones.

      Trac:
      Keywords: tbb-9.0-must-nightly deleted, tbb-9.0-must-alpha added

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      Moving must-alpha tickets to September.

      Trac:
      Keywords: TorBrowserTeam201908 deleted, TorBrowserTeam201909 added

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      First ticket move of mine.

      Trac:
      Keywords: GeorgKoppen201908 deleted, GeorgKoppen201909 added

    • Pili Guerra
      Pili Guerra @pili ·

      Trac:
      Points: N/A to 1

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      Trac:
      Description: We switched to mingw-w64-clang for the Firefox project and should not clean up the mingw-w64 as it still contains cruft related to our spec hack etc.

      to

      We switched to mingw-w64-clang for the Firefox project and should now clean up the mingw-w64 as it still contains cruft related to our spec hack etc.

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      Okay, this took me way longer than expected. bug_31584_v4 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_31584_v4&id=67a38dec8014e4ba33dc062527e74df2aca1f3db) is the resulting patch (which is on top of the patches for #31538 (moved)). For posterity, the mentioned GCC crash when compiling 64-bit Rust is:

      cargo:rustc-cfg=rdos
TARGET = Some("x86_64-pc-windows-gnu")
OPT_LEVEL = Some("2")
HOST = Some("x86_64-unknown-linux-gnu")
CC_x86_64-pc-windows-gnu = Some("x86_64-w64-mingw32-gcc")
CFLAGS_x86_64-pc-windows-gnu = Some("-ffunction-sections -fdata-sections -m64")
running: "x86_64-w64-mingw32-gcc" "-O2" "-ffunction-sections" "-fdata-sections" "-ffunction-sections" "-fdata-sections" "-m64" "-g" "-fno-omit-frame-pointer" "-m64" "-I" "src/libbacktrace" "-I" "/var/tmp/build/rustc-1.34.2-src/build/build/x86_64-unknown-linux-gnu/stage2-std/x86_64-pc-windows-gnu/release/build/backtrace-sys-38ec08965faeaf20/out" "-fvisibility=hidden" "-DBACKTRACE_SUPPORTED=1" "-DBACKTRACE_USES_MALLOC=1" "-DBACKTRACE_SUPPORTS_THREADS=0" "-DBACKTRACE_SUPPORTS_DATA=0" "-DHAVE_DL_ITERATE_PHDR=1" "-D_GNU_SOURCE=1" "-D_LARGE_FILES=1" "-Dbacktrace_full=__rdos_backtrace_full" "-Dbacktrace_dwarf_add=__rdos_backtrace_dwarf_add" "-Dbacktrace_initialize=__rdos_backtrace_initialize" "-Dbacktrace_pcinfo=__rdos_backtrace_pcinfo" "-Dbacktrace_syminfo=__rdos_backtrace_syminfo" "-Dbacktrace_get_view=__rdos_backtrace_get_view" "-Dbacktrace_release_view=__rdos_backtrace_release_view" "-Dbacktrace_alloc=__rdos_backtrace_alloc" "-Dbacktrace_free=__rdos_backtrace_free" "-Dbacktrace_vector_finish=__rdos_backtrace_vector_finish" "-Dbacktrace_vector_grow=__rdos_backtrace_vector_grow" "-Dbacktrace_vector_release=__rdos_backtrace_vector_release" "-Dbacktrace_close=__rdos_backtrace_close" "-Dbacktrace_open=__rdos_backtrace_open" "-Dbacktrace_print=__rdos_backtrace_print" "-Dbacktrace_simple=__rdos_backtrace_simple" "-Dbacktrace_qsort=__rdos_backtrace_qsort" "-Dbacktrace_create_state=__rdos_backtrace_create_state" "-Dbacktrace_uncompress_zdebug=__rdos_backtrace_uncompress_zdebug" "-o" "/var/tmp/build/rustc-1.34.2-src/build/build/x86_64-unknown-linux-gnu/stage2-std/x86_64-pc-windows-gnu/release/build/backtrace-sys-38ec08965faeaf20/out/src/libbacktrace/alloc.o" "-c" "src/libbacktrace/alloc.c"
cargo:warning=during RTL pass: final
cargo:warning=src/libbacktrace/alloc.c: In function '__rdos_backtrace_free':
cargo:warning=src/libbacktrace/alloc.c:75:1: internal compiler error: in based_loc_descr, at dwarf2out.c:14318
cargo:warning= }
cargo:warning= ^
cargo:warning=0x7b1afa based_loc_descr
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:14313
cargo:warning=0x7e404f mem_loc_descriptor(rtx_def*, machine_mode, machine_mode, var_init_status)
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:15861
cargo:warning=0x7e77e0 loc_descriptor
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:16603
cargo:warning=0x7e7d38 loc_descriptor
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:16631
cargo:warning=0x7e80cf dw_loc_list_1
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:16933
cargo:warning=0x7d1b2d dw_loc_list
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:17216
cargo:warning=0x7d1b2d loc_list_from_tree_1
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:18350
cargo:warning=0x7d3bda loc_list_from_tree
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:18957
cargo:warning=0x7d8358 add_location_or_const_value_attribute
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:20184
cargo:warning=0x7de49a gen_formal_parameter_die
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:22287
cargo:warning=0x7cfd72 gen_decl_die
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:26438
cargo:warning=0x7cd7bb gen_subprogram_die
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:23271
cargo:warning=0x7cfd28 gen_decl_die
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:26319
cargo:warning=0x7d0776 dwarf2out_decl
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:26884
cargo:warning=0x7ea1fe dwarf2out_function_decl
cargo:warning=	../gcc-8.3.0/gcc/dwarf2out.c:26899
cargo:warning=0x8376dd rest_of_handle_final
cargo:warning=	../gcc-8.3.0/gcc/final.c:4713
cargo:warning=0x8376dd execute
cargo:warning=	../gcc-8.3.0/gcc/final.c:4755

      The pthread situation is a bit unfortunate. However, I think we can fix that by moving the tor compilation (and it's dependencies) to mingw-w64-clang. If we don't find a better solution than I have in my patch then I'll file a ticket about that so we don't forget and make the mingw-w64-clang transition blocking it.

      Trac:
      Keywords: TorBrowserTeam201909 deleted, TorBrowserTeam201909R added
      Status: new to needs_review

    • C
      cypherpunks @cypherpunks ·

      o_0 isn't it for switching to clang? If you also want gcc, do it for nightlies only, please.

    • boklm
      boklm @boklm ·

      Replying to gk:

      Okay, this took me way longer than expected. bug_31584_v4 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_31584_v4&id=67a38dec8014e4ba33dc062527e74df2aca1f3db) is the resulting patch (which is on top of the patches for #31538 (moved)).

      The patch looks good to me. I merged it to master with commit 17c61f4b647f0e0bf759d78ad49520770914524e.

      The pthread situation is a bit unfortunate. However, I think we can fix that by moving the tor compilation (and it's dependencies) to mingw-w64-clang. If we don't find a better solution than I have in my patch then I'll file a ticket about that so we don't forget and make the mingw-w64-clang transition blocking it.

      Yes, it doesn't look like it is possible to disable pthread without rebuilding gcc. I'm leaving this ticket open until the ticket to switch tor to mingw-w64-clang is created.

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      Opened #31828 (moved), closing.

      Trac:
      Resolution: N/A to fixed
      Actualpoints: N/A to 2
      Status: needs_review to closed

    • C
      cypherpunks @cypherpunks ·

      Clean up mingw-w64 project some more:

      Note, we might bump the GCC version to something supported while we are at it. What prevents you to bump GCC to 9.2 everywhere? The pthread situation is a bit unfortunate. It doesn't seem that Rust depends on winpthread: https://github.com/rust-lang/rust/issues/13501 Have you changed --enable-threads=posix to --enable-threads=win32? Also you can remove old --with-gnu-ld --with-gnu-as.

      LDFLAGS_FOR_TARGET does not work for some reason. Thus, we take

      CFLAGS_FOR_TARGET.

      It didn't work, because linker didn't want to eat -specs. Try now. Also where are --no-seh, --large-address-aware for x86 and --high-entropy-va, --image-base for x64?

      • libmpc-dev What about bumping GMP, MPFR, MPC with GCC? --enable-sdk=all --enable-secure-api They are no longer needed (set by default).

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

    • Georg Koppen
      Georg Koppen @gk ·
      Author

      Thanks for the suggestions. It seems there are at least two further tickets to file for your suggestions. (Bump GCC to 9.2 everywhere and clean the mingw-w64 project further up=). Could you do so? Thanks! I think we are done here, though, for the moment.

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

    • C
      cypherpunks @cypherpunks ·

      Hah, #31845 (moved) and #31846 (moved) are waiting for you :)

    • Trac closed

      closed

    • Trac changed time estimate to 8h

      changed time estimate to 8h

    • Trac added 16h of time spent

      added 16h of time spent

    • Georg Koppen mentioned in issue #31828 (moved)

      mentioned in issue #31828 (moved)

    • Trac mentioned in issue #30322 (moved)

      mentioned in issue #30322 (moved)

    • Trac moved to tpo/applications/tor-browser#31584 (closed)

      moved to tpo/applications/tor-browser#31584 (closed)

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

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

    Please register or sign in to reply