Build failure on Windows: #39

jeroen · 2018-05-04T22:37:23Z

The lodepng dependency problem is fixed, but now it fails like below. Is this a problem with my gcc?

   Compiling wild v0.1.1
   Compiling gif v0.9.2
   Compiling kernel32-sys v0.2.2
   Compiling imagequant-sys v2.11.9
   Compiling crossbeam-utils v0.2.2
   Compiling num_cpus v1.8.0
   Compiling lodepng v2.1.5
   Compiling gif-dispose v2.1.0
   Compiling crossbeam-epoch v0.3.1
   Compiling crossbeam-deque v0.2.0
error: linking with `gcc` failed: exit code: 1
  |
  = note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-Wl,--large-address-aware" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\dllcrt2.o" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\rsbegin.o" "-L" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\imagequant_sys-f6a62ba14f74e711.imagequant_sys0-f5c8c61e9753212fc2f5e5c2991a4af6.rs.rcgu.o" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\imagequant_sys-f6a62ba14f74e711.imagequant_sys1-f5c8c61e9753212fc2f5e5c2991a4af6.rs.rcgu.o" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\imagequant_sys-f6a62ba14f74e711.imagequant_sys2-f5c8c61e9753212fc2f5e5c2991a4af6.rs.rcgu.o" "-o" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\imagequant_sys-f6a62ba14f74e711.dll" "-Wl,--version-script=C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\rustc.evs7Io2gLfdR\\list" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\imagequant_sys-f6a62ba14f74e711.crate.allocator.rcgu.o" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps" "-L" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\release\\deps" "-L" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\build\\imagequant-sys-96ebfd2eb1e88e00\\out" "-L" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib" "-Wl,-Bstatic" "-Wl,--whole-archive" "-l" "imagequant" "-Wl,--no-whole-archive" "C:\\projects\\gifski\\gifski.Rcheck\\00_pkg_src\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\librgb-effc7185392cff7d.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libstd-7d1b8f671c6600f1.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libpanic_unwind-366f3877c2c9fb8a.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libunwind-f979bb52af5245af.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\liblibc-f8976d50c9357b07.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\liballoc_system-3800d261ecc181c1.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\liballoc-bfabd4c61c613469.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libstd_unicode-cf317c34da92a23b.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libcore-fab41fba8f33ac45.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libcompiler_builtins-e0875e0e27f2835e.rlib" "-Wl,-Bdynamic" "-l" "advapi32" "-l" "ws2_32" "-l" "userenv" "-l" "shell32" "-Wl,-Bstatic" "-l" "gcc_eh" "-l" "pthread" "-shared" "-Wl,-Bdynamic" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-lmsvcrt" "-luser32" "-lkernel32" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\rsend.o"
  = note: ld: unrecognized option '--large-address-aware'
          ld: use the --help option for usage information
          
error: aborting due to previous error
The following warnings were emitted during compilation:
warning: nearest.c: In function 'nearest_init':
warning: nearest.c:136:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: nearest.c: In function 'nearest_search':
warning: nearest.c:190:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: nearest.c: In function 'nearest_free':
warning: nearest.c:195:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: kmeans.c: In function 'kmeans_init':
warning: kmeans.c:26:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: kmeans.c: In function 'kmeans_update_color':
warning: kmeans.c:36:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: kmeans.c: In function 'kmeans_finalize':
warning: kmeans.c:64:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: kmeans.c: In function 'kmeans_do_iteration':
warning: kmeans.c:93:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: mediancut.c: In function 'mediancut':
warning: mediancut.c:408:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: mempool.c: In function 'mempool_create':
warning: mempool.c:50:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: mempool.c: In function 'mempool_alloc':
warning: mempool.c:61:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: mempool.c: In function 'mempool_destroy':
warning: mempool.c:70:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: pam.c: In function 'pam_computeacolorhash':
warning: pam.c:66:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: pam.c: In function 'pam_add_to_hash':
warning: pam.c:157:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: pam.c: In function 'pam_allocacolorhash':
warning: pam.c:177:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: pam.c: In function 'pam_acolorhashtoacolorhist':
warning: pam.c:233:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: pam.c: In function 'pam_freeacolorhash':
warning: pam.c:241:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: pam.c: In function 'pam_freeacolorhist':
warning: pam.c:247:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: pam.c: In function 'pam_colormap':
warning: pam.c:264:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: pam.c: In function 'pam_duplicate_colormap':
warning: pam.c:273:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: pam.c: In function 'pam_freecolormap':
warning: pam.c:278:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: pam.c: In function 'to_f_set_gamma':
warning: pam.c:285:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: blur.c: In function 'liq_max3':
warning: blur.c:91:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: blur.c: In function 'liq_min3':
warning: blur.c:118:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
warning: blur.c: In function 'liq_blur':
warning: blur.c:132:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
warning:  }
warning:  ^
error: Could not compile `imagequant-sys`.
warning: build failed, waiting for other jobs to finish...
error: build failed

