Essential Cygwin Development Packages

Whenever I want to do a new Cygwin install on Windows, I’d have to just keep scrolling the Cygwin installer window to find the packages that I use frequently. I decided to compile a list of packages I use and put them here so that I wouldn’t have to waste time on it again in the future.

  • Devel:
    1. cmake
    2. cmake-gui
    3. gcc-core
    4. gcc-g++
    5. gdb
    6. git
    7. make
  • Libs:
    1. libboost-devel
  • Python:
    1. python3
  • Shells:
    1. chere (for shell integration)
  • X11: (Needed for cmake-gui)
    1. gnu-free-fonts
    2. xinit

Additionally, I let Cygwin’s installer to auto-install additional required packages. These packages should be sufficient for compiling C/C++ code under Windows. In order to enable shell integration for bringing up a Cygwin terminal, this command should be executed from Cygwin terminal (using administrator privileges) after installation:

chere -i -t mintty

“sys/time.h” Replacement for Windows

Some C/C++ code targeted for GNU family compilers fail to compile under Windows due to the dependency on sys/time.h header file. The repository here has provided a neat implementation for it. Basically you need these three files: time.h, times.h and times.cpp. I have included them here (in case the repository ever went dead). Note that this is not my code and the original license of the code was LGPL.

sys/time.h:

sys/times.h:

sys/time.cpp:

 

 

 

“Unresolved external symbol” Errors when Compiling CGAL 4.7 Under Windows with Visual Studio 2013

I spent hours trying to compile CGAL 4.7 with Visual Studio 2013. Everything compiled on the first try with Visual Studio 2010 but for some reason I was unable to get it working with VS2013. CMake would create the solution files just fine and was able to resolve everything. However, when I attempted to build the confiugured solution I would get lots of “unresolved external” errors like this:

unresolved external symbol "__declspec(dllimport) class boost::system::error_category const & __cdecl boost::system::generic_category(void)

I followed this guide to the letter. I was sure Boost was being discovered just fine. I had everything in my PATH. After a while I figured out what my problem was! Although I wanted to build 64-bit binaries, I was selecting Visual Studio 12 2013 as my generator!! I was skimming every time I was selecting it so I wasn’t paying attention! I should’ve in fact selected Visual Studio 12 2013 Win64 as my generator. Doing that solved the problems.

Cannot Find “getopt.h” File When Compiling Under Windows

Often times, issues arise when compiling C/C++ code developed for Linux under Windows. One annoying problem is when the code requires some header which is only available in the POSIX API. A header commonly used for parsing the command line arguments is getopt.h. Unfortunately, this header is only available under Linux. After some digging around, I found a port of this header file for Windows here.

In case the repository went down in the future, I’ve pasted the code here. All credits go to the original author. Click on the link below for the full code.

Continue reading Cannot Find “getopt.h” File When Compiling Under Windows

C/C++: Code Not Working under a Certain Build Configuration

If your C/C++ code works fine under a certain build configuration (eg. Release) but not under another (eg. Debug) or simply works fine when built with a certain compiler, it is a sign that the code is not robust and some small detail which depends on compiler optimization is producing undefined behavior.

For instance, my code was working fine under Linux (using G++) and also Visual C++ 2013 (using the Release) configuration, but was giving me a hard time under the “Debug” configuration in VC++. Turned out that the compiler optimization under “Release” was preventing a destructor from being called. Since the destructor was never called, no memory leak was occurring. Building under “Debug” would have disabled that optimization and the code would have crashed with a memory leak error!

This just emphasizes how important it is to test the code thoroughly and detect those parts that could lead to undefined behavior.