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