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

Revision 32632, 3.5 KB (checked in by ak19, 9 months ago)

I think these are fixes necessary to our linux gs-libiconv 1.11 tarball to get the same to compile on Windows with VS14 (VS2015), so that GS3 can proceed to compile past the jni issues caused by libiconv failing to compile. I've added a README with instructions of use and with the list of changes I had to make to the linux tarball to get the windows iconv zip that works with VS14. libiconv 1.11 is the last version that was still provided Vis Studio makefiles, later versions (1.12 and onwards) require Mingw and/or Cygwin as per their READMEs.

Line 
1*****************************************************************
2COMPILING LIBICONV ON WINDOWS USING VS14/VS2015 AND LATER
3*****************************************************************
4In order to get libiconv to compile with Visual Studio 14 (which is Visual Studio 2015) and later,
5I needed to do the following to produce gs-libiconv-winVS14-VS2015-plus.zip now uploaded on GS SVN
6at GS2\common-src\indexers\packages\windows\iconv
7
8For compiling GS3 with VS14 (VS2015) and later, after running ant prepare, rename this zip file as "iconv.zip"
9and then proceed to run ant install.
10
11
121. Libiconv 1.11 appears to be the last version of the package that can be compiled with Visual Studio.
13Subsequent versions require Mingw and/or Cygwin and won't work easily with our existing GS compile workflow.
14
15We already have a gs-libiconv 1.11 tarball at GS3\gs2build\common-src\packages\iconv\gs-libiconv-1.11.tar.gz
16
17I followed Dr Bainbridge's initial attempts and copied this into GS3\gs2build\common-src\indexers\packages\windows\iconv
18where I untarred it and made the following changes (points 2 and 3 below).
19Then I renamed the untarred version from libiconv-1.11 to iconv
20and finally I zipped it up to produce iconv.zip.
21
22
232. In the Makefile.msvc files inside gs-libiconv 1.11 that are listed below,
24change the now syntax error
25
26    !if $(DEBUG)
27to
28    !if "$(DEBUG)" == "1"
29   
30(example is here:
31https://github.com/adobe/chromium/blob/master/third_party/libxslt/win32/Makefile.msvc)
32
33
34List of affected Makefile.msvc files:
35- ./lib/Makefile.msvc
36- ./libcharset/lib/Makefile.msvc
37- ./src/Makefile.msvc
38- ./srclib/Makefile.msvc
39- ./tests/Makefile.msvc
40
41Not sure if other similar instances need similar changes, e.g. !if !$(DLL)
42but they didn't give rise to syntax errors or GS3 compilation failures, so I left them as is.
43
44
453. To overcome mbstate_t "redefinition *conflict*" error:
46
47loop_wchar.h, need last line below to replace existing typedef
48https://stackoverflow.com/questions/31960646/visual-studio-2015-libc-is-not-backwards-compatible
49(explains the need to recompile 'everything' when changing to VS 2015 to use the new definition of mbstate_t)
50
51    typedef struct _Mbstatet
52    { // state of a multibyte translation
53        unsigned long _Wchar;
54        unsigned short _Byte, _State;
55    } _Mbstatet;
56
57    typedef _Mbstatet mbstate_t;
58
59
60So in GS3svn\gs2build\common-src\indexers\packages\windows\iconv\iconv\lib\loop_wchar.h,
61change:
62    # ifndef mbstate_t
63       typedef int mbstate_t;
64    # endif
65to:
66
67    # ifndef mbstate_t
68    typedef _Mbstatet mbstate_t;
69    # endif
70
71
72
73INFORMATIVE LINKS THAT WEREN'T RELEVANT AT THE TIME OR TO SOLVING THE ABOVE PROBLEMS:
74* libiconv 1.14 binaries?
75https://sourceforge.net/projects/mingw-w64/
76
77* Vis Studio 2013 (VS12) and before:
78https://stackoverflow.com/questions/2733402/how-to-build-gnu-libiconv-on-for-windows
79
80* Beware the notes in libconv 1.11's README.woe32 that says:
81"- Requires MS Visual C/C++ 4.0 or 5.0 or 6.0 or 7.0.
82
83  Note that binaries created with MSVC 7.0 should not be distributed: They
84  depend on a closed-source library 'msvcr70.dll' which is not normally part
85  of a Woe32 installation. You cannot distribute 'msvcr70.dll' with the
86  binaries - this would be a violation of the GPL and of the Microsoft EULA.
87  You can distribute the binaries without including 'msvcr70.dll', but this
88  will cause problems for users that don't have this library on their system.
89  Therefore it is not recommended. This problem does not occur with MSVC 6.0
90  and earlier.
91"
Note: See TracBrowser for help on using the browser.