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

[Ellie]

Addition: setting the CC variable through a parent Makefile also seems
to break things without cross-compiling, as I just found out:

bash ./autogen.sh && ./configure --with-zlib=no --with-bzip2=no
--with-png=no --with-harfbuzz=no && CC=gcc MAKEFLAGS=" CC=gcc" make
...
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

(This is on a Linux system where gcc should be the default compiler)

On 3/18/20 1:32 PM, Ellie wrote:
> 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
>