[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fw: MKS toolkit the 2nd

From: Werner LEMBERG
Subject: Fw: MKS toolkit the 2nd
Date: Sun, 08 Sep 2002 09:12:22 +0200 (CEST)

I think that the remarks below are interesting for the autoconf
people also.


--- Begin Message --- Subject: Re: MKS toolkit the 2nd Date: Sat, 07 Sep 2002 22:13:10 -0700
To Werner Lemberg's suggested change to config.guess


Ben Elliston replied:

This is not quite right, for a couple of reasons.  Firstly,
config.guess should output the machine architecture in a format that
is consistent with other systems detected by config.guess.
I would recommend that you follow the lead here and use, for example:


Since it's really "mks" that offers a Unix-like environment on top of
the Win32 kernel.

To which Werner Lemberg replied:

A documented list of allowed values for config.sub and the
configuration types recognized by config.guess would be great...

I'll second Werner's comment; I made the original suggestion of
"586-pc-win32" for lack of information as to the desired format.  It's a
simple matter to provide the desired format if folks know what that
format is ...

It's easy enough to have config.guess provide output in the desired
format, but doing so doesn't mean much unless that information is put to
good use.  The configure scripts often seem to fail for the silliest of
reasons (although finding all causes of failure usually is anything but
trivial).  It would seem to me that at least five things are significant
in characterizing "PC" environments as they affext the GNU build

o  The CPU architecture
o  The operating system
o  Available Unix-like utilities
o  The C/C++ compiler
o  Run-time extensions (such as libraries that implement fork() and
   other Unix APIs)

Some of the characteristics of these elements that determine success or
failure of configure scripts include

Operating System
o  System calls/APIs.  Some (or all) non-ANSI features, such as fork(),
   are not available unless supplemented by run-time extensions such as
   CYGWIN, MKS NutCRACKER, and (I think) UWIN.

o  Pathname.  Under MS-DOS/MS-Windows, pathname separators can be
   either '\' or '/'; however, some older application software cannot
   handle '/', so a safe practice is to use '\'.  Without quoting, many
   Unix-like commands (especially the shell or echo) will interpret '\'
   as an escape character, and can interpret '\'<char> as an escape
   sequence when the first letter of a pathname component is a, b, c,
   f, r, or n.  These behaviors are the cause of many configuration
   script failures when pathname components are obtained from the OS
   (e.g., `echo $PATH`).

   One solution is to require that all environmment variables used in
   one way or another (e.g., 'echo $0' usually makes use of PATH) by
   configure be defined with forward slashes, at least in the shell
   that is used to invoke configure; another would be to include a
   utlility that converted backslashes to slashes e.g.,

       `echo \'slash $0\''

o  PATH component separators.  When the PATH component separator is ';'
   as is the case with MS-DOS/MS-Windows, quoting may be needed to
   prevent the ';' from being interpreted as a command terminator.

o  Allowable filename characters.  Under Win 32, a space is a valid
   character in a pathname.  Quoting might be one solution; requiring
   the use of "dossified" pathnames (e.g., c:/Progra~1/... ) might be

o  Filename length limitations.  MS-DOS and Windows 3.x impose the 8.3
   limit on any component of a pathname.  It's hard for me to see
   MS-DOS as a major platform anymore, though.

o  Filename suffixes, for both the required Unix-like utilities and
   files created by the compilers.  With MS-DOS/MS-Windows, commands
   most probably have .exe suffixes (though I suppose '.com' is
   remotely possible),

Unix-like utilities
   The MKS Toolkit provides most of the Unix-like utilities that GNU
   builds require, although the commands have '.exe.' extensions, and
   in many cases the available options are limited to those covered by
   the POSIX 1003 standards.

   There are several versions of the 'MKS Toolkit'.  I think all
   provide the utilities needed for GNU builds, but some also include
   libraries that emulate Unix system calls such as fork().  I assume
   that the CYGWIN and UWIN environments are similar, but I have no
   direct experience.

   Even Microsoft offer a rudimentary set of Unix-like utilites.

The C/C++ compiler
o  Source, object, and library file suffixes.  The Microsoft C++
   compiler accepts filename suffixes '.cpp' and '.cxx' as C++ source,
   but does not recognize '.cc' Almost anything is accepted as an
   object file (though anyting without a '.obj' suffix generates a
   warning).  Only '.lib' is recognized as a valid suffix for a

   MSVC (actually, the C/C++ compiler cl) has options that force it to
   accept files with other or no suffixes to be treated as C++ source,
   but they create more problems than they solve.  The simplest
   solution would seem to be a script that renames C++ source files to
   have '.cpp' extensions rather than '.cc', or perhaps use of '.cpp'
   rather than '.cc' as the default suffix for GNU C++ source if gcc
   and other compilers accept this.  Werner had suggested a suffix rule
   that made .cpp files from .cc by copying; this also should work,
   except that one would need to ensure that edits always were made to
   the '.cc' files rather than to the derivative '.cpp' files.

   The only simple solution I can see for object files and libraries is
   the use of OBJEXT and LIBEXT variables in configure and in

o  MSVC includes several non-ANSI Unix-like extensions, but in most
   cases prepends a '_' to the function names (e.g., _dup).  Sometimes
   the leading '_' is mandatory, sometimes it is not.  In some cases
   the number and meaning of function parameters are different from
   their Unix counterparts.

   Macro definitions or #ifdefs could handle leading underscores, at
   the expense of slightly more ugly code for Unix-like systems.

   For practical purposes, errors arising from such name differences
   will be found at run time, and usually aren't difficult to fix.

Run-Time Extensions
o  Emulated System Calls.  Some environments, such as CYGWIN, MKS
   NutCRACKER, and (I think) UWIN, provide libraries that emulate
   Unix-like system calls such as fork().  At least in theory, this can
   be independent of availablity (or lack thereof) of Unix-like
   utilities.  Although the presence of such utilities often allows GNU
   code to compile without modification, certain calls, such as fork()
   are implemented at a high cost in CPU time, so alternative coding
   for "PC" environments may be preferable.

   The case probably could be made that such considerations are far
   beyond the scope of the configure script, and consequently
   irrelevant to the output of config.guess.

In any event, it would seem to me that something like


should provide the necessary information to configure.  Again, the exact
format of the output isn't as important as how the information is used.
Obviously, the changes to config.guess are considerably simpler that the
corresponding changes to the configure script.

Jeff Conrad

Join the worldÂ’s largest e-mail service with MSN Hotmail.
--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]