[32632] | 1 | *****************************************************************
|
---|
[35595] | 2 | COMPILING LIBICONV ON WINDOWS USING VS14 AND LATER
|
---|
[32632] | 3 | *****************************************************************
|
---|
[35595] | 4 | In order to get libiconv to compile with Visual Studio v14 (which is Visual Studio 2015) and later,
|
---|
| 5 | I needed to do the following to produce iconv-VS14-PLUS.zip now uploaded on GS SVN
|
---|
[32632] | 6 | at GS2\common-src\indexers\packages\windows\iconv
|
---|
| 7 |
|
---|
[35595] | 8 | The build scripts have been updated to test %VisualStudioVersion%, and if it is < 14.0, then
|
---|
| 9 | the original (older) iconv.zip files is used (renamed to iconv-PRE-VS14,zip for consitency reasons)
|
---|
| 10 | otherwise iconv-VS14-PLUS.zip is used.
|
---|
[32632] | 11 |
|
---|
[32637] | 12 | [
|
---|
[35595] | 13 | NO NEED FOR STEP 1, as windows' iconv-PRE-VS14.zip requires the same changes as the linux gs-libiconv 1.11 tarball to get
|
---|
| 14 | it to compile on windows anyway:
|
---|
[32642] | 15 |
|
---|
[32637] | 16 | X 1. Libiconv 1.11 appears to be the last version of the package that can be compiled with Visual Studio.
|
---|
[32632] | 17 | Subsequent versions require Mingw and/or Cygwin and won't work easily with our existing GS compile workflow.
|
---|
| 18 |
|
---|
| 19 | We already have a gs-libiconv 1.11 tarball at GS3\gs2build\common-src\packages\iconv\gs-libiconv-1.11.tar.gz
|
---|
| 20 |
|
---|
| 21 | I followed Dr Bainbridge's initial attempts and copied this into GS3\gs2build\common-src\indexers\packages\windows\iconv
|
---|
| 22 | where I untarred it and made the following changes (points 2 and 3 below).
|
---|
| 23 | Then I renamed the untarred version from libiconv-1.11 to iconv
|
---|
[35595] | 24 | and finally I zipped it up to produce a new (alternative) for iconv.zip.
|
---|
[32637] | 25 | ]
|
---|
[32632] | 26 |
|
---|
[32642] | 27 | 2. In the Makefile.msvc files inside the extracted iconv folder that are listed below,
|
---|
[32632] | 28 | change the now syntax error
|
---|
| 29 |
|
---|
| 30 | !if $(DEBUG)
|
---|
| 31 | to
|
---|
| 32 | !if "$(DEBUG)" == "1"
|
---|
| 33 |
|
---|
[32642] | 34 | (an example of the correct way of doing this was found here:
|
---|
[32632] | 35 | https://github.com/adobe/chromium/blob/master/third_party/libxslt/win32/Makefile.msvc)
|
---|
| 36 |
|
---|
| 37 |
|
---|
| 38 | List 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] | 45 | Not sure if other similar instances in Greenstone win make files need similar changes, e.g. !if !$(DLL)
|
---|
| 46 | but 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 |
|
---|
| 49 | 3. To overcome mbstate_t "redefinition *conflict*" error:
|
---|
| 50 |
|
---|
| 51 | loop_wchar.h, need last line below to replace existing typedef
|
---|
| 52 | https://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 |
|
---|
| 64 | So in GS3svn\gs2build\common-src\indexers\packages\windows\iconv\iconv\lib\loop_wchar.h,
|
---|
| 65 | change:
|
---|
| 66 | # ifndef mbstate_t
|
---|
| 67 | typedef int mbstate_t;
|
---|
| 68 | # endif
|
---|
| 69 | to:
|
---|
| 70 |
|
---|
| 71 | # ifndef mbstate_t
|
---|
| 72 | typedef _Mbstatet mbstate_t;
|
---|
| 73 | # endif
|
---|
| 74 |
|
---|
| 75 |
|
---|
[32637] | 76 | 4. 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
|
---|
| 82 | That new VS compilers had their own stdbool.h where bool was typedefed to some other type with a different size in memory.
|
---|
[32642] | 83 | So we have to use VS' stdbool.h instead of iconv.zip's stdbool.h
|
---|
[32637] | 84 |
|
---|
| 85 | My solution was therefore to get rid of iconv/windows/stdbool.h for the iconv-VS14+ version,
|
---|
[32642] | 86 | to force it to find the stdbool.h in VS14+ instead.
|
---|
[32637] | 87 | So I renamed iconv/windows/stdbool.h to iconv/windows/stdbool.unusable_for_VS14plus
|
---|
| 88 |
|
---|
| 89 |
|
---|
[32632] | 90 | INFORMATIVE LINKS THAT WEREN'T RELEVANT AT THE TIME OR TO SOLVING THE ABOVE PROBLEMS:
|
---|
| 91 | * libiconv 1.14 binaries?
|
---|
| 92 | https://sourceforge.net/projects/mingw-w64/
|
---|
| 93 |
|
---|
| 94 | * Vis Studio 2013 (VS12) and before:
|
---|
| 95 | https://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 | "
|
---|