You are not logged in.

#1 2019-11-14 19:30:37

bepaald
Member
Registered: 2016-10-08
Posts: 3

Cross compiling to windows

Hi!

So I have a project written in c++ (https://github.com/bepaald/signalbackup-tools). I have been trying, and failing to create a windows executable from this code.

The program is a command line program, and depends only on sqlite3, crypto++ and the standard libraries. The program compiles fine with g++, clang++ and mingw without any errors or warnings. In it's simplest form, just "g++ -std=c++2a */*.cc main.cc -lsqlite3 -lcryptopp" would produce a working linux program. Similarly, I have installed mingw-w64-gcc as well as mingw-w64-crypto++ and mingw-w64-sqlite to get a windows build. Calling:

$ x86_64-w64-mingw32-g++ -static-libgcc -static-libstdc++ -static -std=c++2a -L/usr/x86_64-w64-mingw32 */*.cc *.cc -lcryptopp -lsqlite3

creates an executable without any errors or warnings. However, running the exe, either through wine or in a Windows 10 VM doesn't seem to work. The program runs for a bit, but stops somewhere during its execution without any errors or unexpected output, just suddenly I'm back at the prompt (I also tried this at a friend once on an actual on-hardware Windows installation, with the exact same results).

I have very limited windows skills, have no idea how to debug something like this. Anyone with more experience cross-compiling? Any clue what could be going wrong?

Thanks!

Offline

#2 2019-11-20 19:22:06

NeoZelux
Member
Registered: 2012-10-28
Posts: 43

Re: Cross compiling to windows

hey the first week or so of trying to cross compile for windows on my laptop was a nightmare for me, being awake all night and whatnot. I'll try to share some of the troubleshooting steps that helped me get through it.



What I like to do now is make a small test suite of software that tries to run various things ie hello world, play sine wave, open a window etc.
But where I like to start is the most basic main function that's not even hello world but returns a specific value like 69 or something.
you can see the return value of exit codes with something like

echo %ERRORLEVEL%


From there I'd incrementally test larger programs until i see which one doesn't run.
So in addition if you're trying to test different libraries I would go through each step testing one library at a time,
you also have to make sure that you actually use some code that makes the executable ~need~ the library you are testing.

If you only link to it but mingw-w64 sees that you don't actually ever call any code that needs it I believe it omits the reference to the dll
in the executable.

I found the dependency walker "depends"  very useful in this undertaking, and you can verify what I just claimed with it too.
It's probably a good idea to code minimally when testing each library works, rather than testing all the stuff the library offers I'm suggesting
you test one solitary thing the library does and maybe print the result or return it as an exit code to verify it ran successfully, then progress from there.

another useful thing I'd like to mention is the windows api function

int MessageBox(
  HWND    hWnd,
  LPCTSTR lpText,
  LPCTSTR lpCaption,
  UINT    uType
);


last i checked windows has documentation for it here https://docs.microsoft.com/en-us/window … messagebox
I like to use it to display exceptions that abort the whole program because i find it working when all other things in the software fail (text libraries, graphics etc)
It makes those popup error/notification windows with the ok button show up.


Another thing that got me, the default max stack size on my win laptop is like 3 or 4 MB and on my linux desktop is ~8MB, and I had some naughty functions that ran at startup that didn't segfault on linux but would segfault on windows.


gdb will probably catch something like that so if you can get it easily on your target platform it's something to consider.


Another disparity to mention is the sizes of integers on different platforms. This can really lead to messed up stuff like dividing by 0 in the middle of normal expressions that would be fine if all the types were 64bit but maybe on windows or some android they are 32bit and multipyling a and b overflows to a negative number etc.


So you could revisit a lot of the expressions that involve multiplication at some point and make sure that the multipy operations convert to a type big enough to hold the result.

example



long posA,posB,portion ;
...
position1 = posA * portion  /1000 + posB * portion /1000 ; // long is 32bit on some platforms and 64bit on others, if posA * portion results in 5billion that will overflow on the 32bit platforms even though 5billion /1000 can be stored as a 32bit integer

And Lastly, logging is a great practice for big programs. If you log to a file and flush the output near suspect lines of code you could see at what point the program failed that way as well.
I consider logging a good mechanism when you have all the other rudimentary facilities working, at the least you'd probably want to write some kind of test "hello logging" program
to make sure your logging mechanism works right.


I've tested this stuff mostly on windows 10 and a little bit on win 7.

I may have misunderstood which phase of testing you're at when I first started typing this, but even if you got past the hello world-y parts of cross compiling I think alot of it still applies.

Offline

Board footer

Powered by FluxBB