The text was updated successfully, but these errors were encountered:

kornelski · 2018-05-04T22:49:06Z

It looks like you're trying to cross-compile 64-bit to 32-bit using MinGW, and MinGW doesn't support that.

Try using 32-bit MinGW to compile MinGW executables, or
Use MSVC version of Rust, or
Drop support for 32-bit. It's been 12 years since the last notable Windows-compatible 32-bit CPU was released.

jeroen · 2018-05-04T22:53:32Z

I'm writing bindings for the R programming language. Our toolchain has both x32 and x64 compilers. How does rust find the proper gcc.exe? Does it just take whatever is first in the path? Can I pass it custom paths to gcc for WIN32 and WIN64 somehow?

kornelski · 2018-05-04T23:22:55Z

There's *-gnu target that searches for MinGW only, and *-msvc target that looks up Visual Studio installation it the registry.

Run:

rustup default stable-x86_64-pc-windows-msvc

to switch.

jeroen · 2018-05-04T23:32:17Z

Our entire system is compiled with the mingw-w64 toolchain, so it won't link with msvc.

I think I need something like this to point rust to the correct toolchain: rust-lang/cc-rs#82

kornelski · 2018-05-05T00:32:05Z

Doesn't rustup default stable-i686-pc-windows-gnu help for the 32-bit build? It still finds a 64-bit MinGW!?

jeroen · 2018-05-05T09:24:53Z

I added this to my ~/.cargo/config file:

[target.x86_64-pc-windows-gnu]
linker = "c:/Rtools/mingw_64/bin/gcc"

[target.i686-pc-windows-gnu]
linker = "c:/Rtools/mingw_32/bin/gcc"

That seems to have some effect but unfortunately my toochain is static so rust is passing the wrong libs to the linker.

kornelski · 2018-05-05T10:53:23Z

I'm not sure what you mean by the toolchain being static.

jeroen · 2018-05-05T12:25:11Z

Our mingw-w64 gcc toolchain is configured as described here. Because it has been configured with --static-gcc we do not have to pass linker flags to ssh_eh.

Also our toolchain has been compiled with pthreads support.

For whatever reason that does not seem to work well with rust: https://ci.appveyor.com/project/jeroen/gifski/build/1.0.23

jeroen · 2018-05-05T12:30:07Z

I don't really understand how/where rust is invoking the gcc compiler. It is complaining about missing pthread symbols. Usually when we compile an application that requires pthreads we need to pass -pthread both to CFLAGS as well as LIBS. How would that work for a cargo crate?

kornelski · 2018-05-05T15:43:40Z

There are two places where Rust invokes C compiler:

When making static libraries from your dependencies' C source code (e.g. gifski depends on libimagequant, which compiles C code). This isn't really done by Rust itself, but by the cc crate (it supports the CC env var) or custom build scripts.
When linking everything together

In the first case every dependency is responsible for declaring which libraries are needed by printing linking info in their build scripts.

In the second case you shouldn't need to do anything at all if Rust is installed correctly and dependencies aren't buggy.

