cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Compiling under windows with USE_IDN=yes, patch needed

From: Guenter <lists_at_gknw.net>
Date: Sat, 28 Jul 2012 06:13:28 +0200

Hi Jan,
Am 28.07.2012 03:29, schrieb Jan Ehrhardt:
> Compiling under Windows from the commandline in /winbuild with
> USE_IDN=yes fails with unresolved externals _IdnToAscii and
> _IdnToUnicode.
>
> Solution: add /DWANT_IDN_PROTOTYPES to line 175 of MakefileBuild.vc in
> winbuild
>
> -CFLAGS = $(CFLAGS) /DUSE_WIN32_IDN
> +CFLAGS = $(CFLAGS) /DUSE_WIN32_IDN /DWANT_IDN_PROTOTYPES
>
> WANT_IDN_PROTOTYPES is needed in /lib/idn_win32.c
hehe, funny story this is ...
originally idn_win32.c did include windows.h but this include was
removed during a code cleanup ...
I guess the problem is that M$ did put the IDN functions into a header
which is included from windows.h, and this is not normalization.h which
only comes with the 'Microsoft IDN Mitigation APIs';
when I was on that one year ago to build WinIDN with MinGW + OpenWatcom
I finally choosed to clone the prototypes instead of including
normalization.h which was not possible without further crazy hacks, and
then protected these with WANT_IDN_PROTOTYPES so that only the compilers
which need those protos can define it; if you now say that it works no
longer with MSVC either I guess we can just remove this proetction and
always use these prototypes for all Windows compilers ...; on the other
hand it might happen that at some point MinGW and OpenWatcom add these
protos to their APIs which would then produce a redefine ..., sigh
ok, for now your suggestion seems to be the simplest way to fix ...

can you please lookup which MSVC header has those two functions
IdnToAscii and IdnToUnicode, and if they are protected somehow so that
they are not aways available?

Gün.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-07-28