search

ECCC-MSC / libecbufr

libecbufr is a general purpose, template-oriented BUFR encoding/decoding library
Other
10 stars 7 forks source link

Build on Windows #80

Closed tomkralidis closed 4 years ago

tomkralidis commented 4 years ago

Moved from https://answers.launchpad.net/libecbufr/+question/283033

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?

Thanks, Charlie Question information

Language: English Edit question

Status: Solved

For: libECBUFR Edit question

Assignee: No assignee Edit question

Solved by: Charlie Martin

Solved: 2016-01-25

Last query: 2016-01-25

Last reply: 2016-01-25

Related bugs

Link existing bug

Related FAQ:

Running libECBUFR experimentally under Microsoft Windows (R) Link to a FAQ

Yves Pelletier (yves-pelletier) said on 2016-01-25: #1

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

Yves Pelletier (yves-pelletier) said on 2016-01-25: #2

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

Yves

Charlie Martin (martinc-e) said on 2016-01-25: #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

Charlie Martin (martinc-e) said on 2016-01-25: #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.

Yves Pelletier (yves-pelletier) said on 2016-01-25: #5

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 configure.in to specify version 0.18.1 for AM_GNU_GETTEXT_VERSION

Charlie Martin (martinc-e) said on 2016-01-26: #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):

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 on 2016-01-27: #8

Thanks.

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 on 2016-01-27: #9

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

AC_CHECK_HEADER(dial.h,HAVE_DIAL_H=1,HAVE_DIAL_H=0) AM_CONDITIONAL(HAVE_DIAL, test "$HAVE_DIAL_H" = "1") if test "$HAVE_DIAL_H" = "1"; then AC_DEFINE(HAVE_DIAL_H,1,[if dial.h exists]) fi

then in the corresponding Makefile.am:

if HAVE_DIAL targets = prog1 prog2 test_needs_dial else targets = prog1 prog2 endif

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

AC_CHECK_FUNCS(scandir) AM_CONDITIONAL(HAVE_SCANDIR, test "$HAVE_SCANDIR" != "1")

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.