2

I am trying to compile "xz-5.2.1" in MinGW/MSYS environment. I see the following errors:

#error UINT32_C is not defined and unsigned int is not 32-bit.

error: #error size_t is not 32-bit or 64-bit

I am not familiar with MinGW, could anyone shed some light on this? It looks like some macro definition are missing. Some header file missing?

ADD 1

The commands I used to compile the xz-5.2.1 are:

./configure
./make

The error screenshot:

enter image description here

Some background, I am following this link to compile the Tesseract-OCR library. And this is just one of the steps.

ADD 2

Based on the error message, I checked the sysdefs.h file. It contains the following content:

#ifdef HAVE_CONFIG_H
#   include <config.h>
#endif

The above make output contains the -DHAVE_CONFIG_H, so I think the system header file <config.h> should be included.

enter image description here

But strange enough, I searched the C:\MinGW\include, there's no such file. So I GUESS this may have caused the undefined UINT_MAX warning at line 57. And then the UINT32_C is not defined error at line 58.

enter image description here

But I don't know why the system header file config.h is missing and where to get it.

ADD 3

I dig a bit about the GNU autotools. And luckily enough I find that the following commands can carry on my build process: (Though I am still not very sure why it works. All I know is that it may be related to portability.)

autoheader  (this generates the config.h.in file)
./Configure  (this generates the config.h file from the config.h.in file)

And now, my build process is blocked by another issue as below:

enter image description here

It seems this is a known issue. And another thread has addressed it.

(I will continue update with my progress.)

Community
  • 1
  • 1
smwikipedia
  • 61,609
  • 92
  • 309
  • 482
  • You will need to give more detail about *how* you are trying to build `xz-5.2.1` -- e.g. commands you are issuing to yield these error messages -- to enable anyone to answer effectively. FWIW, the bug tracker comment at https://sourceforge.net/p/mingw/bugs/2216/#f4cc indicates that `xz-5.2.1` builds successfully with MinGW under MSYS, *provided* your `/mingw/lib` tree is not polluted by `*.la` files which do not match your installation. – Keith Marshall May 01 '15 at 08:22
  • @KeithMarshall I added my compile commands to my question. – smwikipedia May 03 '15 at 13:30
  • `config.h` is *not* a system header; it is generated specifically for each individual project, when you run `./configure`, and should be present in your project's build directory. – Keith Marshall May 04 '15 at 08:27
  • BTW, when you run configure for a MinGW build, in MSYS, you should *always* specify a `--prefix` argument; usually you want the absolute windows path for the MinGW installation directory, e.g. `./configure --prefix=C:/MinGW`, (but *do* use slashes in preference to backslashes, which MSYS shell interprets as escapes). – Keith Marshall May 04 '15 at 08:37
  • A further BTW: it's generally better to keep build directory separate from the source tree, or at least as a `build` subdirectory of the top source directory. In this latter case, with your `build` directory as CWD, you would be running `../configure --prefix=C:/MinGW`. – Keith Marshall May 04 '15 at 08:43
  • Are you building from a released tarball, or from a git clone? If the former, there's something wrong with the source package when you need to run *any* of the GNU autotools to build it; if the latter, then this additional developer centric activity is normal. – Keith Marshall May 04 '15 at 11:05
  • As you've noted, the `libiconv.la` issue is the result of a known packaging bug; the (simple) workaround is to delete all `*.la` files from your `/mingw/lib` tree, (unless they relate to libraries which you've built and installed yourself). – Keith Marshall May 04 '15 at 11:12
  • @KeithMarshall I am building from the stable released tar file xz-5.2.1.tar.gz, not a git clone. – smwikipedia May 05 '15 at 01:23
  • If you are building from the released tarball, I don't understand why you need to run `autoheader` to generate `config.h.in`; I downloaded `xz-5.2.1.tar.xz`, and I see this file already present -- right there in the top source directory. Maybe you have a corrupt `xz-5.2.1.tar.gz` file. – Keith Marshall May 06 '15 at 13:17
  • FTR, I can also see, (and can read), `config.h.in` in the xz-5.2.1.tar.gz tarball, as it is published on the tukaani.org/xz download page. – Keith Marshall May 06 '15 at 13:31
  • And ... just for fun ... I unpacked each of the `xz-5.2.1.tar.gz` and the `xz-2.5.1.tar.xz` tarballs, and ran `configure` followed by `make` on each in turn; both built OOTB for MinGW, without any hint of the problems you seem to be experiencing, (nor indeed *any* problem -- not even as much as a hiccough). – Keith Marshall May 06 '15 at 14:38

1 Answers1

1

If you care for an easier way to handle this kind of dependency management or a general update on toolchain functionality, I strongly suggest switching to MSYS2 with MinGW-w64.

Both projects aim (and succeed) in bringing a better version of the original. MSYS2 comes with a large number of 3rd party libraries that you can easily install. MinGW-w64 allows for GCC with full C++11/14/... support and extended Windows API availability, along with some useful extensions and more up to date headers. You'll notice that most problems originating from system headers will have already been solved, either by the MinGW-Packages scripts below, or upstream (of either MinGW-w64 or the projects themselves).

For you specifically, I suggest the following steps:

  1. Install and update MSYS2.

  2. Open an MSYS2 command prompt (or the 32-bit or 64-bit command prompts if you plan on building 32-bit or 64-bit things) from the start menu entries. Install {32-bit,64-bit} MinGW-w64 GCC:

    pacman -S mingw-w64-{i686,x86_64}-gcc

  3. Install tesseract-OCR:

    pacman -S mingw-w64-{i686,x86_64}-tesseract-ocr

    and optionally the data files:

    pacman -S mingw-w64-tesseract-ocr-osd mingw-w64-{i686,x86_64}-tesseract-ocr-eng

