freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Freetype 2.4.10 MSVC++ / Cygwin Compile fails


From: mpsuzuki
Subject: Re: [ft-devel] Freetype 2.4.10 MSVC++ / Cygwin Compile fails
Date: Thu, 20 Sep 2012 22:50:54 +0900

On Thu, 20 Sep 2012 08:31:41 -0500
RMWChaos <address@hidden> wrote:
>> I found that there is a wrapper script for the compilers
>> whose options are not Unix-like syntax; "compile".
>> It comes from gnulib which is really designed for MSDOS
>> or Windows compatibilities (you can find explicit keywords
>> like cygwin/mingw/wine, cl.exe in it), it is used by the
>> packages like gzip or gexttext, stored as gzip-1.5/build-aux/compile.
>>
>> # Automake has also "compile" wrapper script, but it is not
>> # for such issues; it is designed for old compilers that
>> # cannot take both of "-c" "-o" at once.
>Ah, was not aware of that. Need to pull that wrapper script out and take 
>a look at it. Perhaps it's portable enough to be applied to libraries 
>such as Freetype and ICU that haven't implemented it or something like it.

Indeed. I think the inclusion of the scripts in build-aux
to FreeType2 package is a considerable option as the
first step to minimize the FreeType2-specific hack to use
MSVC via Cygwin.

The aclocal.m4 in ICU has different remark; I guess it
distinguishes Cygwin native compilation and Cross compilation
with MSVC running on Cygwin or MinGW. Current autoconf's
cross compilation detection is based on GNU toolchain prefix
(e.g. the name like "i586-mingw32msvc-gcc" will indicate
that the compiled binary should work without Cygwin, even
if this compiler itself is working on Cygwin), it would
not be work well with non-GNU compilers like cl.exe.

>> Among the packages you listed, iconv (GNU libiconv-1.14)
>> does NOT include it and configure script could not invoke
>> cl.exe correctly (in my case), thus, during the configuration,
>> the fundamental check like "the size of wchar_t" fails.
>> I'm suspicious whether the built binary is safe.
>>
>> I attached my config.log. Could you send me your config.log
>> left in libiconv's build directory?
>As I recall, iconv was a real pain to get compiled.
>I managed to succeed using mingw-w64 previously, but will have
>to spend some time on it with this new auto-build process
>I'm working on. I'll work on it today and send you the config.log
>a bit later. Thanks for providing yours.

Oh. It's sufficient for me to hear that libiconv was not
built easily. In fact, my config.log includes some errors
showing that the configure script tries to use build-aux/compile
but failed because it is not included. I'm wondering why
the dependency to build-aux/compile is not automatically
solved when libiconv maintainer makes a source tarball.

I think gnulib's build-aux/compile is not so widely used,
so, many packages (without this) misunderstands the nature
of MSVC and misconfigures the setting for the compilers.

>As for Freetype, I've made some good progress. Had to modify 
>"/builds/detect.mk", "/builds/module.mk", and /builds/win32/detect.mk" 
>so that it properly created the "/objs/ftmodule.h" file. The current 
>implementation of replacing the unix-like forward slashes with 
>windows-like backslashes doesn't appear to be working properly for Win7. 
>The attached patch file makes the necessary changes to these files, but 
>more work is needed. Note the patch only modifies in-place the existing 
>DOS/Win code rather than adding a third Win7 code block; so this is more 
>of a hack than a permanent fix - only to be used specifically when 
>you're building on a Win7 box.

Thank you for providing a patch, I will check. I'm working
with Windows 7 + MSVC 2005 (maybe it looks like an odd
combination)

Regards,
mpsuzuki



reply via email to

[Prev in Thread] Current Thread [Next in Thread]