Writing A Cygwin Friendly Package

Text vs Binary Modes

As discussed in the section called Text and Binary Files in the chapter called Writing Portable C with GNU Autotools, text and binary files are different on Windows. Lines in a Windows text files end in a carriage return/line feed pair, but a C program reading the file in text mode will see a single line feed.

Cygwin has several ways to hide this dichotomy, and the solution(s) you choose will depend on how you plan to use your program. I will outline the relative tradeoffs you make with each choice:

     # _AB_AC_FUNC_FOPEN(b | t, USE_FOPEN_BINARY | USE_FOPEN_TEXT)
     # -----------------------------------------------------------
     define([_AB_AC_FUNC_FOPEN],
     [AC_CACHE_CHECK([whether fopen accepts "$1" mode], [ab_cv_func_fopen_$1],
     [AC_TRY_RUN([#include <stdio.h>
     int
     main ()
     {
        FILE *fp = fopen ("conftest.bin", "w$1");
        fprintf (fp, "\n");
        fclose (fp);
        return 0;
     }],
                 [ab_cv_func_fopen_$1=yes],
                 [ab_cv_func_fopen_$1=no],
                 [ab_cv_func_fopen_$1=no])])
     if test x$ab_cv_func_fopen_$1 = xyes; then
       AC_DEFINE([$2], 1,
                 [Define this if we can use the "$1" mode for fopen safely.])
     fi[]dnl
     ])# _AB_AC_FUNC_FOPEN
     
     # AB_AC_FUNC_FOPEN_BINARY
     # -----------------------
     # Test whether fopen accepts a "" in the mode string for binary file
     # opening.  This makes no difference on most unices, but some OSes
     # convert every newline written to a file to two bytes (CR LF), and
     # every CR LF read from a file is silently converted to a newline.
     AC_DEFUN([AB_AC_FUNC_FOPEN_BINARY], [_AB_AC_FUNC_FOPEN(b, USE_FOPEN_BINARY)])
     
     # AB_AC_FUNC_FOPEN_TEXT
     # ---------------------
     # Test whether open accepts a "t" in the mode string for text file
     # opening.  This makes no difference on most unices, but other OSes
     # use it to assert that every newline written to a file writes two
     # bytes (CR LF), and every CR LF read from a file are silently
     # converted to a newline.
     AC_DEFUN([AB_AC_FUNC_FOPEN_TEXT],   [_AB_AC_FUNC_FOPEN(t, USE_FOPEN_TEXT)])
     
     
     # _AB_AC_FUNC_OPEN(O_BINARY|O_TEXT)
     # ---------------------------------
     AC_DEFUN([_AB_AC_FUNC_OPEN],
     [AC_CACHE_CHECK([whether fcntl.h defines $1], [ab_cv_header_fcntl_h_$1],
     [AC_EGREP_CPP([$1],
                   [#include <sys/types.h>
     #include <sys/stat.h>
     #include <fcntl.h>
     $1
     ],
                   [ab_cv_header_fcntl_h_$1=no],
                   [ab_cv_header_fcntl_h_$1=yes])
     if test "x$ab_cv_header_fcntl_h_$1" = xno; then
       AC_EGREP_CPP([_$1],
                    [#include <sys/types.h>
     #include <sys/stat.h>
     #include <fcntl.h>
     _$1
     ],
                     [ab_cv_header_fcntl_h_$1=0],
                     [ab_cv_header_fcntl_h_$1=_$1])
     fi])
     if test "x$ab_cv_header_fcntl_h_$1" != xyes; then
       AC_DEFINE_UNQUOTED([$1], [$ab_cv_header_fcntl_h_$1],
         [Define this to a usable value if the system provides none])
     fi[]dnl
     ])# _AB_AC_FUNC_OPEN
     
     
     # AB_AC_FUNC_OPEN_BINARY
     # ----------------------
     # Test whether open accepts O_BINARY in the mode string for binary
     # file opening.  This makes no difference on most unices, but some
     # OSes convert every newline written to a file to two bytes (CR LF),
     # and every CR LF read from a file is silently converted to a newline.
     #
     AC_DEFUN([AB_AC_FUNC_OPEN_BINARY], [_AB_AC_FUNC_OPEN([O_BINARY])])
     
     
     # AB_AC_FUNC_OPEN_TEXT
     # --------------------
     # Test whether open accepts O_TEXT in the mode string for text file
     # opening.  This makes no difference on most unices, but other OSes
     # use it to assert that every newline written to a file writes two
     # bytes (CR LF), and every CR LF read from a file are silently
     # converted to a newline.
     #
     AC_DEFUN([AB_AC_FUNC_OPEN_TEXT],   [_AB_AC_FUNC_OPEN([O_TEXT])])
     
     
      

Add the following preprocessor code to a common header file that will be included by any sources that use fopen calls:

#define fopen rpl_fopen

Save the following function to a file, and link that into your program so that in combination with the preprocessor magic above, you can always specify text or binary mode to open and fopen, and let this code take care of removing the flags on machines which do not support them:

