source: main/trunk/greenstone2/common-src/indexers/packages/windows/iconv/GS-README-VS14-VS2015-AND-LATER.txt@ 32642

*****************************************************************
COMPILING LIBICONV ON WINDOWS USING VS14/VS2015 AND LATER
*****************************************************************
In order to get libiconv to compile with Visual Studio 14 (which is Visual Studio 2015) and later,
I needed to do the following to produce gs-libiconv-winVS14-VS2015-plus.zip now uploaded on GS SVN
at GS2\common-src\indexers\packages\windows\iconv

For compiling GS3 with VS14 (VS2015) and later, after running ant prepare, rename this zip file as "iconv.zip" 
and then proceed to run ant install.


[
NO NEED FOR STEP 1, as windows' iconv.zip requires the same changes as the linux gs-libiconv 1.11 tarball to get it to compile on windows anyway:

X 1. Libiconv 1.11 appears to be the last version of the package that can be compiled with Visual Studio.
Subsequent versions require Mingw and/or Cygwin and won't work easily with our existing GS compile workflow.

We already have a gs-libiconv 1.11 tarball at GS3\gs2build\common-src\packages\iconv\gs-libiconv-1.11.tar.gz

I followed Dr Bainbridge's initial attempts and copied this into GS3\gs2build\common-src\indexers\packages\windows\iconv
where I untarred it and made the following changes (points 2 and 3 below). 
Then I renamed the untarred version from libiconv-1.11 to iconv
and finally I zipped it up to produce iconv.zip.
]

2. In the Makefile.msvc files inside the extracted iconv folder that are listed below,
change the now syntax error

    !if $(DEBUG)
to
    !if "$(DEBUG)" == "1"
    
(an example of the correct way of doing this was found here:
https://github.com/adobe/chromium/blob/master/third_party/libxslt/win32/Makefile.msvc)


List of affected Makefile.msvc files:
- ./lib/Makefile.msvc
- ./libcharset/lib/Makefile.msvc
- ./src/Makefile.msvc
- ./srclib/Makefile.msvc
- ./tests/Makefile.msvc

Not sure if other similar instances in Greenstone win make files need similar changes, e.g. !if !$(DLL)
but our other win make files didn't give rise to syntax errors or GS3 compilation failures, so I left them as is.


3. To overcome mbstate_t "redefinition *conflict*" error:

loop_wchar.h, need last line below to replace existing typedef
https://stackoverflow.com/questions/31960646/visual-studio-2015-libc-is-not-backwards-compatible
(explains the need to recompile 'everything' when changing to VS 2015 to use the new definition of mbstate_t)

    typedef struct _Mbstatet
    { // state of a multibyte translation
        unsigned long _Wchar;
        unsigned short _Byte, _State;
    } _Mbstatet;

    typedef _Mbstatet mbstate_t;


So in GS3svn\gs2build\common-src\indexers\packages\windows\iconv\iconv\lib\loop_wchar.h, 
change:
    # ifndef mbstate_t
       typedef int mbstate_t;
    # endif
to:

    # ifndef mbstate_t
    typedef _Mbstatet mbstate_t;
    # endif


4. stdbool.h redefinition of bool

- The solution wasn't: http://www.cplusplus.com/forum/beginner/72957/
(and which issue produced the flow on errors at https://lists.gnu.org/archive/html/bug-gnu-libiconv/2007-07/msg00002.html)

- The solution was indicated at: https://github.com/chansen/p5-time-moment/issues/12
That new VS compilers had their own stdbool.h where bool was typedefed to some other type with a different size in memory.
So we have to use VS' stdbool.h instead of iconv.zip's stdbool.h

My solution was therefore to get rid of iconv/windows/stdbool.h for the iconv-VS14+ version,
to force it to find the stdbool.h in VS14+ instead.
So I renamed iconv/windows/stdbool.h to iconv/windows/stdbool.unusable_for_VS14plus
    

INFORMATIVE LINKS THAT WEREN'T RELEVANT AT THE TIME OR TO SOLVING THE ABOVE PROBLEMS:
* libiconv 1.14 binaries?
https://sourceforge.net/projects/mingw-w64/

* Vis Studio 2013 (VS12) and before:
https://stackoverflow.com/questions/2733402/how-to-build-gnu-libiconv-on-for-windows

* Beware the notes in libconv 1.11's README.woe32 that says:
"- Requires MS Visual C/C++ 4.0 or 5.0 or 6.0 or 7.0.

  Note that binaries created with MSVC 7.0 should not be distributed: They
  depend on a closed-source library 'msvcr70.dll' which is not normally part
  of a Woe32 installation. You cannot distribute 'msvcr70.dll' with the
  binaries - this would be a violation of the GPL and of the Microsoft EULA.
  You can distribute the binaries without including 'msvcr70.dll', but this
  will cause problems for users that don't have this library on their system.
  Therefore it is not recommended. This problem does not occur with MSVC 6.0
  and earlier.
"