And you're done. Of course, you can still compile the various dependencies yourself, but why bother? If you really want to, you can start from the build scripts for the packages you can install in MSYS2, which are located here:

https://github.com/Alexpux/MINGW-packages

Just open the PKGBUILD files and you can see the build steps required. Note that all these scripts assume the dependencies have been installed within MSYS2.

Also note that the installed packages and compilers are all independent of MSYS2 as you'd expect: you can use it only as a tool to keep your development tree up to date, and build from any other Windows environment.

rubenvb
  • 74,642
  • 33
  • 187
  • 332
  • Maybe some people prefer to use MinGW.org's products, because they care about the due diligence taken to avoid copyright and trademark infringement. – Keith Marshall May 04 '15 at 11:07
  • @rubenvb I noticed that MSYS2 is derived from CygWin. I am wondering if I could just use CygWin for good. – smwikipedia May 05 '15 at 08:12
  • @smwikipedia The original MSYS was also, once, forked from Cygwin. Thing is, they didn't track upstream and stuck to an old version. As I can currently see, MSYS2 tracks upstream, at least in principle. Note that MSYS(2) != Cygwin. MSYS provides an Unix shell environment, primarily to run Unix Makefiles and Autotools configure scripts and such. MSYS2 adds to that a binary repository of MinGW-w64 3rd-party libraries (which Cygwin does not provide!). If you use Cygwin to compile native Windows applications, you'll essentially be cross-compiling, which can get tricky. If you need native ... – rubenvb May 05 '15 at 08:17
  • ... Windows development, I strongly suggest MSYS2. Cygwin, albeit useful, is overkill and will not give you the advantages of the MSYS2 binary packages. – rubenvb May 05 '15 at 08:17
  • @rubenvb Does MSYS2 contain some convenient package manager like `apt-get`? – smwikipedia May 05 '15 at 08:47
  • @smwikipedia yes, it includes `pacman`, which has been ported from Arch Linux. See [their wiki](https://wiki.archlinux.org/index.php/pacman#Usage) for details on the options. Basically: `apt-get update`==`pacman -Sy`, `apt-get install X`==`pacman -S X`, `apt-cache search X`==`pacman -Ss X`, `apt-get remove X`==`pacman -R X`. The MinGW-w64 packages all follow the naming scheme I showed in my post (`mingw-w64-ARCH-pkgname`). A list of packages can be obtained through `pacman -Ssq mingw-w64` or by looking at [the github project](https://github.com/Alexpux/MINGW-packages). – rubenvb May 05 '15 at 08:53
  • @rubenvb I tried `packman --help`. It seems no such command exists yet. How can I install it? I didn't see it in the `mingw-get` window. – smwikipedia May 05 '15 at 08:56
  • @smwikipedia You need MSYS2, not MSYS. It's a completely separate thing. See my answer above for all information you need to install and set it up. If you need help, we can chat here in a chat room. – rubenvb May 05 '15 at 09:01
  • @rubenvb Sorry I misunderstand you. I will try the MSYS2 now. – smwikipedia May 05 '15 at 13:12
  • @rubenvb Is MinGW-w64 solely for 64bit windows? I need to make 32bit DLLs. – smwikipedia May 05 '15 at 13:33
  • @smwikipedia No, it can build both 32 and 64-bit binaries. To install the 32-bit toolchain in MSYS2, do `pacman -S mingw-w64-i686-gcc`. To use it, use the "MinGW-w64 32-bit Shell" that you can find in the `MSYS2 64-bit` or `MSYS2 32-bit` start menu folder (depending on which version you installed. Note you can build 32-bit binaries from a 64-bit MSYS2 just fine. In fact, if you have a 64-bit Windows, I suggest you install 64-bit MSYS2. You will still be able to build 32-bit binaries just fine with. – rubenvb May 06 '15 at 07:13
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/77063/discussion-between-smwikipedia-and-rubenvb). – smwikipedia May 06 '15 at 07:15
  • @rubenvb Could you help me on this thread? http://stackoverflow.com/questions/30069830/how-to-install-mingw-w64-and-msys2 – smwikipedia May 06 '15 at 07:17
  • 1
    FTR, MSYS2 is neither MSYS, nor Cygwin, but seems to me to be more like Cygwin than MSYS ever will be. MSYS2 is maintained by A.N. Other, who has no association with MinGW.org, (who distribute MSYS); A. N. Other has, confusingly, hijacked the MSYS name for his product, yet he has completely lost sight of the original MSYS *minimalist* objective. Real MSYS really has no need to become a full-blown Cygwin clone, as MSYS2 seems set to become. So yeah, @smwikipedia, *I* would just use the real deal, i.e. Cygwin, if I felt the need for more than MSYS, (which I don't), but YMMV. – Keith Marshall May 06 '15 at 14:15
  • 1
    MSYS2 is developed by lexx83/Alexpux, mingwandroid, Elieux as indicated on Sourceforge. There is indeed no association with MinGW.org. I never implied that. Neither is MSYS2 more like Cygwin, or even close to a clone. The base system is quite small and minimalistic. You as a user can choose to make it as complete as you want. But it seems you're so set on, well, I don't really know what you're trying to do here except spew misconceptions and how the original is better because you think it is more minimalistic. – rubenvb May 06 '15 at 14:56