[bug-gnu-libiconv] libiconv 1.11 - build for Microsoft Visual Studio 2005 (VC 8)

[Milan Gornik]

Hello,

We're using iconv library since version 1.9.1 and Microsoft Visual Studio 98 
(VC++ 6). Now, we switched to new version of Microsoft Visual Studio - 2005 
(VC++ 8) and we wanted to continue using iconv. There were problems with 
using library version 1.9.1 with this compiler, so we also switched to new 
version of iconv (1.11). We tried to rebuild library from the sources. The 
problem is this version also doesn't build with VS 2005.

Now, I found usable workaround to these problems which includes small 
modifications to project and source files. After these workarounds are 
applied, iconv 1.11 successfully builds and runs on VS 2005. The link to the 
site where I've found these workarounds:
http://arton.no-ip.info/collabo/backyard/?IconvForWoe32

As that page is using non-standard charset, I also attached our own 
workaround page, which follows instructions from the previous link and adds 
more comments on changes.

I wanted to ask if there is a possibility that development team working on 
iconv consider these workarounds (and apply something similar to the new 
version). I see that VC++ 8 is not listed as supported platform in 
README.woe32, so I understand this is a feature request, not a bug report.

Regards.
Milan Gornik

Issue 1: EXEEXT undefined

Scenario: 
EXEEXT is makefile-related symbol which is 
used to define executable file extension ('.exe' on Windows platform). It is defined 
by GNU make utility, but Microsoft's NMAKE doesn't define such 
symbol.

Resolution: 
EXEEXT symbol is manually added to 
Microsoft Visual C++ makefile.


Explanation of changes: Append this line to the 
end of the file:
#define EXEEXT 
"exe"

Issue 2: width module is not included in build configuration

Scenario:
Original makefile (Makefile.msvc) doesn't include compilation 
of width.c unit which is 
mandatory.

Resolution:
width.c unit is added to makefile.


Explanation of changes: Enter following two 
lines as a replacement for line number 93:
setenv.obj unsetenv.obj \
width.obj

On line number 124 insert 
blank line and then following lines of text:
width.obj : width.c
$(CC) 
$(INCLUDES) $(CFLAGS) -c width.c

Issue 3: stdint.h unit is not present in MSVS compiler

Scenario:
One of the units in libiconv is 
including stdint.h header file, 
whIsich is C Standard Library mandatory library (as of C99 standard). Microsoft 
Visual C++ compiler doesn't follow this part of the C99 standard, as it had the 
same functionalities defined before this standard was introduced (as of MSVS 
98).

Resolution:
stdint.h is removed from included units 
list, and additional defines are introduced to define Microsoft-specific names 
as C99 names.


Explanation of changes: On line number 23, 
there is this directive: #include 
<stdint.h>
Replace that line with the following lines:
#ifndef _WIN32
#include 
<stdint.h>
#endif

typedef unsigned char uint8_t;
typedef 
unsigned short uint16_t;
typedef unsigned int uint32_t;

Issue 4: POSIX library unistd.h not present in MSVC compiler

Scenario:
POSIX standard defines unistd.h library which defines some of the 
system-related symbols, process-related functions etc. This module is not 
present in MSVS compiler C Standard Library.

Resolution:
unistd.h is included only if HAVE_UNISTD_H is previously 
defined.


Explanation of changes: On line number 30, 
there is directive: #include 
<unistd.h>
Replace that line with the following lines:
#if HAVE_UNISTD_H
#include 
<unistd.h>
#endif