Cross-compiling and debugging C ++ Windows applications for Linux
Recently I showed an interesting application for which you can develop plugins. The application turned out to be very useful for scientific work, but here's the bad luck - the application was developed under Windows, I have Ubuntu. Windows for development for this application from the lab has not yet been obtained. In order not to waste time, I decided to master the cross-compilation and debugging of this application.
Total available:
Ubuntu 12.10 x64
Non-Unicode Graph-Models Workshop (MGM) application (In console commands, gmw.exe will be called)
Need to:
Develop and debug plug-ins (dll-libraries) without installing Windows.
')
And then Wine, Code :: Blocks, ported GDB, and boost will help us.
When trying to open a non-unicode application under Wine
zyuki of the following form are obtained:
The Internet very quickly gives the following hint to this problem:
In my case, this approach did not improve the situation one iota.
As it turned out, no Russian locales were added to the system ( tyts ).
Now run with the above hint
And, voila, the application with readable Russian text is launched:
In the future, for debugging, we need to change the code of the debugging plug-in, so it is better to immediately take the Code :: Blocks version from under svn.
Install svn:
Using svn, we get the code C :: B, for this we go to the folder where we want to save the code C :: B, where we type:
Go to the resulting folder 'trunk'.
C :: B is compiled using g ++, autotools, automake and some other utilities that need to be installed:
In addition, Code :: Blocks depends on wxWidgets:
Adjust the installer for the computer (you can run it once):
And then, install the codeblocks itself (the --prefix key can be missed to use the default settings):
More details can be viewed at the link .
We carry out points 1 through 5 from the Code :: Blocks forum . After that, compilation of programs should work if linking to platform-dependent libraries is not used (linking with boost :: regexp will be discussed later).
(*) In the new Code :: Blocks, the menu has slightly changed compared to the instructions. Settings you need to look in 'Settings-> Compiler ...'. For the old Code :: Blocks (10.05), point 5 needs to be fully completed; for the new one (12.11), we will not touch the setting relating to gdb in paragraph 5.
If boost is used, it is better to put it separately from / usr / include, since At this address there are many linux-specific header files that we do not want to include in the project when compiling under Windows.
UPD: When setting up a link in the “Other Linker Options” field, it makes sense to add the option “-Wl, - subsystem, windows, - kill-at”, which indicates that this is a real Windows DLL and, most importantly, prohibits the use decorating characters (--kill-at) when exporting functions with the __stdcall calling convention. More here and here .
Starting from point 7 on the link above, cross-debugging is described, but, unfortunately, insight.exe, mentioned in the instructions, cannot be found. So let's go our own way.
gdb, which is native to Linux, partially can debug Windows applications, although it can only dwell on exceptions and almost always ignores breakpoints. To deal with these problems, download gdb in the mingw32 package under Windows. To do this, download and then unpack and go to the 'bin' subfolder. Install gdb under Windows:
Now the gdb.exe file has appeared in the same bin folder, which is what we need.
Create a script to simulate the usual gdb for this in the file / usr / bin / i586-mingw32msvc-gdb
Enter the following lines:
For the old C :: B everything is already configured, for the new debugger you need to configure it additionally. In the 'Settings-> Debugger' item, click on the 'GDB / CDB debugger' then on 'Create Config'. In the new config, we change the debugger launch command to '/ usr / bin / i586-mingw32msvc-gdb', other settings as desired. After that, go to 'Settings-> Compiler ... ", in the' Selected Compiler 'section, select the compiler that you set up before and then on the' Toolchain executables' tab, change 'Debugger' to our newly created config. Now the debugger will stop at breakpoints, although it will not be able to stop the program at an arbitrary moment (this problem has not yet been resolved.) However, when trying to debug, C :: B gives the following error:
This error indicates that the debugger plugin in C :: B does not understand the issue of the gdb.exe debugger. As it turned out, upon closer inspection, the debugger plugin has a platform-specific code, and this is where you need to remember that we have the source code C :: B. We are now slightly correcting the code of this plugin. It will be necessary to change the code of only one file '{Path to svn code of Code :: Blocks} /src/plugins/debuggergdb/gdb_driver.cpp'
To do this, go to the root of the C :: B project (from where the ./bootstrap commands were run), by default it is the 'trunk' folder. And patch the patch :
Well, rebuild Code :: Blocks:
And almost everything is ready, it remains only to create a project. Steps 12-13 here . If you want to create a project dll-library, then specify the creation of a dynamic library in the wizard and rename the extension to dll.
Check that the selected compiler-linker-debugger chain is in the project settings. '{Right key to the project} -Build Options ...' item 'Selected compiler', and you can enjoy and debug. Let me remind you that for some reason the debugger cannot be interrupted during execution, i.e. All debugging actions can be applied only during program shutdown. In particular, you can not put a new breakpoint, if the program is not at any other breakpoint ...
The boost library is basically a set of header files, and therefore no problems with linking usually arise. But for some parts of a boost, you need to link to a static library, for example, boost :: regex. We try to build a project and get:
The error occurs because we are trying to link to the linux library in order to build a windows application.
To link you need to compile boost :: regex using MingW32 ( about cross-compiling ). Download boost, unpack and go to the folder with unpacked boost . Create a user-config.jam file in the root of your home directory:
With the following content:
Further we set up assembly and we collect:
After executing the last command, I had “failed updating 1 target” errors, which, however, does not interfere with programming.
As a result, we have a fully prepared environment for writing, building and debugging Windows applications or Windows libraries from under Linux. Now you can get to work ...
Total available:
Ubuntu 12.10 x64
Non-Unicode Graph-Models Workshop (MGM) application (In console commands, gmw.exe will be called)
Need to:
Develop and debug plug-ins (dll-libraries) without installing Windows.
')
And then Wine, Code :: Blocks, ported GDB, and boost will help us.
Wine, not unicode application, Ubuntu English interface and Russian language
When trying to open a non-unicode application under Wine
wine gmw.exe zyuki of the following form are obtained:
The Internet very quickly gives the following hint to this problem:
LC_ALL=ru_RU.UTF-8 wine gmw.exe In my case, this approach did not improve the situation one iota.
As it turned out, no Russian locales were added to the system ( tyts ).
sudo echo "ru_RU.UTF-8 UTF-8" >> /var/lib/locales/supported.d/ru sudo locale-gen ru Now run with the above hint
LC_ALL=ru_RU.UTF-8 wine gmw.exe And, voila, the application with readable Russian text is launched:
Configuring IDE Code :: Blocks for cross-compiling and debugging
Installing Code :: Blocks
In the future, for debugging, we need to change the code of the debugging plug-in, so it is better to immediately take the Code :: Blocks version from under svn.
Install svn:
sudo apt-get install subversion Using svn, we get the code C :: B, for this we go to the folder where we want to save the code C :: B, where we type:
svn checkout svn://svn.berlios.de/codeblocks/trunk Go to the resulting folder 'trunk'.
C :: B is compiled using g ++, autotools, automake and some other utilities that need to be installed:
sudo apt-get install libtool autotools-dev automake autoconf g++ libhunspell-dev libgtk2.0-dev libgamin-dev libboost-dev In addition, Code :: Blocks depends on wxWidgets:
sudo apt-get install libwxgtk2.8-dev Adjust the installer for the computer (you can run it once):
sudo ./bootstrap And then, install the codeblocks itself (the --prefix key can be missed to use the default settings):
sudo ./configure --prefix={ } --with-contrib-plugins=all sudo make sudo make install More details can be viewed at the link .
Compile and link setup
We carry out points 1 through 5 from the Code :: Blocks forum . After that, compilation of programs should work if linking to platform-dependent libraries is not used (linking with boost :: regexp will be discussed later).
(*) In the new Code :: Blocks, the menu has slightly changed compared to the instructions. Settings you need to look in 'Settings-> Compiler ...'. For the old Code :: Blocks (10.05), point 5 needs to be fully completed; for the new one (12.11), we will not touch the setting relating to gdb in paragraph 5.
If boost is used, it is better to put it separately from / usr / include, since At this address there are many linux-specific header files that we do not want to include in the project when compiling under Windows.
UPD: When setting up a link in the “Other Linker Options” field, it makes sense to add the option “-Wl, - subsystem, windows, - kill-at”, which indicates that this is a real Windows DLL and, most importantly, prohibits the use decorating characters (--kill-at) when exporting functions with the __stdcall calling convention. More here and here .
Starting from point 7 on the link above, cross-debugging is described, but, unfortunately, insight.exe, mentioned in the instructions, cannot be found. So let's go our own way.
Cross-debugging in Code :: Blocks & MingW32 gdb for Windows
gdb, which is native to Linux, partially can debug Windows applications, although it can only dwell on exceptions and almost always ignores breakpoints. To deal with these problems, download gdb in the mingw32 package under Windows. To do this, download and then unpack and go to the 'bin' subfolder. Install gdb under Windows:
wine mingw-get.exe install gdb Now the gdb.exe file has appeared in the same bin folder, which is what we need.
Create a script to simulate the usual gdb for this in the file / usr / bin / i586-mingw32msvc-gdb
sudo gedit /usr/bin/i586-mingw32msvc-gdb Enter the following lines:
#!/bin/sh wine {Path to mingw}/bin/gdb.exe $@ For the old C :: B everything is already configured, for the new debugger you need to configure it additionally. In the 'Settings-> Debugger' item, click on the 'GDB / CDB debugger' then on 'Create Config'. In the new config, we change the debugger launch command to '/ usr / bin / i586-mingw32msvc-gdb', other settings as desired. After that, go to 'Settings-> Compiler ... ", in the' Selected Compiler 'section, select the compiler that you set up before and then on the' Toolchain executables' tab, change 'Debugger' to our newly created config. Now the debugger will stop at breakpoints, although it will not be able to stop the program at an arbitrary moment (this problem has not yet been resolved.) However, when trying to debug, C :: B gives the following error:
The program has stopped on a breakpoint but the breakpoint format is not recognized: 0x1A0x1AZ:{}/SamplePlugin.cpp:48:948:beg:0x68087599 This error indicates that the debugger plugin in C :: B does not understand the issue of the gdb.exe debugger. As it turned out, upon closer inspection, the debugger plugin has a platform-specific code, and this is where you need to remember that we have the source code C :: B. We are now slightly correcting the code of this plugin. It will be necessary to change the code of only one file '{Path to svn code of Code :: Blocks} /src/plugins/debuggergdb/gdb_driver.cpp'
To do this, go to the root of the C :: B project (from where the ./bootstrap commands were run), by default it is the 'trunk' folder. And patch the patch :
patch --unified --strip=0 --forward --input=gdb_driver.cpp.patch Well, rebuild Code :: Blocks:
sudo ./configure --prefix={ } --with-contrib-plugins=all sudo make sudo make install And almost everything is ready, it remains only to create a project. Steps 12-13 here . If you want to create a project dll-library, then specify the creation of a dynamic library in the wizard and rename the extension to dll.
Check that the selected compiler-linker-debugger chain is in the project settings. '{Right key to the project} -Build Options ...' item 'Selected compiler', and you can enjoy and debug. Let me remind you that for some reason the debugger cannot be interrupted during execution, i.e. All debugging actions can be applied only during program shutdown. In particular, you can not put a new breakpoint, if the program is not at any other breakpoint ...
Linking static boost library
The boost library is basically a set of header files, and therefore no problems with linking usually arise. But for some parts of a boost, you need to link to a static library, for example, boost :: regex. We try to build a project and get:
{...}/boost/regex/v4/cpp_regex_traits.hpp|1059|undefined reference to `boost::scoped_static_mutex_lock::scoped_static_mutex_lock(boost::static_mutex&, bool)' The error occurs because we are trying to link to the linux library in order to build a windows application.
To link you need to compile boost :: regex using MingW32 ( about cross-compiling ). Download boost, unpack and go to the folder with unpacked boost . Create a user-config.jam file in the root of your home directory:
gedit ~/user-config.jam With the following content:
using gcc : : i586-mingw32msvc-g++ ; Further we set up assembly and we collect:
sudo ./bootstrap.sh --with-libraries=regex --without-icu sudo ./b2 After executing the last command, I had “failed updating 1 target” errors, which, however, does not interfere with programming.
As a result, we have a fully prepared environment for writing, building and debugging Windows applications or Windows libraries from under Linux. Now you can get to work ...
Source: https://habr.com/ru/post/162171/
All Articles