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

[mpsuzuki]

On Tue, 18 Sep 2012 16:40:24 -0500
RMWChaos <address@hidden> wrote:

>Mpsuzuki,
>
>Thanks for your response. Running without Cygwin dependency. Cygwin bash
>is just used during the ./configure process; otherwise, I wouldn't even
>use it.

I see.

>Most other libs' configure processes that I've worked with (a small
>sampling, comparatively, I'm sure) seem to rely on a relative path
>scheme rather than absolute, and moving between Cygwin bash and GNU Make
>isn't a problem as a result, which is why I was asking about why
>Freetype isn't. Looking at the code, I do see where Freetype configure
>will fallback to using a relative path if it can't get an absolute path;
>so I may just "break" that code to force it.

Hmm. My concerns about Cygwin + MSVC cross compiling are
following 2 points:

* The compiler & linker of MSVC are dependent with many
MSDOS environmental variables designed for MSVC (to make
compiler/linker search appropriate SDK directories including
headers & libraries). MSVC installation will provide a
shortcut menu to start MSDOS command prompt with
appropriate environment (I remember MSVC installer warns
us NOT to put the environmental variables for MSVC to
the default setting, because it can confuse the runtime
dynamic loading), but no Cygwin terminal with appropriate
environment for MSVC - we have to set by ourselves.
In fact, when I invoke MSVC compiler in Cygwin's terminal,
it will immediately failed.

        $ /cygdrive/e/MSVC2005/VC/bin/cl.exe /?
        /cygdrive/e/MSVC2005/VC/bin/cl.exe: error while loading shared 
libraries: MSVCR80.dll: cannot open shared object file: No such file or 
directory

* Autoconf's "configure" is often designed for the compilers
on Unix systems. For example, AC_CHECK_LIB macro (used to
check the existence of a library with given name) assumes
that "-lxxx" option will make the compiler search libxxx.
Apparently, it would not work with MSVC ("/Fl" should be used
instead of "-l"). I could not find the abstraction system
in Autoconf to translate such options, I'm afraid that
Autoconf's configure is not safe solution for the people
working with MSVC.

--

Because of my 2 concerns, I'm questionable whether the
binary (configued by Autoconf's configure & compiled by
MSVC) is really useful.

Maybe you want to ask "if Autoconf configure & MSVC combination
is not recommended, what is recommended solution?". It would
be MinGW make + MSVC. FreeType2's makefile (which is out of
Autoconf) have the abstraction system mapping "-l" to "/Fl"
for MSVC.

Myself is heavily addicted to Unix systems (I can type
"configure && make && make install" in the dark, but I cannot
compile hello-world with MSVC in the dark :-)), so I can sympathize
with the wish of cross-compilation with Autoconf + MSVC.
But, making Autoconf for MSVC-ready would be long work.

Regards,
mpsuzuki


