Re: [ft] Building freetype under cygwin

[Werner LEMBERG]

> address@hidden ~/freetype-2.6
> $ ./objs/apinames.exe \
>   -o `cygpath -w /home/alex/freetype-2.6/objs/ftexport.sym` \
>   `cygpath -w /home/alex/freetype-2.6/include/freetype/ttnameid.h` \
>   `cygpath -w /home/alex/freetype-2.6/include/freetype/freetype.h`

Aah, OK.  I've never used cygwin, so the problem isn't with `apinames'
per se, but the conversion of UNIX style file names to Windows style.

Could you work on a patch that fixes that?  The idea is to use GNU
make's powerful string substitution routines to massage the recipe in
the rule for generating $(EXPORTS_LIST) in file `exports.mk', that is,
having the following replacement.

  if we have cygwin + mingw (or whatever triggers the problem):
    U2W := `cygpath -w %`
  otherwise:
    U2W := %

  $(EXPORTS_LIST): $(APINAMES_EXE) $(PUBLIC_HEADERS)
          $(subst /,$(SEP),$(APINAMES_EXE)) \
          -o$(patsubst %,$(U2W),$@ $(APINAMES_OPTIONS) $(PUBLIC_HEADERS))
          @echo TT_New_Context >> $(EXPORTS_LIST)
          @echo TT_RunIns >> $(EXPORTS_LIST)

> Not to change the topic, but I’ve tried some alternative methods of
> building.  Under the same environment as above (cygwin with mingw
> toolchain), cmake seems to go further, but doesn’t seem to offer
> disabling zlib.

I've just applied some cmake patches that should take care of this.
Please test the git repository.

> Switching to msys2 shell with mingw toolchain, the build is
> finishing, but the binary ends up requiring libgcc_s_dw2-1.dll —
> passing --static-libgcc in LDFLAGS doesn’t seem to have any effect.

Hmm.  AFAIK, a user-defined LDFLAGS is passed on to libtool...  Does
libtool pass `--static-libgcc' to the gcc command line?


    Werner