Adjust gcc runtime library handling in windows build

[tkelman]

I keep going back and forth on this. This is going back to using the opensuse runtime libs (and adding libwinpthread since they've switched threading models), which might help with jump-dev/Ipopt.jl#77 but may also change at any moment which could suddenly break appveyor if nightlies pull in some ABI incompatibility...

[vchuravy]

Does OpenSuse 42.2 still provide GCC 4.9.2 compatibility? Looking at the repositories they seem to only provide 6.2.
They also provide a version of libatomic [1] and we should start to include that. This would allow us to revert #19647
and resolve atomics correctly on windows [2, 3].

[1] http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_42.2/noarch/mingw32-libatomic1-6.3.0-1.1.noarch.rpm
[2] #19123 (comment)
[3]

julia/src/jitlayers.cpp

Lines 313 to 327 in d3bac6e

	#if defined(_OS_LINUX_)
	// Resolve non-lock free atomic functions in the libatomic library.
	// This is the library that provides support for c11/c++11 atomic operations.
	static uint64_t resolve_atomic(const char *name)
	{
	static void *atomic_hdl = jl_load_dynamic_library_e("libatomic",
	JL_RTLD_LOCAL);
	static const char *const atomic_prefix = "__atomic_";
	if (!atomic_hdl)
	return 0;
	if (strncmp(name, atomic_prefix, strlen(atomic_prefix)) != 0)
	return 0;
	return (uintptr_t)jl_dlsym_e(atomic_hdl, name);
	}
	#endif

[tkelman]

They only provide 6.2, which is why this is sort of fragile. Until we fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333 or fix libgmp's build system so clang can build it properly on windows, we will have to stick with cygwin's old 4.9.2 compiler in order for the buildbots to still be capable of building win32 julia correctly (ref #18162). So Julia and deps will continue to be built using cygwin's 4.9.2, but we're replacing the runtime dll's with those from opensuse so packages from winrpm work. This isn't guaranteed to work, we get somewhat lucky that it does. We actually had already been replacing the runtime dll's in the binaries with an older gcc 5 set from opensuse that I saved, rather than the latest version from opensuse which is subject to change over time.

[vchuravy]

Yeah that's what I thought. So we can't depend on libatomic currently?

[tkelman]

In what sense? We can't currently assume the compiler used to build Julia has libatomic, so we couldn't add it as a call to std_dll. We could add it to the list we call winrpm.sh on and put it in the binaries if it would serve some purpose to do so.

[tkelman]

osx travis failure was #17626, appveyor failure was #19707

[huckl3b3rry87]

While the backport for 0.5 is pending, is there an easy manual fix for this issue?

[tkelman]

Yeah, should be just copy the libgfortran-3.dll libquadmath-0.dll libstdc++-6.dll libgcc_s_s*-1.dll libssp-0.dll libwinpthread-1.dll files from joinpath(WinRPM.installdir, "usr", Sys.MACHINE, "sys-root", "mingw", "bin") to JULIA_HOME. If you want to test JuliaPackaging/WinRPM.jl#97, that should do it automatically.

[zhengys18]

@tkelman this is @huckl3b3rry87 and I am trying to get some code to work on a labmates computer, but when I run https://github.com/JuliaPackaging/WinRPM.jl/pull/97/files I get

Also, thank for the quick response!

[tkelman]

I wasn't accounting for the possibility of that file not being there yet, thanks for testing! Try JuliaPackaging/WinRPM.jl@9bee07c

[zhengys18]

Thanks for the response！ I downloaded the file from
https://osdn.net/projects/sfnet_sixtyfourbitcompiles/downloads/64bit/libwinpthread-1.dll/
Not sure if that is a sketchy site, but it works!

And I put it in the /bin.

Thanks!

[zhengys18]

I tried to delete the program and try your patch but after I deleted it when I start julia I get

It is working if I just put the program in /bin though

[tkelman]

Delete the newer copies and rename the -copy backups to what they used to be. Or take them from a clean install of Julia.

[queueyong]

This fixes my problem. Now Ipopt is well working, thanks.