undefined reference to `__assert_func' #27
Comments
|
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 |
|
https://www.refheap.com/110216 I'm going to uninstall everything and try again. Not sure what's wrong |
|
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 |
|
Whoa that's weird... perhaps it was mixing in header files by accident? I was next gonna suggest that maybe |
|
I'm getting the same issue, though only when enabling lto. However, git for windows isn't even on my path. This only started when I ran |
|
Hm that's odd, do you have multiple |
|
I think I just have Cygwin, unless Python or PowerShell have one. |
|
Can you paste your path here? Both user profile path and system path |
|
|
|
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... |
|
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. |
|
I am also running into this. Using an MSYS2 configuration with I removed git for windows from my path, as suggested above. I am currently stumped how to fix this. |
|
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? |
|
No, just the one from MSYS2. However, it appears that the rust installation itself provides a full gcc toolchain. The gcc crate emits the following flags when compiling: 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? |
|
Just for kicks, I decided to remove the gcc package installed via pacman, and the problem is still the same. Seems like the gcc crate prefers the gcc toolchain packaged with rust, which is fundamentally broken on my machine. Edit: Installing with the mingw-w64 package recommended in the rust readme has fixed my minimal test case (at https://gist.github.com/rphmeier/5e63dedbafa9c7f9242c) but miniz-sys still fails to compile. |
|
Check thru your local path and your system path, it should be merged unless one is too long. I would suggest copying out your whole path except win sys directories and restart and then add back in manually just what would be needed. It'd be great to figure out what the cause of this is! |
|
Yes the rust gcc shouldn't be in PATH at all in theory |
|
That's the weird thing: Rust gcc is not in PATH (and never was any time I checked: |
|
This may also have to do with various link paths going wrong, for example if you compile code with the system gcc but then rustc links code with its bundled gcc, they can disagree on runtime libraries (e.g. this goes awry). When you get a chance, can you try to confirm which gcc is being used to compile the C code and which is being used to link the code? |
|
I have confirmed that the gcc crate is using the system gcc. Because of the linker errors, I'd assume that the rustc gcc is being used to link the code. Is the gcc crate supposed to prefer rustc gcc? |
|
Hm, the gcc crate doesn't really have a preference one way or another (it just calls |
Currently we run sub-commands with a different PATH so they can find the bundled `gcc.exe` that we ship with the `*-windows-gnu` host compilers. The current logic, however, *prepends* to `PATH` which means that if the system has a `gcc` installed it will not be used over the bundled `gcc`. This can cause problems, however, if the system gcc is used to compile native code and the Rust compiler then links everything with the bundled gcc. The standard library in both situations can be subtly different (the C standard library), and this can lead to errors such as rust-lang/flate2-rs#27. This commit switches the ordering by appending our own tools to `PATH` instead of prepending, so the system tools will be favored over the bundled ones (which are intended to only be used as a last resort anyway).
|
Ok, I've opened a PR against rust-lang/rust for this: rust-lang/rust#31131 |
Removes a C dependency that fails to compile sometimes on windows. See rust-lang/flate2-rs#27
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!
The text was updated successfully, but these errors were encountered: