[Devel] Cygwin experience and bugs

[Jeff Russell]

This note describes my installation problems with freetype 2.1.3 compiled
under cygwin on Windows 2000. Sorry for the lack of patch, but some of these
suggested fixes require policy decisions. In summary, there were four major
problems that precluded building a shared library version of freetype on
cygwin:
1. Automatic platform detection failed
2. Shared libraries will not be build based on current makefile commands
3. Linking the shared library requires a dummy "main()" symbol be supplied.
4. The postinstall commands incorrectly assemble file names.

Here are the details.  I do not have the bandwidth to supply a
proper/elegant solution, but am happy to help out as I can.

1. Platform detecion. The automatic platform detection does note work--it
concludes a DOS environment.  The real solution is to manually copy
./builds/unix/config.mk to the root source direcotry (.). The documentation
for building is split between docs/BUILD and docs/INSTALL, and adding a
specific note somewhere concerning cygwin would be helpful.

2. Cygwin caveat to build shared libraries. It appears that a partial work
around for cygwin was attempted then abandoned in libtool. As libtool is
generated by configure, it will not attempt to build a shared library
version. This is a "hard coded" logic decision based on how libtool analyzes
the build environment as invoked by the Makefile. The error messages from
libtool are somewhat misleading, but the fix is to invoke libtool with the
"-no-undefined" flag.  The fix requires adding this flag to the LINK_LIBRARY
macro in ./builds/unix/unix-cc.mk file.

3. Cygwin address@hidden problem. The gcc in cygwin is configured to include
startup objects, e.g. crt0.o and crtbegin.o, so the linking process wants to
find a "main()" when linking the library (under control of libtool).
Unfortunately, libcygwin.a provides such a function in libcmain.o, which has
an undefined symbol address@hidden A search of mailing lists yielded one, icky
solution: provide a dummy "main()" to avoid picking up the one in
libcmain.o. I provided a file "cygwin_hack.c" with the content:
   main()
   {  return 0; }
Build it into a shared object, i.e. "gcc -o cygwin_hack.lo -c
cygwin_hack.c", then add it to the objects passed for the library linking
(defined in ./builds/unix/unix-cc.mk).

My final change to unix-cc.mk (for probs #2 and #3) is:
# Library linking
#
LINK_LIBRARY = $(LIBTOOL) --mode=link $(CCraw) -no-undefined -o $@ \
                          cygwin_hack.lo $(OBJECTS_LIST) \
                          -rpath $(libdir) -version-info $(version_info)

# EOF
Not the most elegant solution. I'm sure adding this extra .c file could be
accomplished in a better way.

4. Error in post-install scripts for libtool. There are two boo-boos in the
post-install script that calls out incorrect file names in libtool. The
definition of the command "postinstall_cmds" about line 206 of libtool
builds file names incorrectly for cygwin. (1) The postinstall_cmds attempts
to source the file "libfreetype.lai" using the variables "$dir/${file}i to
build the file name.  On cygwin, the shared library file name is
"libfreetype.dll.a", i.e. this is "$file".  My fix was to hardcode the
correct name ("$dir/libfreetype.lai"), since I could not find a variable
with that supplied the proper suffix.  (2) The postinstall_cmds attempts to
pass a file name to the install program as "./libs/$dlname" which is really
a subdirectory of ./objs (not just .), so changed the file specification to
"$dir/$dlname".

Good luck,
JEff Russell
PhD Student
University of Texas at Austin