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