--- 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
586-pc-win32
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:
i586-pc-mks
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
environment:
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
another.
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
library.
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
makefiles.
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
i586-win32-mks-msvc
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 worlds largest e-mail service with MSN Hotmail.
http://www.hotmail.com
--- End Message ---