Fixing Cross Compilation for Windows Executable

[k10blogger]

I had a bit of a trouble cross compiling the tools for usage on windows.

Two issues came up that are fixed with the two lines here.

1. Undefined reference to nanosleep that was resolved by adding the lpthread library

/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccDZPiC1.o:fel.c:(.text+0x22ef): undefined reference to `nanosleep'

2. Dependency on the dll

        DLL Name: KERNEL32.dll
        DLL Name: msvcrt.dll
        DLL Name: libwinpthread-1.dll
        DLL Name: WS2_32.dll
        DLL Name: zlib1.dll

Which was reduced to only the basic ones by static linking the libraries.

DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: WS2_32.dll`

[paulkocialkowski]

It looks like you are doing two unrelated things in one commit. It should be split in two.

Then I don't see the benefit of switching from dynamic to static libraries. We generally use dynamic libraries, why would it be better to use static?

On the nanosleep issue, I am not very aware of what the normal thing to do is, but it seems that winpthread does provide a nanosleep implementation. Maybe a comment should be added above the line that includes it to clarify why it is needed, since the relationship with pthread is not very obvious.

And does it work with -lwinpthread? It would maybe be a bit better to use it instead.

[paulkocialkowski]

From the list of DDLs you posted, it seems that cygwin is not present. Maybe we should use it instead? Apparently there is a nanosleep implementation in libgloss.

[k10blogger]

I am using mingw in linux for cross compilation on windows, not cygwin.

As it is part of the windows only build invocation. The lpthread links the libwinpthread library. (This can be cross confimed by the first list of dlls). Both lpthread and lwinpthread links to the same library when buiding for windows. I can change to lwinpthread if needed and it makes it understand that it is windows library. Let me know if this change needs to be done.

As to why i am preferring static linkage is because. Windows by default comes with these 3 dll (KERNEL32.dll, msvcrt.dll, WS2_32.dll). These stay on the C:\Windows\System32 path.
The dynamic library zlib1.dll and libwinpthread-1.dll would then need to be explicitly downloaded or compiled. It is better for exe portability if these are statically linked. Moreover if these are not found there is no failure message that pops up. Sometimes making it incredibly difficult to figure things out what is missing.
With static linking i can just move the exe out of the build system and use directly on any windows machine without worrying about having the dependent dlls.

[paulkocialkowski]

Yes I think using lwinpthread, along with a comment explaining why it is needed would be best.

Regarding static build, again I am not too aware of how software distribution generally works with Windows. If producing statically-linked binaries is common practice to distribute Windows software, we could do that too. I remember some software shipping with extra dlls in the same directory, but I guess the end result is the same as having everything into a single binary.

On the other hand it also seems fine to me to tell users they should have the dlls of required dependencies installed. But we probably don't want to have an installer or something similar to deal with it.

[k10blogger]

Changed to -lwinpthread and added a comment.

I too dont want to have to deal with an installer or a bundler so i rather have it statically linked.