enable_ansi_support(): error LNK2019: unresolved external symbol

[jakwings]

Compiling failed on AppVeyor CI.

See the logs of the failed builds: https://ci.appveyor.com/project/sharkdp/fd/build/1.0.197

[volks73]

I would like to add that I have also experienced the LNK2019 error. I was using the stable-i686-pc-windows-msvc toolchain from the Developer Prompt installed with the C++ Built Tools 2017 configured for the x86 environment. When I try to build my project using the stable-x86_64-pc-windows-msvc toolchain from the Developer Prompt configurd for the x64 environment, everything builds successfully.

Here is a snippet of the error message that displays the linker error.

note: libansi_term-90d9c9360c432cc8.rlib(ansi_term-90d9c9360c432cc8.ansi_term15.rust-cgu.o) : 
error LNK2019: unresolved external symbol __imp__GetStdHandle referenced in function 
__ZN9ansi_term7windows19enable_ansi_support17h52d3ee1de6502c43E
          libansi_term-90d9c9360c432cc8.rlib(ansi_term-90d9c9360c432cc8.ansi_term15.rust-cgu.o) : 
error LNK2019: unresolved external symbol __imp__GetLastError referenced in function 
__ZN9ansi_term7windows19enable_ansi_support17h52d3ee1de6502c43E
          libansi_term-90d9c9360c432cc8.rlib(ansi_term-90d9c9360c432cc8.ansi_term15.rust-cgu.o) : 
error LNK2019: unresolved external symbol __imp__SetConsoleMode referenced in function 
__ZN9ansi_term7windows19enable_ansi_support17h52d3ee1de6502c43E

When I remove the ansi_term crate from the project, the build is successful with the stable-i686-pc-windows-msvc toolchain. It appears the problem is related to enabling ansi support and the i686 toolchain. I am not sure how to go about resolving the problem, but I am happy to help in any way I can.

[retep998]

Your functions have the wrong signatures. It only manifests in a linking failure on 32bit due to the stdcall calling convention name decoration. I personally recommend getting your bindings from winapi and not trying to bind them yourself.

[pravic]

Funny enough that it is reproduced only with release build. At least in Aaronepower/tokei#173.

[glebpom]

There are already two pull-requests fixing this issue. #33 by @volks73 and #35 by me. I think this bug is pretty critical because clap relies on this crate, so a lot of software fails to compile for 32bit windows platform

[volks73]

I agree with @retep998 and @glebpom that using the winapi crate should be preferred, so please use the #35 pull request to resolve this issue.

[pravic]

It looks like @ogham is unavailable.

What Rust community does in such situations?

[glebpom]

From crates policies:

If someone wants to take over a package, and the previous owner agrees, the existing maintainer can add them as an owner, and the new maintainer can remove them. If necessary, the team may reach out to inactive maintainers and help mediate the process of ownership transfer.

[pravic]

Oh my: https://crates.io/crates/ansi_term/reverse_dependencies

I've sent a letter to @ogham but he didn't respond. However he's quite active on SO still, so no idea why this project is unmaintained so long.

[ogham]

Hi everyone,

I'm really sorry this took me an age to merge -- I'll try to be a better steward of my crate in the future.

Version v0.11 was published just now with the PR included.

[sharkdp]

@ogham Thank you very much!

I'm really sorry this took me an age to merge -- I'll try to be a better steward of my crate in the future.

Don't let anyone stress you out. This is an open source project, after all.

[rivy]

Should this be closed now?

[jakwings]

Not sure. I don't have a Windows machine or Rust project with AppVeyor CI enabled for testing at the moment. :wink:

[rivy]

Hmm, I think I can help with that ... PR#46. Completed testing at https://ci.appveyor.com/project/rivy/rust-ansi-term/builds/23029890. 🙂