Cross-compiling tripped up by CC being set, and unusual build platform detection

[Ellie]

Hi everyone,

Thanks for your nice work on freetype2!

I tried cross-compiling freetype2 for Windows, and ran into a few
strange behaviors. E.g. when I set the CC variable to the cross compiler
that it should be using anyway, things break:

bash ./autogen.sh && ./configure --host=x86_64-w64-mingw32
--with-zlib=no --with-bzip2=no --with-png=no --with-harfbuzz=no && make
CC=x86_64-w64-mingw32-gcc
...
./builds/unix/libtool --mode=link x86_64-w64-mingw32-gcc -o
/home/ellie/Develop/myprj/vendor/freetype2/objs/libfreetype.la
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftsystem.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftdebug.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftinit.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftver.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftbase.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftbbox.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftbdf.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftbitmap.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftcid.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftfstype.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftgasp.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftglyph.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftgxval.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftmm.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftotval.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftpatent.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftpfr.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftstroke.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftsynth.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/fttype1.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftwinfnt.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/truetype.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/type1.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/cff.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/type1cid.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/pfr.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/type42.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/winfnt.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/pcf.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/bdf.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/sfnt.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/autofit.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/pshinter.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/raster.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/smooth.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftcache.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftgzip.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftlzw.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftbzip2.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/psaux.lo
/home/ellie/Develop/myprj/vendor/freetype2/objs/psnames.lo -rpath
/usr/local/lib -version-info 23:0:17  -no-undefined -export-symbols
/home/ellie/Develop/myprj/vendor/freetype2/objs/ftexport.sym
libtool:   error:
'/home/ellie/Develop/myprj/vendor/freetype2/objs/ftsystem.lo' is not a
valid libtool object
make: *** [config.mk:55:
/home/ellie/Develop/myprj/vendor/freetype2/objs/libfreetype.la] Error 1
$ echo $?
2

While this works fine:

bash ./autogen.sh && ./configure --host=x86_64-w64-mingw32
--with-zlib=no --with-bzip2=no --with-png=no --with-harfbuzz=no && make
...
libtool: link: ( cd
"/home/ellie/Develop/myprj/vendor/freetype2/objs/.libs" && rm -f
"libfreetype.la" && ln -s "../libfreetype.la" "libfreetype.la" )
$ echo $?
0

This is rather inconvenient when calling freetype2's build from a nested
Makefile that also already runs under the same cross-compile
environment, and hence might have CC set either directly, or via MAKEFLAGS.

Also, even for the working second build line, it seems freetype assumes
I am compiling for Unix for some reason:

  platform                    unix
  compiler                    cc
  configuration directory     ./builds/unix
  configuration rules         ./builds/unix/unix.mk

The build runs through, so I'm not sure how much this matters, but it
does nevertheless feel like it might potentially be a bug. For what it's
worth, it IS possible to build with the Windows build files for
cross-compilation:

bash ./autogen.sh && ./configure $(HOSTOPTION) --with-zlib=no
--with-bzip2=no --with-png=no --with-harfbuzz=no && cp
"./builds/windows/w32-mingw32.mk" "./config.mk" && make SEP=/

^ works fine too! Shouldn't that be what it automatically picks?

I hope the CC issue particularly can be addressed, because I feel like I
won't be the last person losing some time debugging environment changes
to track this culprit down. All the other libraries I cross-compile
don't have an issue with this, so this one really struck me by surprise.

Best regards,

Ellie