Advice on building on appveyor for GNU target

[steveklabnik]

Hey there!

This is likely a bug in my project, rather than a bug in cargo-update, but I wanted to ask some advice. Currently, here's a failing build: https://ci.appveyor.com/project/steveklabnik/kernel/build/job/q0ntqfgte41r529a

  = note: C:\Users\appveyor\AppData\Local\Temp\1\cargo-install.NrnbniSQAEoB\release\deps\liblibgit2_sys-a5d90d29dc2660db.rlib(diff_print.c.obj):diff_print.c:(.text$git_diff_print_callback__to_file_handle+0x5b): undefined reference to `__imp___acrt_iob_func'
          C:\Users\appveyor\AppData\Local\Temp\1\cargo-install.NrnbniSQAEoB\release\deps\liblibgit2_sys-a5d90d29dc2660db.rlib(util.c.obj):util.c:(.text$printf+0x29): undefined reference to `__imp___acrt_iob_func'
          C:\Users\appveyor\AppData\Local\Temp\1\cargo-install.NrnbniSQAEoB\release\deps\liblibgit2_sys-a5d90d29dc2660db.rlib(util.c.obj):util.c:(.text$printf.constprop.3+0x25): undefined reference to `__imp___acrt_iob_func'
          C:\Users\appveyor\AppData\Local\Temp\1\cargo-install.NrnbniSQAEoB\release\deps\liblibgit2_sys-a5d90d29dc2660db.rlib(util.c.obj):util.c:(.text$printf.constprop.4+0x25): undefined reference to `__imp___acrt_iob_func'
          C:\Users\appveyor\AppData\Local\Temp\1\cargo-install.NrnbniSQAEoB\release\deps\liblibgit2_sys-a5d90d29dc2660db.rlib(cache.c.obj):cache.c:(.text$printf+0x29): undefined reference to `__imp___acrt_iob_func'

I see that in your appveyor.yml, you are installing some stuff. Are users expected to do that too? What stuff should I add, specifically?

Thanks!

[mati865]

It's caused by differences between mingw-w64 headers and crt, reported here rust-lang/rust#47048

If you are using MSYS2 then Rust internal mingw libraries are much older than ones found in the system.

[nabijaczleweli]

As an addendum to that, if you want a hotfix – https://github.com/nabijaczleweli/cargo-update/blob/master/appveyor.yml#L16-L17. I did the equivalent of that manually on my system and it works quite fine, so…

[NovemberZulu]

The weird thing is I am able to build git2 and libgit2-sys without that workaround...

[nabijaczleweli]

On my machine, building is cool and good, linking to them is harder. Also, it's nigh-impossible to reproduce on other people's machines (this is, in fact, the only time I've heard of someone also experiencing this).

[NovemberZulu]

My understating was that git2 links to libgit2-sys, so linking errors should still occur.

[nabijaczleweli]

Having fixed this again literally 23 minutes ago, I can in fact confirm that it only happens during executable linking (i.e. to .exe and .dll (because DLLs are executable, because ~~Windows~~)).

Your logic is slightly flawed, because git2 links to libgit2-sys statically, i.e. it doesn't until you're linking an exec.

[NovemberZulu]

I think I am getting it now: git2 does not produce an .exe/.dll, so no linking occurs. Is it correct?

[nabijaczleweli]

Yes.

[NovemberZulu]

Guess I was expecting the linker to be more smart that it actually is :) Thanks for the explanation!

[mati865]

Explained here rust-lang/rust#47048 (comment)

[nabijaczleweli]

Have all issues been resolved here, or are things still brewing?

[mati865]

Three is another workaround: rust-lang/rust#47048 (comment)
However none of the devs seems to care about it.

[nabijaczleweli]

That workaround sounds like a lot more work than the one I implement, even more fun that nobody seems to care :v

What course of axion do you recommend?
My first thought was to make something like @nex3's PATH guide in format, with a detailed guide describing and about fixing this issue, but that seems like a solution for individual people rather than a generic one, so :v

[mati865]

Only viable solution is fixing Rust.
I'll try to bump GCC they are using but it's gonna take time.

[nabijaczleweli]

Okay, well that's a bit out of my ballpark, so genuinely good luck with that, and let's just make this issue track fixing Rust to the point where it doesn't happen.

[CAD97]

Update: windows-gnu seems to be breaking at the build script stage.

Install attempt

C:\Users\cad97>rustup show
Default host: x86_64-pc-windows-gnu

installed toolchains
--------------------

stable-x86_64-pc-windows-gnu
beta-x86_64-pc-windows-gnu
nightly-x86_64-pc-windows-gnu (default)

active toolchain
----------------

nightly-x86_64-pc-windows-gnu (default)
rustc 1.31.0-nightly (77af31408 2018-10-11)


C:\Users\cad97>cargo install cargo-update --force
    Updating crates.io index
  Installing cargo-update v1.6.3
   Compiling pkg-config v0.3.14
   Compiling winapi-x86_64-pc-windows-gnu v0.4.0
   Compiling cc v1.0.25
   Compiling winapi v0.3.6
   Compiling version_check v0.1.5
   Compiling proc-macro2 v0.4.20
   Compiling libc v0.2.43
   Compiling unicode-xid v0.1.0
   Compiling matches v0.1.8
   Compiling unicode-normalization v0.1.7
   Compiling serde v1.0.79
   Compiling cfg-if v0.1.5
   Compiling ucd-util v0.1.1
   Compiling regex v1.0.5
   Compiling unicode-width v0.1.5
   Compiling percent-encoding v1.0.1
   Compiling embed-resource v1.1.4
   Compiling vec_map v0.8.1
   Compiling utf8-ranges v1.0.1
   Compiling semver-parser v0.7.0
   Compiling bitflags v1.0.4
   Compiling strsim v0.7.0
   Compiling json v0.11.13
   Compiling array_tool v1.0.3
   Compiling unicode-bidi v0.3.4
   Compiling lazy_static v1.1.0
   Compiling memchr v2.1.0
   Compiling log v0.4.5
   Compiling regex-syntax v0.6.2
   Compiling textwrap v0.10.0
   Compiling tabwriter v1.1.0
   Compiling cargo-update v1.6.3
   Compiling libz-sys v1.0.24
   Compiling libssh2-sys v0.2.11
   Compiling curl-sys v0.4.13
   Compiling libgit2-sys v0.7.10
error: failed to run custom build command for `cargo-update v1.6.3`
process didn't exit successfully: `D:\Temp\cargo-installLWcyGe\release\build\cargo-update-d935fe03e503727c\build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Failed to execute windres: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }', libcore\result.rs:1009:5
stack backtrace:
   0: std::sys::windows::backtrace::unwind_backtrace
             at libstd\sys\windows\backtrace/mod.rs:104
             at libstd\sys\windows\backtrace/mod.rs:91
   1: std::sys_common::backtrace::print
             at libstd\sys_common/backtrace.rs:71
             at libstd\sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:476
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: rust_begin_unwind
             at libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::result::unwrap_failed
   9: embed_resource::windows_not_msvc::compile_resource
  10: embed_resource::compile
  11: std::rt::lang_start::{{closure}}
  12: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  13: _rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  14: std::panicking::try
             at libstd/panicking.rs:289
  15: std::rt::lang_start_internal
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  16: main
  17: _tmainCRTStartup
  18: mainCRTStartup
  19: unit_addrs_search
  20: unit_addrs_search

warning: build failed, waiting for other jobs to finish...
error: failed to compile `cargo-update v1.6.3`, intermediate artifacts can be found at `D:\Temp\cargo-installLWcyGe`

Caused by:
  build failed

[nabijaczleweli]

That's out of scope of this issue for several reasons:

1. This is an embed_resource issue (which I also maintain, so no worries, reopen there), and
2. Looks like a broken install of binutils (which maybe is just weird, and I'd then lofta support it in embed_resource).

[nabijaczleweli]

Hmmm, ran across this crate while searching for something unrelated...