undefined reference to `__assert_func'

[viperscape]

For some reason I cannot compile this project: https://github.com/viperscape/font-atlas-example/tree/master/atlas-gen, specifically that sub-project atlas-gen. Below is the output during linking. I am using mingw gcc from cygwin (x86_64-w64-mingw32-gcc) with rust-nightly 32bit. It's very possible that this is an issue on my end, as I was able to compile this yesterday; I'm not sure what changed :-( I'm hesitant to install mingw directly because it's housed on sourceforge, which I try to avoid now a days. Any clues to what is going on here? Thanks!

note: C:\Users\chris\font-atlas-example\atlas-gen\target\debug\deps\libminiz_sys-d19b88f9ef21a81d.rlib(miniz.o): In function `tinfl_decompress':
/cygdrive/c/Users/Chris/.cargo/registry/src/github.com-121aea75f9ef2ce2/miniz-sys-0.1.6/miniz.c:1707: undefined reference to `__assert_func'
C:\Users\chris\font-atlas-example\atlas-gen\target\debug\deps\libminiz_sys-d19b88f9ef21a81d.rlib(miniz.o): In function `tdefl_start_dynamic_block':
/cygdrive/c/Users/Chris/.cargo/registry/src/github.com-121aea75f9ef2ce2/miniz-sys-0.1.6/miniz.c:2024: undefined reference to `__assert_func'
/cygdrive/c/Users/Chris/.cargo/registry/src/github.com-121aea75f9ef2ce2/miniz-sys-0.1.6/miniz.c:2026: undefined reference to `__assert_func'
/cygdrive/c/Users/Chris/.cargo/registry/src/github.com-121aea75f9ef2ce2/miniz-sys-0.1.6/miniz.c:2027: undefined reference to `__assert_func'
/cygdrive/c/Users/Chris/.cargo/registry/src/github.com-121aea75f9ef2ce2/miniz-sys-0.1.6/miniz.c:2030: undefined reference to `__assert_func'
C:\Users\chris\font-atlas-example\atlas-gen\target\debug\deps\libminiz_sys-d19b88f9ef21a81d.rlib(miniz.o):/cygdrive/c/Users/Chris/.cargo/registry/src/github.com-121aea75f9ef2ce2/miniz-sys-0.1.6/miniz.c:2031: more undefined references to `__assert_func' follow

$ gcc --version
gcc (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ rustc --version
rustc 1.5.0-nightly (168a23ebe 2015-10-01)

$ cargo --version
cargo 0.6.0-nightly (7f21e73 2015-10-01)

[alexcrichton]

Hm interesting, perhaps some header files are getting mixed up? Could you gist the full output of the build script when a failure is hit, and also past the output of rustc -vV?

[viperscape]

https://www.refheap.com/110216

$ rustc -vV
rustc 1.5.0-nightly (168a23ebe 2015-10-01)
binary: rustc
commit-hash: 168a23ebe1729386138fa71643382fdd64fac205
commit-date: 2015-10-01
host: i686-pc-windows-gnu
release: 1.5.0-nightly

I'm going to uninstall everything and try again. Not sure what's wrong

[viperscape]

I resolved it somehow, I think git for windows somehow was the issue because ultimately removing that from my path fixed this issue. I looked around and never found anything relating to gcc in there, except for licenses. Thanks for getting my on the right track

[alexcrichton]

Whoa that's weird... perhaps it was mixing in header files by accident? I was next gonna suggest that maybe gcc was getting mixed up (e.g. flate2 compiled with one and linking with another), but glad to hear that it's working at least now!

[Zarathustra30]

I'm getting the same issue, though only when enabling lto. However, git for windows isn't even on my path.

C:\Users\William\AppData\Local\Temp\rustc.Dze3jbe4m8SP\libminiz_sys-fa48ce1a538dca79.rlib(miniz.o):miniz.c:(.text$tdefl_compress_lz_codes+0x382): undefined reference to `__assert_func'
C:\Users\William\AppData\Local\Temp\rustc.Dze3jbe4m8SP\libminiz_sys-fa48ce1a538dca79.rlib(miniz.o):miniz.c:(.text$tdefl_compress_lz_codes+0x43a): undefined reference to `__assert_func'
ld: C:\Users\William\AppData\Local\Temp\rustc.Dze3jbe4m8SP\libminiz_sys-fa48ce1a538dca79.rlib(miniz.o): bad reloc address 0x43a in section `.text$tdefl_compress_lz_codes'