#if HAVE_CONFIG_H # include <config.h> #endif #include <stdio.h> /* Use the system size_t if it has one, or fallback to config.h */ #if STDC_HEADERS || HAVE_STDDEF_H # include <stddef.h> #endif #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif /* One of the following headers will have prototypes for malloc and free on most systems. If not, we don't add explicit prototypes which may generate a compiler warning in some cases -- explicit prototypes would certainly cause compilation to fail with a type clash on some platforms. */ #if STDC_HEADERS || HAVE_STDLIB_H # include <stdlib.h> #endif #if HAVE_MEMORY_H # include <memory.h> #endif #if HAVE_STRING_H # include <string.h> #else # if HAVE_STRINGS_H # include <strings.h> # endif /* !HAVE_STRINGS_H */ #endif /* !HAVE_STRING_H */ #if ! HAVE_STRCHR /* BSD based systems have index() instead of strchr() */ # if HAVE_INDEX # define strchr index # else /* ! HAVE_INDEX */ /* Very old C libraries have neither index() or strchr() */ # define strchr rpl_strchr static inline const char *strchr (const char *str, int ch); static inline const char * strchr (const char *str, int ch) { const char *p = str; while (p && *p && *p != (char) ch) { ++p; } return (*p == (char) ch) ? p : 0; } # endif /* HAVE_INDEX */ #endif /* HAVE_STRCHR */ /* BSD based systems have bcopy() instead of strcpy() */ #if ! HAVE_STRCPY # define strcpy(dest, src) bcopy(src, dest, strlen(src) + 1) #endif /* Very old C libraries have no strdup(). */ #if ! HAVE_STRDUP # define strdup(str) strcpy(malloc(strlen(str) + 1), str) #endif char* rpl_fopen (const char *pathname, char *mode) { char *result = NULL; char *p = mode; /* Scan to the end of mode until we find 'b' or 't'. */ while (*p && *p != 'b' && *p != 't') { ++p; } if (!*p) { fprintf(stderr, "*WARNING* rpl_fopen called without mode 'b' or 't'\n"); } #if USE_FOPEN_BINARY && USE_FOPEN_TEXT result = fopen(pathname, mode); #else { char ignore[3]= "bt"; char *newmode = strdup(mode); char *q = newmode; p = newmode; # if ! USE_FOPEN_TEXT strcpy(ignore, "b") # endif # if ! USE_FOPEN_BINARY strcpy(ignore, "t") # endif /* Copy characters from mode to newmode missing out b and/or t. */ while (*p) { while (strchr(ignore, *p)) { ++p; } *q++ = *p++; } *q = '\0'; result = fopen(pathname, newmode); free(newmode); } #endif /* USE_FOPEN_BINARY && USE_FOPEN_TEXT */ return result; }

The correct operation of the file above relies on several things having been checked by the configure script, so you will also need to ensure that the following macros are present in your configure.in before you use this code:

# configure.in -- Process this file with autoconf to produce configure AC_INIT(rpl_fopen.c) AC_PROG_CC AC_HEADER_STDC AC_CHECK_HEADERS(string.h strings.h, break) AC_CHECK_HEADERS(stdlib.h stddef.h sys/types.h memory.h) AC_C_CONST AC_TYPE_SIZE_T AC_CHECK_FUNCS(strchr index strcpy strdup) AB_AC_FUNC_FOPEN_BINARY AB_AC_FUNC_FOPEN_TEXT

File System Limitations

We discussed some differences between Unix and Windows file systems in the section called File system Issues in the chapter called Writing Portable C with GNU Autotools. You learned about some of the differences between Unix and Windows file syatems. This section expands on that discussion, covering filename differences and separator and drive letter distinctions.

Executable Filename Extensions

As I already noted in the section called Package Installation, the fact that Windows requires that all program files be named with the extension .exe, is the cause of several inconsistencies in package behaviour between Windows and Unix.

For example, where Libtool is involved, if a package builds an executable which is linked against an as yet uninstalled library, libtool puts the real executable in the .libs (or _libs) subdirectory, and writes a shell script to the original destination of the executable [2] , which ensures the runtime library search paths are adjusted to find the correct (uninstalled) libraries that it depends upon. On Windows, only a PE-COFF executable is allowed to bear the .exe extension, so the wrapper script has to be named differently to the executable it is substituted for (i.e the script is only executed correctly by the operating system if it does not have an .exe extension). The result of this confusion is that the Makefile can't see some of the executables it builds with Libtool because the generated rules assume an .exe extension will be in evidence. This problem will be addressed in some future revision of Automake and Libtool. In the mean time, it is sometimes necessary to move the executables from the .libs directory to their install destination by hand. The continual rebuilding of wrapped executables at each invocation of make is another symptom of using wrapper scripts with a different name to the executable which they represent.

It is very important to correctly add the .exe extension to program file names in your Makefile.am, otherwise many of the generated rules will not work correctly while they await a file without the .exe extension. Fortunately, Automake will do this for you where ever it is able to tell that a file is a program - everything listed in bin_PROGRAMS for example. Occasionaly you will find cases where there is no way for Automake to be sure of this, in which case you must be sure to add the $(EXEEXT) suffix. By structuring your Makefile.am carefully, this can be avoided in the majority of cases:

TESTS = $(check_SCRIPTS) script-test bin1-test$(EXEEXT)

could be rewritten as:

check_PROGRAMS = bin1-test TESTS = $(check_SCRIPTS) script-test $(check_PROGRAMS)

The value of EXEEXT is always set correctly with respect to the host machine if you use Libtool in your project. If you don't use Libtool, you must manually call tyhe Libtool macro, AC_EXEEXT in your configure.in to make sure that it is initialiesed correctly. If you don't call this macro (either directly or implicity with AC_PROG_LIBTOOL), your project will almost certainly not build correctly on Cygwin.