[TUTORIAL] Compiling the DLL on Linux
Getting the DLL to compile using wine isn’t nearly as trivial as it is on Windows. But in the process of getting rid of my previous hacky Makefile setup I mostly figured this out, so I decided to write a guide for it.
Prerequisites
— A PC with a Linux distribution. I’ve done this on several distributions and haven’t found one that this didn’t work on.
— Civ 4 installed with wine. This is trivial if you have the GOG version, just winetrick msxml3 and d3dx9. See the winehq page for further information.
— Basic Linux knowledge. You should at least know stuff like how paths work and how to use wine in a terminal emulator.
Step 0: Getting the source code
You should probably have it by now, but if you don’t, and want to start from scratch, clone Leoreth’s repo at https://github.com/dguenms/beyond-the-sword-sdk.
Step 1: Getting wine 1.7
Why do we need such an ancient version of wine?, you might ask — and rightly so, wine 1.7 was released 5 years ago. Well as it turns out, most newer versions don’t work with the VC++ 2003 compiler and will cause an internal compiler error. 1.8 or 1.9 might work as well, I just haven’t tried. 2.0 definitely didn’t work for me.
Luckily, PlayOnLinux provides an easy way to get wine 1.7. After installing it, go to Tools->Manage Wine Versions. Then select wine 1.7.55 (on the x86 tab), and install it. You won’t need PlayOnLinux after this.
You should now be able to locate your wine executable in ~/.PlayOnLinux/wine/linux-x86/1.7.55/bin. I like to move this to a ~/.wine_versions folder so that its path is ~/.wine_versions/linux-x86/1.7.55/bin/wine.
Now create a new wineprefix using
$ export WINEPREFIX=~/compile_linux; ~/.wine_versions/linux-x86/1.7.55/bin/wine winebootAfter this, you should have a 32-bit wineprefix in the ~/compile_linux folder.
Step 2: Getting the Visual C++ 2003 Toolkit and the Platform SDK
For the VC++ 2003 Toolkit I like to use Leoreth’s installer. Install this in your regular wineprefix (presumably in .wine, using your system-wide wine command), then move the .wine/drive_c/Program Files/Microsoft Visual C++ Toolkit 2003 folder to ~/compile_linux/drive_c/Program Files.
Delete the PSDK folder, it won’t work. Instead, download this installer from Microsoft. Mount and install it in your regular wineprefix (next next finish, though you may want to select the Core SDK only in the custom install option). Now you should have a Program Files/Microsoft Platform SDK folder; move this to ~/compile_linux/drive_c/Program Files as well.
Step 3: Getting fastdep
You will need a fastdep binary compatible with the build script. For this you’ll have to clone my patched version like this:
$ svn checkout https://github.com/bptato/RFC-Greek-World/trunk/CvGameCoreDLL/bin/fastdep-0.16Place the resulting folder in your CvGameCoreDLL/bin folder, and optionally compile fastdep using make if you can’t/don’t want to use the binary I compiled.
Step 4: Compiling the DLL
This should be the easiest step if you’ve done everything correctly. I’ve made a shell script which functions like the Makefile (probably not perfect but it works; suggestions are welcome); just save https://raw.githubusercontent.com/bptato/RFC-Greek-World/master/CvGameCoreDLL/compile.sh in your DLL folder.
Then make sure the variables in compile_settings.sh match your setup. Specifically, PYTHON and BOOST should point to an existing folder; I placed these in my DLL folder, since this version of wine can behave weird with absolute paths outside of the wineprefix. If you really want to use absolute paths (to e.g. put your Python/Boost folders in your civ folder as recommended in Nightinggale’s makefile thread), use something like «Z:$HOME/your/path». Also make sure the FASTDEP variable points to your fastdep binary.
Finally, make compile.sh executable:
$ ./compile.sh [release/debug/final_release]You can also use [clean] to remove the Release/, Debug/, Final_release/, or if no target was specified, all of these folders.
And that’s it!
Further notes
The final_release target (idea from advciv’s makefile) performs whole program optimization. This means that linking takes ages, but you supposedly get a somewhat faster DLL.
Also, by default, the script will spawn a child process for checking and compiling every single cpp file to make use of all available processing power. While this speeds up compilation on my (hexa-core) system, it may actually be slower than running a single process on systems with a low amount of cores. Change PARALLEL=true to PARALLEL=false in compile_settings.sh to disable this.
For editing the sources, any text editor works. Those that I’ve found so far with somewhat usable code completion support are Geany, and vim/neovim with the OmniCppComplete plugin. CodeBlocks’s completion also works nicely, but it’s a huge pain to set up (an ancient windows version is required, which of course can’t use compile.sh). And I haven’t the slightest clue how to get the clangd language server to cooperate, unfortunately.
Debugging can be done with winedbg, see this page for further information. Most of the time you’ll want to use the info proc (get civ 4’s process id), attach (attach to a running instance of civ 4), cont (after attaching) and bt (get backtrace) commands.
How to Use the Dynamic Link Library in C++ Linux (gcc compiler)?
The Dynamic Link Library (DLL) is stored separately from the target application and shared among different applications, compared to Static Library. The DLL is the file extension on Windows while on Linux, it is *.so (Shared Object).
The *.so/*.dll can be loaded right before the application starts or during the application’s runtime. On Windows, the Win32 API LoadLibrary is used while on Linux gcc compiler, the dlopen function is used.
Creating *.so on Windows
There are many ways and many languages to create a *.so on Linux e.g. You can write a C or C++ source code and compile it with the following command:
gcc -shared -o libhello.so -fPIC hello.c
gcc -shared -o libhello.so -fPIC hello.c
Example hello.c that exports the hello function:
int hello() return 8; // my lucky number >
Let’s do this slightly differently. In this post, we learn that you can now use Delphi to compile the source code into Linux 64-bit Server native code directly.. So, let’s do this by creating a tiny Delphi DLL/*.so library. This library exports a single function that takes a double and returns its double value.
And, as you hit F9 to build, you will have the libProject6.so file, the Linux *.so library (if you change target platform to Windows, the code will be compiled into Project6.dll automatically, that is the beauty of the Delphi IDE).
How to Use the Dynamic Link Library in C++ Linux (gcc compiler)?
Copy the file to Ubuntu and create the following C/C++ source code in the same directory.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
// https://helloacm.com/how-to-use-the-dynamic-link-library-in-c-linux-gcc-compiler/ #include #include #include // function export from the *.so typedef double (*double_ptr)(double); int main(int argc, char **argv) char *error; double_ptr GetDouble; void *handle; // open the *.so handle = dlopen ("./libProject6.so", RTLD_LAZY); if (!handle) fputs (dlerror(), stderr); exit(1); > // get the function address and make it ready for use GetDouble = (double_ptr)dlsym(handle, "GetDouble"); if ((error = dlerror()) != NULL) fputs(error, stderr); exit(1); > // call the function in *.so printf ("%f\n", (*GetDouble)(2.0)); // remember to free the resource dlclose(handle); >
// https://helloacm.com/how-to-use-the-dynamic-link-library-in-c-linux-gcc-compiler/ #include #include #include // function export from the *.so typedef double (*double_ptr)(double); int main(int argc, char **argv) < char *error; double_ptr GetDouble; void *handle; // open the *.so handle = dlopen ("./libProject6.so", RTLD_LAZY); if (!handle) < fputs (dlerror(), stderr); exit(1); >// get the function address and make it ready for use GetDouble = (double_ptr)dlsym(handle, "GetDouble"); if ((error = dlerror()) != NULL) < fputs(error, stderr); exit(1); >// call the function in *.so printf ("%f\n", (*GetDouble)(2.0)); // remember to free the resource dlclose(handle); > The RTLD_LAZY resolves undefined symbols when code from the dynamic library is executed, which is faster to open. Alternatively, RTLD_NOW resolves all undefined symbols before dlopen returns and fails if this cannot be done.
Compile the source code using (-ldl, the Interfaces for Dynamic Loader):
How to compile c++ to Dll file in Ubuntu
Now I can compile successfully by using make file provided, now I want to compile the project to dll file, how should I modify the make file? The make file is:
default: all # ------------------------------------------------------------------- # Change the path to Z3 4.1.1 accordingly # The directory indicated by this path should contain "lib" and "bin" # e.g. "/home/z3_src_4.1.1" # "/home/work/tool/z3/z3_src_4.1.1" # ------------------------------------------------------------------- Z3_path = ../z3 JUNK = S3 SOURCE = strTheory.cpp testMain.cpp INCLUDE = $(Z3_path)/lib LIB = $(Z3_path)/bin/external all: $(SOURCE) g++ -std=c++14 -O3 -fopenmp -static -I$(INCLUDE) -L$(LIB) $(SOURCE) -lz3 -lrt -o S3 -Wall @echo "" clean: rm -f $(JUNK) In a Unix environment, a shared libraries is not called dll , it’s called shared object and they’ll present the .so extension.
@RaelGugelminCunha Thanks for comments, because I want to call them by using C# code in windows, any suggestions for that?
1 Answer 1
From your comment I assume you are asking about
This is an entirely different subject. It requires more than just changing your makefile. However, this question has been asked before:
If your project is in C or C++ you can use MinGW tools and the same sort of linux based compile tools that use gcc/g++. You can install MinGW like this:
sudo apt-get install gcc-mingw32
If your project is mainly for C#, you might be better off with MonoDevelop. From their website:
MonoDevelop enables developers to quickly write desktop and web applications on Linux, Windows and Mac OS X. It also makes it easy for developers to port .NET applications created with Visual Studio to Linux and Mac OS X maintaining a single code base for all platforms.