[SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

Trilby · 2016-01-28 16:09:23

I have a software project that was originally written for linux, but for the past year I've been trying various approaches to rewrite it to be platform independant. I have an SFML branch here that I've been working on. Note that this branch doesn't yet do anything particularly useful, but now that I am confident that I can complete the project in SFML, I want to ensure that I can actually compile it for windows before I put the work into completing it.

Unfortunately I'm completely clueless on buidling software for windows ... completely.

Allegedly Mingw should be able to cross compile for windows but I'm not having any luck. I've installed the mingw-64-toolchain group, as well as mingw versions of two of my project's dependencies from the AUR (mingw-w64-fftw and mingw-w64-sfml). I have a Makefile for windows on the above linked github page: Makefile.win.

I also have a Makefile.win.static, though that is much more clueless flailing. Provided I can confirm all licensing allows it, I may prefer to make this a fully statically linked binary that can be distributed as a single file without needing to ship DLLS - so if anyone has input on that, I'd love to learn how to do this. But for the time being, I'm working on what I hope to be a simpler build with dynamic libs.

In Makefile.win I have the build directives, and also a "bundle" directive that copies all the mingw provided dlls and bundles them in a tar.gz. The build process proceeds without errror, then I move this bundle to my windows test machine, extract, and attempt to run the exe. But I just get a dialog box with the error described here that libgcc-sjlj-1.dll is missing. According to that thread this should be solved by adding -static-libgcc to the linker line. So I added "-static-libgcc" to the LDLIBS line, and rebuilt again without error. But I still get the exact same error message on the Windows machine when I try to run the binary: libgcc-sjlj-1.dll is missing.

EDIT: for at least diagnostic purposes, I also copied the libgcc-sjlj-1.dll provided by the mingw-w64-gcc package to the windows computer. Now I get a different error on the windows machine for a different missing lib: libwinpthread-1.dll

The Infinity · 2016-02-20 03:19:29

You already figured out that you just need to add the *.dll files from mingw-w64-gcc. The *.dll files from mingw-w64-winpthreads (dependency of mingw-w64-gcc) are required as well.

I guess the question here is why these aren't already pulled when adding your project's dependencies.
1. When not cross compiling you usually don't think about gcc-libs as dependency because it belongs to the base group. This is not the case for the mingw-w64-* toolchain because mingw-w64-gcc does not belong the base{,-devel} groups.
2. Adding mingw-w64-gcc to the dependencies of your project would solve the problem. I'm not sure why this is usually not done (see https://wiki.archlinux.org/index.php/Mi … guidelines) and why there is no mingw-w64-gcc-libs split package as in the regular toolchain.

To your attempt by adding "-static-libgcc":
1. This will link statically against the standard lib. Hence it is not required anymore. That the lib from mingw-w64-winpthreads is still required is the case because the statically linking was only done partially. Linking statically against the theading lib should resolve this issue.
2. However, I wouldn't recommend linking statically for the same reasons we usually don't link statically under GNU/Linux. Just provide the *.dll files.
3. Additionally, I wouldn't hardcode the architecture. You might also want to build a x86_64 version.

I also have a Makefile.win.static, though that is much more clueless flailing.

All your dependencies must be present as static libraries. I think mingw-w64-sfml from the AUR does only provide a dynamic linkable version of sfml. Static libs are the *.a files but don't confuse them with the *.dll.a files (*.dll.a files are only import libs used when linking dynamically).

Unfortunately I'm completely clueless on buidling software for windows

That's what I'm always doing: I actually create PKGBUILDs for my apps (eg. https://aur.archlinux.org/packages/mingw-w64-tageditor). As you can see in the example, I'm using the cmake build system which works very well with the mingw-w64-cmake package. CMake also allows to add a resource file with version and description of your app quite easily. I'm also bundeling my apps. However, I'm using a self-written tool which performs dependency resolution, extracts all required *.dll/*.exe files from the mingw-w64-* packages and puts everything together in a tarball for i686 and one for x86_64 (eg. https://martchus.no-ip.biz/repo/win/x86 … 2-all.zip).
(Don't know, if its a good solution, but it works for me and I dislike installers anyways.)

Last edited by The Infinity (2016-02-22 18:32:52)

Trilby · 2016-02-20 03:40:39

Thanks for the input. Some of the files I refer to no longer exist (at least not in the current github repo). First I gave up on static linking, but then I tried doing it again after reading more. The mingw sfml package does include the .a libs, but statically linking still fails. I still need to include all the sfml dlls, the libgcc dll, and even when that is added I get an error about the pthreads dll - I gave up at that as it seems to be an infinite regress: every new lib added requires others. I'm not going to ask users to install a whole operating system worth of libs to run one program - they may as well just install a different OS on a VM at that point.

I do want to get static linking working as I think that is the only way this program will ever be distributable to the people for whom a windows build would be desirable. Otherwise there's really no point in me bothering to make it cross platform in the first place.

The Infinity · 2016-02-20 16:04:59

I'm not going to ask users to install a whole operating system worth of libs to run one program.

I wouldn't consider deploying some *.dll files "installing a whole operating system". If you have a look at the distribution of other apps you see that its not uncommon to link dynamically against some libs. The tarball from my example is only so big because it contains applications using wxWidgets, Qt 5, GTK 2 and GTK 3 so 4 graphical tool kits must be included.

I still need to include all the sfml dlls

Then it is not linked statically. However if you finally link statically against sfml the same problem as you have with the threading lib might occur (only partial static linkage). This problem could be solved in the same way as the problem with the threading lib.

Trilby · 2016-02-20 16:36:06

The Infinity wrote:

I wouldn't consider deploying some *.dll files "installing a whole operating system".

I would, if I get stuck in a (near) infinite regress of including several more dlls for each single one I include.

Steef435 · 2016-02-20 17:43:03

I've always heard that statically linking was way easier for Windows (never done it though) because including all those dlls is a pain, so maybe that route will be easier. I did some random digging and apparently you also need -static-libstdc++ next to -static-libgcc to solve the missing libgcc-sjlj-1.dll. So I think you should at least include: -static -static-libgcc -static-libstdc++ -lpthread -lsfml-all.

Trilby · 2016-02-20 17:45:21

Thanks Steef, I'm away from my Windows VM, but I'll try that on Monday. I did have all of those except for -lpthread, and it still gave errors until the sfml and libgcc dlls were present, and then there were yet others.

The Infinity · 2016-02-20 19:30:16

Trilby wrote:

I would, if I get stuck in a (near) infinite regress of including several more dlls for each single one I include.

That's why I wrote a tool for that. But the code is currently to messy to share.

Using "-static -static-libgcc -static-libstdc++ -lpthread -lsfml-all" as Steef435 proposed prevents linking with shared libs AT ALL. I didn't thought about that option because I never use it but it should work. You could also use "-static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread ...".

By the way, don't force static linkage in your project's makefile. Leave it up to the user whether he wants to build link statically or dynamically.

Trilby wrote:

I'm away from my Windows VM

You can test your application with Wine, too. Wine is also able to run a tool called DependencyWalker which is quite useful to retrace the actual dependencies of your application after building. (Its does the same as "readelf -d".)

Last edited by The Infinity (2016-02-22 18:34:46)

Trilby · 2016-02-20 22:06:52

The Infinity wrote:

By the way, don't force static linkage in your're projects makefile.

The windows makefile is only for my use. I'll be distributing the binary for windows users. The target userbase would not have the slightest idea how to compile anything - they just want the tool to work. That's why I'm going through all this in the first place. If I could leave it up to them to build it I could actually just focus on the code which I'm pretty good at.

Trilby · 2016-02-22 14:40:07

I just got this running on Windows this morning (there are runtime issues, but I can work with that as it's from my code). But the only way for this to run on windows was to copy over every single dll included with the mingw toolchain. This was the case whether it was built with static or dynamic linking. The statically linked binary was as large as the dynamically linked binary plus all the dlls - but the statically linked binary still required that all the dlls be present. I have no idea how that could be.

But as long as I can get it distributable, I can wait on someone who knows how to compile for windows to make it cleaner.

4144 · 2017-03-07 20:38:01

Trillby, you can try mxe from here: https://github.com/mxe/mxe

It allow build static and shared all packages inside and own apps.
Look like it create really static binaries, without any dlls.

But mingw inside have some limitation. Works only gcc 5 based compiler. gcc 6 have issues with -O3. Also in both compilers lto is broken.

hipersayan_x · 2017-03-31 05:16:50

Trilby wrote:

But the only way for this to run on windows was to copy over every single dll included with the mingw toolchain. This was the case whether it was built with static or dynamic linking. The statically linked binary was as large as the dynamically linked binary plus all the dlls - but the statically linked binary still required that all the dlls be present.

I run in the same problem. This is because if your are linking with at least one dynamic library (.dll or .so), then your executable becomes dynamically linked and you need to include all gcc and glibc dependencies, no matter if you use the -static* flags. All mingw-w64-* packages in AUR are dynamically linked, so if you want a fully static binary, then you must compile all your dependency tree statically.

Also, just in case, you can list all required dependencies for your executables and dll files with the command *-w64-mingw32-objdump -x file.dll | grep 'DLL Name' | awk '{print $3}'. Hope it helps.

Arch Linux

#1 2016-01-28 16:09:23

[SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

#2 2016-02-20 03:19:29

Re: [SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

#3 2016-02-20 03:40:39

Re: [SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

#4 2016-02-20 16:04:59

Re: [SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

#5 2016-02-20 16:36:06

Re: [SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

#6 2016-02-20 17:43:03

Re: [SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

#7 2016-02-20 17:45:21

Re: [SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

#8 2016-02-20 19:30:16

Re: [SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

#9 2016-02-20 22:06:52

Re: [SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

#10 2016-02-22 14:40:07

Re: [SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

#11 2017-03-07 20:38:01

Re: [SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

#12 2017-03-31 05:16:50

Re: [SOLVED] Mingw cross compiling for win32- libgcc_s_sjlj-1.dll missing

Board footer