#313 can not compile djvulibre on Windows (MSYS2 + mingw-w64)

[Vincent TORRI]

Hello

when compiling on Windows (MSYS2 + mingw-w64), i have the following error:

ByteStream.cpp: In member function 'virtual int DJVU::ByteStream::seek(long int, int, bool)':
ByteStream.cpp:122:13: error: definition of static data member 'DJVU::ByteStream::EndOfFile' of dllimport'd class
122 | const char ByteStream::EndOfFile=ERR_MSG("EOF");
| ^~~~~~~~~~
make[1]: ** [Makefile:623: libdjvulibre_la-ByteStream.lo] Error 1

I've remarked that DJVUAPI_EXPORT (for c++ source code), DDJVUAPI_EXPORT (for the API) and MINILISPAPI_EXPORT (for miniexp source code) are not defined when the library is compiled, so i've modified libdjvu/Makefile.am like this:

libdjvulibre_la_CPPFLAGS = -DDIR_DATADIR=\"$(datadir)\" -DDJVUAPI_EXPORT -DDDJVUAPI_EXPORT -DMINILISPAPI_EXPORT

and compilation succeeds

regards

Vincent Torri

[Leon Bottou]

Bonjour Vincent,

Makefile.am already contains the following lines:

if HAVE_OS_WIN32

libdjvulibre_la_CPPFLAGS += -DDJVUAPI_EXPORT

libdjvulibre_la_CPPFLAGS += -DDDJVUAPI_EXPORT -DMINILISPAPI_EXPORT

libdjvulibre_la_LDFLAGS += -Wl,--export-all-symbols

endif

and HAVE_OS_WIN32 is defined in configure.ac as follows:

AC_CHECK_DECL([_WIN32],[have_os_win32=yes],[have_os_win32=no])

AM_CONDITIONAL([HAVE_OS_WIN32], [test "x${have_os_win32}" = "xyes"])

Is the problem caused because _WIN32 is not defined by MSYS2+mingw-w64.  

According to https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=vs-2019, it should in fact define both _WIN32 and _WIN64.

· _WIN32 Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined.

· _WIN64 Defined as 1 when the compilation target is 64-bit ARM or x64. Otherwise, undefined.

Could this be fixed by changing configure.ac with

AC_CHECK_DECL([_WIN32],[have_os_win32=yes],[have_os_win32=no])

AC_CHECK_DECL([_WIN64],[have_os_win32=yes],[ ])

AM_CONDITIONAL([HAVE_OS_WIN32], [test "x${have_os_win32}" = "xyes"])

From: Vincent TORRI doursse@users.sourceforge.net
Reply-To: "Ticket #313: can not compile djvulibre on Windows (MSYS2 + mingw-w64)" 313@bugs.djvu.p.re.sourceforge.net
Date: Monday, November 11, 2019 at 2:19 AM
To: "Ticket #313: can not compile djvulibre on Windows (MSYS2 + mingw-w64)" 313@bugs.djvu.p.re.sourceforge.net
Subject: [djvu:bugs] #313 can not compile djvulibre on Windows (MSYS2 + mingw-w64)

[bugs:#313] can not compile djvulibre on Windows (MSYS2 + mingw-w64)

Status: open
Group: djvulibre
Labels: windows mingw compilation
Created: Mon Nov 11, 2019 07:18 AM UTC by Vincent TORRI
Last Updated: Mon Nov 11, 2019 07:18 AM UTC
Owner: nobody

Hello

when compiling on Windows (MSYS2 + mingw-w64), i have the following error:

ByteStream.cpp: In member function 'virtual int DJVU::ByteStream::seek(long int, int, bool)':
ByteStream.cpp:122:13: error: definition of static data member 'DJVU::ByteStream::EndOfFile' of dllimport'd class
122 | const char ByteStream::EndOfFile=ERR_MSG("EOF");
| ^~~~~~~~~~
make[1]: ** [Makefile:623: libdjvulibre_la-ByteStream.lo] Error 1

I've remarked that DJVUAPI_EXPORT (for c++ source code), DDJVUAPI_EXPORT (for the API) and MINILISPAPI_EXPORT (for miniexp source code) are not defined when the library is compiled, so i've modified libdjvu/Makefile.am like this:

libdjvulibre_la_CPPFLAGS = -DDIR_DATADIR=\"$(datadir)\" -DDJVUAPI_EXPORT -DDDJVUAPI_EXPORT -DMINILISPAPI_EXPORT

and compilation succeeds

regards

Vincent Torri

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/djvu/bugs/313/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Vincent TORRI]

hello

ho, indeed the git has the fix. Not the latest release. Maybe a new release is necessary (last one is 4 years ago)

[Leon Bottou]

One might produce a release file, but I'd prefer people to use git...

[Vincent TORRI]

I use my own package installer for Windows and unfortunately, running the autotools leads to an error i was not able to fix. I you provide another build system (meson for example which is a LOT faster than autotools, especially on Windows), then no problem. Otherwise, i'll use the current release