If some buggy dependency failed to declare it needs libpthread, you may work around it by adding build.rs to your project that prints cargo:rustc-link-lib=pthread (I haven't tried this though).

jeroen · 2018-05-05T16:27:41Z

Thanks for your help!

The weird thing is that the line that fails does have -lpthread already, twice even. But maybe I need to add -pthread to the CFLAGS in order to activate the proper macros.

  = note: "c:/Rtools/mingw_32/bin/gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-Wl,--large-address-aware" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\dllcrt2.o" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\rsbegin.o" "-L" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\imagequant_sys-f6a62ba14f74e711.imagequant_sys0-f5c8c61e9753212fc2f5e5c2991a4af6.rs.rcgu.o" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\imagequant_sys-f6a62ba14f74e711.imagequant_sys1-f5c8c61e9753212fc2f5e5c2991a4af6.rs.rcgu.o" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\imagequant_sys-f6a62ba14f74e711.imagequant_sys2-f5c8c61e9753212fc2f5e5c2991a4af6.rs.rcgu.o" "-o" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\imagequant_sys-f6a62ba14f74e711.dll" "-Wl,--version-script=C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\rustc.jcMSx8yQyCkh\\list" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\imagequant_sys-f6a62ba14f74e711.crate.allocator.rcgu.o" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps" "-L" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\release\\deps" "-L" "C:\\projects\\gifski\\GIFSKI~1.RCH\\00_PKG~1\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\build\\imagequant-sys-96ebfd2eb1e88e00\\out" "-L" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib" "-Wl,-Bstatic" "-Wl,--whole-archive" "-l" "imagequant" "-Wl,--no-whole-archive" "C:\\projects\\gifski\\gifski.Rcheck\\00_pkg_src\\gifski\\src-i386\\myrustlib\\target\\i686-pc-windows-gnu\\release\\deps\\librgb-effc7185392cff7d.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libstd-7d1b8f671c6600f1.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libpanic_unwind-366f3877c2c9fb8a.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libunwind-f979bb52af5245af.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\liblibc-f8976d50c9357b07.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\liballoc_system-3800d261ecc181c1.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\liballoc-bfabd4c61c613469.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libstd_unicode-cf317c34da92a23b.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libcore-fab41fba8f33ac45.rlib" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\libcompiler_builtins-e0875e0e27f2835e.rlib" "-Wl,-Bdynamic" "-l" "advapi32" "-l" "ws2_32" "-l" "userenv" "-l" "shell32" "-Wl,-Bstatic" "-l" "gcc_eh" "-l" "pthread" "-shared" "-Wl,-Bdynamic" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-lmsvcrt" "-luser32" "-lkernel32" "C:\\Users\\appveyor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\i686-pc-windows-gnu\\lib\\rsend.o"
  = note: c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2.o): In function `_gthread_once':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:703: undefined reference to `pthread_once'
          c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2-fde.o): In function `_gthread_mutex_init_function':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:736: undefined reference to `pthread_mutex_init'
          c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2-fde.o): In function `_gthread_once':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:703: undefined reference to `pthread_once'
          c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2-fde.o): In function `_gthread_mutex_lock':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:752: undefined reference to `pthread_mutex_lock'
          c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2-fde.o): In function `_gthread_once':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:703: undefined reference to `pthread_once'
          c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2-fde.o): In function `_gthread_mutex_lock':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:752: undefined reference to `pthread_mutex_lock'
          c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2-fde.o): In function `_gthread_once':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:703: undefined reference to `pthread_once'
          c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2-fde.o): In function `_gthread_mutex_lock':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:752: undefined reference to `pthread_mutex_lock'
          c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2-fde.o): In function `_gthread_mutex_unlock':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:782: undefined reference to `pthread_mutex_unlock'
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:782: undefined reference to `pthread_mutex_unlock'
          c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2-fde.o): In function `_gthread_once':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:703: undefined reference to `pthread_once'
          c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2-fde.o): In function `_gthread_mutex_lock':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:752: undefined reference to `pthread_mutex_lock'
          c:/Rtools/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.9.3/libgcc.a(unwind-dw2-fde.o): In function `_gthread_mutex_unlock':
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:782: undefined reference to `pthread_mutex_unlock'
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:782: undefined reference to `pthread_mutex_unlock'
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:782: undefined reference to `pthread_mutex_unlock'
          C:\msys2-rtools\home\Jeroen\mingw-gcc-4.9.3\i686-493-posix-dwarf-rt_v3-s\build\gcc-4.9.3\i686-w64-mingw32\libgcc/./gthr-default.h:782: undefined reference to `pthread_mutex_unlock'
          collect2.exe: error: ld returned 1 exit status

kornelski · 2018-05-05T16:55:19Z

Your paths still show mix of "x86_64" and "i686". It's possible that it's not seeing symbols, because it's looking for 32-bit ones in a 64-bit library.

You're making it extra hard by doing cross-compilation. Use 32-bit Rust for 32-bit executables. With Rustup it's trivial to switch back and forth, you don't need to reinstall anything.

jeroen · 2018-05-07T14:11:43Z

OK I found the issue.

My mingw-w64 toolchain is OK, however our build does not have libgcc_eh.a because these object are part of libgcc.a (in the same toolchain directory). As a workaround I created a copy of libgcc.a and renamed it libgcc_eh.a and then linking works.

Now I need to figure out why rust insists on linking against -lgcc_eh and if that is something I can suppress to link against -lgcc instead.

jeroen · 2018-05-07T14:39:51Z

Do you know where the call that links gcc_eh comes in? Is it here? https://github.com/rust-lang/rust/blob/385ef1514c80fb8c0cb061dc69eb1d953a84e2b3/src/libunwind/build.rs#L38

kornelski · 2018-05-07T19:39:08Z

libunwind handles panic!() in Rust. Panics use the same mechanism as exception handling, and gcc_eh is a library for exception handling.

libgcc and libgcc_eh are distinct, so I'm surprised the renaming worked :) GCC should always have this library, so if it's not found, it maybe due to missing library search path or mix-up of toolchains.

You could try adding to Cargo.toml:

[profile.release]
panic = "abort"

which disables panics and theoretically makes the library unnecessary, but I don't know if that will save you from it being linked.

jeroen · 2018-05-07T19:55:42Z

Right, compiling with rustflags =-C panic=abort will avoid the need for dwarf objects however rust still hardcodes the -lgcc_eh linker flag so we need to work around that :-(

The problem is not the path but that our gcc has been configured with --static-gcc so therefore all runtime libs get included with libgcc.a which is what applications usually link to.

jeroen closed this as completed May 19, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Build failure on Windows: #39

Build failure on Windows: #39

jeroen commented May 4, 2018 •

edited

Loading

kornelski commented May 4, 2018 •

edited

Loading

jeroen commented May 4, 2018

kornelski commented May 4, 2018

jeroen commented May 4, 2018

kornelski commented May 5, 2018 •

edited

Loading

jeroen commented May 5, 2018

kornelski commented May 5, 2018

jeroen commented May 5, 2018

jeroen commented May 5, 2018

kornelski commented May 5, 2018 •

edited

Loading

jeroen commented May 5, 2018

kornelski commented May 5, 2018 •

edited

Loading

jeroen commented May 7, 2018

jeroen commented May 7, 2018

kornelski commented May 7, 2018

jeroen commented May 7, 2018

Build failure on Windows: #39

Build failure on Windows: #39

Comments

jeroen commented May 4, 2018 • edited Loading

kornelski commented May 4, 2018 • edited Loading

jeroen commented May 4, 2018

kornelski commented May 4, 2018

jeroen commented May 4, 2018

kornelski commented May 5, 2018 • edited Loading

jeroen commented May 5, 2018

kornelski commented May 5, 2018

jeroen commented May 5, 2018

jeroen commented May 5, 2018

kornelski commented May 5, 2018 • edited Loading

jeroen commented May 5, 2018

kornelski commented May 5, 2018 • edited Loading

jeroen commented May 7, 2018

jeroen commented May 7, 2018

kornelski commented May 7, 2018

jeroen commented May 7, 2018

jeroen commented May 4, 2018 •

edited

Loading

kornelski commented May 4, 2018 •

edited

Loading

kornelski commented May 5, 2018 •

edited

Loading

kornelski commented May 5, 2018 •

edited

Loading

kornelski commented May 5, 2018 •

edited

Loading