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

Last change on this file was 35595, checked in by davidb, 3 years ago

Updated README file to reflect file name changes in the zip files used

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