Building POCO C++ with Mingw

I've been looking for a logging framework for C++. I'd read about several options, but hadn't really found anything I felt like trying, until a couple of days ago, when I discovered POCO C++.

I decided to give it a try, but the README seemed to be warning me I was in for some Interesting Times(TM):

Microsoft Visual Studio 7.1 (2003), 8.0 (2005), 9.0 (2008) or 10.0 (2010) is required to build the POCO C++ Libraries on Windows platforms.

BTW, the emphasis is mine.

Still, nothing new, just another OSS telling users of OSS on Windows: "You're on your own".

Before I go on, I've solved these problems on my own, but if I had searched the POCO Forum, I would've saved some time, as someone had posted solutions to all the problems I found. I did google it, but sometimes google is not enough.

I fired Msys and ran configure. I didn't follow README's advice, however, and didn't run make -s. I prefer having as much info available as possible, thank you very much, so I ran it with --debug and -w.

The first problem came in the form of an unrecognized option: -mno-cygwin. I looked in the <POCO_HOME>/build/config/MinGW file, and found these lines:

SHLIB   = $(CXX) -shared -mno-cygwin -o $@ -Wl,--out-implib=$(dir $@)$(subst cyg,lib,$(basename $(notdir $@))).a

SYSFLAGS = -mno-cygwin -D_WIN32 -DMINGW32 -DWINVER=0x500 -DPOCO_NO_FPENVIRONMENT -DPCRE_STATIC -DPOCO_THREAD_STACK_SIZE -DFoundation_Config_INCLUDED -I/usr/local/include -I/usr/include

A couple of searches, and I realized this option didn't apply to my version of gcc, so I removed it.

Then, the linker complained it couldn't find OpenSSL libs ssl and crypto. Having built OpenSSL, I had those libs, so I added another -L to this line, pointing to the OpenSSL libs (once again, in <POCO_HOME>/build/config/MinGW file):

SYSLIBS  = -L/usr/local/lib -L/usr/lib -liphlpapi -lws2_32 -lssl -lcrypto -lws2_32 -lgdi32

Another go at make, and this time I got an error with strip. After making sure I hadn't inadvertently linked in my porn collection (it is rather sizable, and tends to show up in the most embarrassing places), I've decided to google strip. And then, naturally, strip command.

From what I've learned, it's nothing I should actually worry about at this stage, although it is something interesting to look into later on. So, I've decided to remove it from the <POCO_HOME>/build/config/MinGW file, by turning this

STRIP   = strip

into this

STRIP   =

And there you go, we have build! I've built the Logger example, and I plan on giving it a try on my own project.

And now for something slightly completely different: A semi-rant...

MS is preparing to cripple the next version of VC++ Express, which the POCO C++ blog also refers in this post.

I fail to see what's the drama, actually. Maybe now all the people behind OSS can actually direct their effort at creating a better support for OSS on Windows, instead of just saying "There you go, have these VC++ files and enjoy".

Organizing OSS on Windows

In my old days as a developer, the development environment was a simple affair. I had an IDE, and it would take care of most of my equally simple needs.

The first time I had to deal with installing/configuring additional components/libs was with Delphi. But even that was simple. Same thing with C++ Builder. The most complex thing I remember doing back then was installing SGI STL. And even that was simple.

These days... as I said, if you're working on Windows, you either use Visual C++, or you're in for a whole lotta work. Thankfully, you're also in for a whole lotta learning.

So, after installing or building perl, OpenSSL, zlib, libssh2, Boost, mingw, msys, git, msysgit, msmtp, etc, my HD is a bit of a mess. You can't properly plan for what you don't know, and I never found (in truth, never looked for, either) a guide on how to organize these things on Windows.

So, I've decided to roll my own. It all boils down to 3 points:

• Includes
• Binaries
• PATH (for additional utilities)

I'll start with two main folders

• tool
• lib

tool will have stuff like perl, mingw + msys, git, msysgit, or msmtp. These are not libraries, they're tools necessary for the job. Where possible, I'll have a main folder for each tool (e.g., msmtp), which will contain a folder for each different version (e.g., msmtp-1.4.27, msmtp-1.4.28). It's important to keep track of your PATH (on System, on Windows Control Panel), to make sure it's pointing to the version you want.

lib will follow the same principle. Taking libssh2 as an example, I would have a main folder, say libssh2, and sub-folders for libssh2-1.4.1 and libssh2-1.4.2. When dealing with libraries, we have to take care of the include and lib paths. Include is rather simple, but lib has several options - dynamic vs. static and debug vs. release.

gcc (and that's 3 consecutive paragraphs starting in lowercase) uses dynamic linking, by default. This means if the lib path contains both a dynamic and a static version of the same lib, it'll use the dynamic (and, naturally, it'll require it at runtime). So, where possible, I'll try to have two lib folders - one with dynamic libs (both debug and release), and another with static libs (also, both debug and release).

Another advantage of having your own main folder above the lib's/util's main folder is that it gives you a handy and - hopefully - uncluttered location for any notes you may find useful (e.g., how to configure msmtp to use your gmail account to send e-mail). Yes, I know there's a plethora of utilities to store these notes and to sync with more cloudy devices than you care to imagine. This is just another alternative.

And that pretty much covers it all for now. When I do get around to clean up this mess, I'll post the results here.