rustc 1.3.0 (9a92aaf19 2015-09-15)
cargo 0.4.0-nightly (553b363 2015-08-03) (built 2015-08-03)

This only started when I ran cargo update. Temporary workaround: Disable lto.

[alexcrichton]

Hm that's odd, do you have multiple gcc binaries in your PATH perchance? Or perhaps a nonstandard install of gcc? (or is this MSVC?)

[Zarathustra30]

I think I just have Cygwin, unless Python or PowerShell have one.

[viperscape]

Can you paste your path here? Both user profile path and system path

[Zarathustra30]

%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Python27\;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\MiKTeX 2.9\miktex\bin;C:\UTIL;C:\UTIL\ffmpeg\bin;C:\Program Files (x86)\WinMerge;C:\cygwin64\bin

C:\Program Files\Rust stable 1.3\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Python27\;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\MiKTeX 2.9\miktex\bin;C:\UTIL;C:\UTIL\ffmpeg\bin;C:\Program Files (x86)\WinMerge;C:\cygwin64\bin

[alexcrichton]

Hm I can't seem to reproduce this locally in cygwin, is there a way that I could reproduce locally? Also it could be that the wrong header file was picked up perhaps, but I'm not sure how it could have leaked in in the first place...

[viperscape]

So I don't know if this issue should stay closed, probably because it's really an environment issue. I think this is how to fix it though, so @Zarathustra30 give this a try:

Uninstall gcc and mingw in cygwin. Then make sure all are actually uninstalled when you go to reinstall. Select just one mingw64, since I have rust 32bit installed I chose i686 version. If you have 64bit then try amd x86_64. Once installed, I copied i686-w64-mingw32-gcc.exe in cygwin bin folder as a gcc.exe. This seemed to clear up my issues, otherwise I received errors on some projects complaining gcc was not installed-- ironically not projects that included this library, so I don't know what that means. See if that works for you.

[rphmeier]

I am also running into this. Using an MSYS2 configuration with

$ rustc -vV
rustc 1.5.0 (3d7cd77e4 2015-12-04)
binary: rustc
commit-hash: 3d7cd77e442ce34eaac8a176ae8be17669498ebc
commit-date: 2015-12-04
host: x86_64-pc-windows-gnu
release: 1.5.0

$ cargo -vV
cargo 0.6.0-nightly (e1ed995 2015-10-22)

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-msys/4.9.2/lto-wrapper.exe
Target: x86_64-pc-msys
Configured with: /msys_scripts/gcc/src/gcc-4.9.2/configure --build=x86_64-pc-msys --prefix=/usr --libexecdir=/usr/lib --enable-bootstrap --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --with-arch=x86-64 --disable-multilib --with-tune=generic --enable-__cxa_atexit --with-dwarf2 --enable-languages=c,c++,fortran,lto --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --disable-win32-registry --disable-symvers --with-gnu-ld --with-gnu-as --disable-isl-version-check --enable-checking=release --without-libiconv-prefix --without-libintl-prefix --with-system-zlib
Thread model: posix
gcc version 4.9.2 (GCC)

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/c/ProgramData/Oracle/Java/javapath:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/c/Program Files (x86)/Windows Kits/8.1/Windows Performance Toolkit:/c/Program Files/Microsoft SQL Server/110/Tools/Binn:/c/Program Files (x86)/Microsoft SDKs/TypeScript/1.0:/c/Program Files (x86)/Skype/Phone:/e/Program Files (x86)/Microsoft VS Code/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

I removed git for windows from my path, as suggested above. I am currently stumped how to fix this.

[alexcrichton]

This may happen if rustc disagrees on the linker and/or gcc that's being used by the build script, so are there perhaps multiple gcc installations lying around?

[rphmeier]

No, just the one from MSYS2.
which gcc and which ld both indicate they are installed in /usr/bin, pacman -Qe | grep gcc brings up only one version of gcc and gcc-libs.

However, it appears that the rust installation itself provides a full gcc toolchain. The gcc crate emits the following flags when compiling:
"-L" "E:\\msys64\\home\\Habermeier\\.multirust\\toolchains\\stable\\bin\\rustlib\\x86_64-pc-windows-gnu\\lib"

Which makes me believe that it is compiling with the gcc I installed through pacman, but trying to link against the libgcc provided with rustc. It might even try to use the rustc-provided ar/ld, further exacerbating the problem.

I would really prefer not to remove the gcc package from my MSYS2 installation. Is there another way I can fix this?