Build on Windows

Asked by Charlie Martin on 2016-01-23

My application runs on OSX, Linux and Windows. So far I've been able to build libECBUFR on the first two.

However, I can't get past the configuration step on Windows. I'm building under mingw, which so far has been able to build any package that builds on Linux. But libECBUFR can't even get past the autoreconf step. It has problems with gettext, which seems to be triggered by the --install switch. If I leave out the --install option, then there is an error reported about the AC_PROG_LIBTOOL macro.

Has this package been successfully built on windows? If so, what was the procedure?


Question information

English Edit question
libECBUFR Edit question
No assignee Edit question
Solved by:
Charlie Martin
Last query:
Last reply:

Yves Pelletier suggests this article as an answer to your question:
FAQ #539: “Running libECBUFR experimentally under Microsoft Windows (R)”.

Hello Charlie,

Good to hear libecbufr compiles on OSX.

Compilation under Windows, using mingw, was added on an experimental basis by Vanh. It worked at the time, and I think it probably can be made to work again. However, there is currently no institutional requirement for this cabability in our operating environment, and consequently this code has remained untouched for several years. So it is not too surprising that something may have lapsed during that time. I will ask Vanh whether he would take a look on a volunteer basis. It would be difficult for us to commit official resources on this feature.

Otherwise, if you were to find a solution, and provided us a suggested patch, we would consider putting it in the code.

Best regards


Charlie Martin (martinc-e) said : #3

Thanks for the info.

I have made good progress on this, mainly by adding a number of packages that were required by the automake system, which apparently haven't been needed by other (automake) packages on my system. I can now get ./reconf to complete, and a configure script gets built.

I'm currently stuck on errors from strtok_r,() which isn't avaiable on mingw. One solution is to provide your own version, and I find "mock_strtok_r()" in bufr_util.c. But it doesn't seem to be used. Why is it there? I'll hack libecbufr to use it and see what happens.


Charlie Martin (martinc-e) said : #4

Opps, I see that it gets defined as strtok_r in bufr_util.h. I'll just need to find why this is not being activated.

Good to hear that you are making progress.

Vanh also took a look and has this to say:

You need to use the MinGW Installation Manager to add all packages that are essential for libECBUFR to compile.

gettext 0.18.1 (take the msys package, not the 0.18.3 from MinGW)
Also add csv

Modify to specify version 0.18.1 for AM_GNU_GETTEXT_VERSION

Charlie Martin (martinc-e) said : #6

I was able to get libecbufr working on Windows (using mingw). So now my app will produce BUFR messages on OSX, Linux and Windows.

Here are the steps that I followed to get the Windows library built:

- Edit API/Sources/bufr_template.c, and add (so that mock_strtok_r() is defined):
#include "bufr_util.h"

- install autotools and dependencies:
mingw-get install automake
mingw-get install gettext
mingw-get install msys-cvs
mingw-get install libtool
mingw-get install libiconv

- Get the pkg-config-lite distribution from Unpack it, and install pkg-config.exe in the msys/1.0/bin directory.

- Download and build GNU Check

- Create configure

- Edit ./configure, and comment out the line:

- Edit Examples/Makefile, and remove build targets for the following programs (this will have to be done every time Examples/Makefile is regenerated by ./configure):
decode_net (sys/socket.h not available)
decode_cmc_table (scandir not available)

- Configure and build
LDFLAGS="-lintl" ./configure --prefix=/usr/local
make install

cpb (chris-beauregard) said : #7

> Edit API/Sources/bufr_template.c, and add (so that mock_strtok_r() is defined):

Fixed in r325.

The other elements are somewhat more difficult to fix. In some cases (missing header files or functions) we could handle them with autoconf tests and automake rules to strip build targets, but I can't test that stuff.

Charlie Martin (martinc-e) said : #8


I don't know autotools configuration, but if I did, I would remove decode_net and decode_cmc_table from the list of programs for my build. Can you suggest how to do this?

I also realize that in my build notes. the ./configure goes before "Edit Examples/Makefile..."

cpb (chris-beauregard) said : #9

Roughly speaking, you would add a conditional that automake will understand when it generates So, to skip something missing a header file you might use add the following to

if test "$HAVE_DIAL_H" = "1"; then
   AC_DEFINE(HAVE_DIAL_H,1,[if dial.h exists])

then in the corresponding

targets = prog1 prog2 test_needs_dial
targets = prog1 prog2

Similarly, a conditional can be added for a missing library function like scandir() with:


Yes, even though $HAVE_SCANDIR is defined it's not available to automake without the AM_CONDITIONAL().

That's how it *should* work. We use AM_CONDITIONAL already in places in LibECBUFR so it *should* work okay and this is pretty basic autotools stuff, but I haven't touched Windows development since the days when ME was considered bleeding edge... caveat emptor.