>-RMWChaos
>
>On 2012-09-18 12:01, suzuki toshiya wrote:
>> Today I don't have my machine with MSVC in my hand...
>> I think "make setup visualc" is not designed for the combination
>> of Cygwin bash/make + MSVC. It would be suitable for MinGW make + MSVC.
>>
>> The binaries you want to build are those running on Windows
>> platform WITHOUT cygwin? Or, those running DEPENDING cygwin?
>> Cygwin is designed to pretend as if it were Unix platform,
>> so configure will be (mis)guided as if it finds the platform
>> as Unix.
>>
>>>    bash ./configure %FLAGS%
>>>    make
>>>    make install
>>>
>>> For most packages, this is working well; however, I'm really struggling
>> Without giving concrete example, I could not comment about
>> whether this (configure && make && make install) is right
>> direction, because, I'm not sure which binary (with cygwin?
>> without cygwin?) you want. What kind of packages you could
>> get expected result?
>>
>> Regards,
>> mpsuzuki
>>
>>
>> RMWChaos wrote:
>>> *ENVIRONMENT:*
>>> MS Windows 7 x64
>>> MSVC 2008 / SDK 7.0 -or- 2010 / SDK 7.1
>>> Cygwin bash
>>> GNU make 3.8.1
>>>
>>>
>>> *PREAMBLE:*
>>> Ultimately, this might turn out to be one build 'bug' and one build 
>>> feature 'enhancement / change request', and perhaps I should submit this 
>>> as two separate issues; however, they both relate to the same problem: I 
>>> can't get Freetype2 to compile in Windows 7 x64 using Cygwin / GNU Make 
>>> / MSVC 2008 or 2010. I'll wait to see what some initial responses are 
>>> before deciding how to proceed.
>>>
>>> I'm attempting to develop an automated build process for a Windows 
>>> application that requires the Freetype2 lib. The automated build allows 
>>> for the selection of x86 / x64, MSVC 2008 / 2010, static / shared libs, 
>>> and other options. To accommodate these options and simplify the build 
>>> process, I want to build all libs using the following steps, where all 
>>> the chosen build options are stored in var FLAGS...
>>>
>>>    bash ./configure %FLAGS%
>>>    make
>>>    make install
>>>
>>> For most packages, this is working well; however, I'm really struggling 
>>> with Freetype2. As noted in the two problem descriptions below, these 
>>> steps aren't working because the Freetype2 configure and makefiles 
>>> appear to be using absolute paths rather than relative paths (if I can 
>>> modify this one thing, I can get my preferred method above to work).
>>>
>>> Alternatively, running 'make setup visualc' is defaulting to unix rather 
>>> than win32/visualc, and thus fails when it can't find a 'visualc' target 
>>> in the unix makefile. Am I doing something wrong here by running "make 
>>> setup visualc" from the Freetype source directory, or has this something 
>>> to do with having a Win x64 OS or using Cygwin bash?
>>>
>>> I'm unable to use the MSVC/SDK command line "vcbuild" tool with the 
>>> freetype.sln/vcproj files in this case due to the need to allow for the 
>>> numerous possible build combinations. So the solution to either of the 
>>> following problems below will likely resolve the issue for me. 
>>> Preferably, I'd like to get a solution to problem #2 and change the 
>>> Freetype2 configure and makefiles to use relative- rather than absolute 
>>> paths during the build process. Perhaps someone can explain to me the 
>>> choice to use absolute- over relative paths?
>>>
>>>
>>> *PROBLEM #1:*
>>> Running "make setup visualc", setup still detects as unix-based OS and 
>>> CC compiler rather than Win32 and CL compiler - although, configure 
>>> reports ' checking for cc...no' and 'checking for cl ... cl.exe' - and 
>>> eventually fails with the message "make: *** No rule to make target 
>>> `visualc'. Stop.". Is this because I've got a Win64 OS and am using 
>>> Cygwin bash?
>>>
>>> The unix build process doesn't have a visualc build process - duh, it's 
>>> unix, not Windows - and the detect process is seeing my system as unix 
>>> rather than win32 even when I pass the visualc option to make setup. So 
>>> I'm stumped here. How do I force the make setup process to detect as 
>>> win32 rather than unix? I suspect I need to follow the CUSTOMIZE 
>>> instructions, but I would think that the setup detect process would see 
>>> my system as windows rather than unix.
>>>
>>>
>>> *PROBLEM #2:*
>>> The configure process for Freetype2 is using absolute paths rather than 
>>> relative paths. This is a problem as ./configure is run in Cygwin bash, 
>>> where paths are in the format "/cygdrive/c/..." but GNU Make is run in a 
>>> Win CMD shell, where paths are in the format "C:\...". Ultimately, when 
>>> GNU make is called, after ./configure completes, it fails immediately 
>>> because it sees the absolute path 
>>> '/cygdrive/c/.../freetype/src/base/ftsystem.c' as a switch (the initial 
>>> forward slash) rather than as a path, which would fail anyway under 
>>> Windows CMD shell. If instead there was a relative path 
>>> 'src/base/ftsystem.c', things should work properly. Even running GNU 
>>> make under Cygwin, it still fails seeing the path as a switch because 
>>> it's not wrapped in quotes.
>>>
>>> Need an "easy" way to convert configure to utilize relative paths so 
>>> that it assumes it's running in the source base directory 'freetype' and 
>>> everything else is accessed via './src/base', etc. I've passed the 
>>> CFG="--srcdir=." option to make setup as well as "--srcdir=." to 
>>> ./configure, but that didn't appear to work. I've also manually changed 
>>> 'abs_curr_dir' var in configure to '.' and './' but neither of those 
>>> worked either.
>>>
>>> Thanks and regards,
>>>
>>> -RMWChaos
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Freetype-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>>
>>
>