![]() |
Using The GNU Configure Scripts In OS/2Written by Dale DePriest |
IntroductionThis article describes the ability to use GNU configure scripts within the OS/2 environment. These configure scripts are a key tool in permitting the automatic configuration of source code among a wide divergence of Unix systems. Extending their use to OS/2 opens the possibility of much more high quality and easily available software than we might otherwise enjoy. People have been porting Unix applications to OS/2 for years and this article hopes to help continue this practice by making the task a bit easier. Of course if you are using a Unix script to configure and port Unix applications and utilities you might expect that the tools would depend upon a Unix environment. And this is indeed the case. Luckily pioneers in this effort have already developed most of the tools needed to establish a Unix environment for you. Names like Eberhard Mattes (The E and M of EMX) and Kai Rommel have already built many of the tools that you may need. Eberhard has supplied and continues to enhance a Unix-like linkable shared library layer plus a modified version of the GNU C compiler that supports most of the syntax and semantics of the Unix C language. While EMX supplies GCC as part of the installation there is no reason to believe that it requires GCC in order to work. EMX itself is a set of libraries that could be linked to any C or C++ compiler. Kai Rommel has used EMX to port many of the Unix utility commands into the OS/2 environment as well. These commands are needed both by the configure scripts and by many of the Unix makefiles. Many other people have contributed to this effort as well and many Unix-like commands are available from other sources. Using The KSH ShellIn order to run the configure script you will need a Unix shell. This article describes the KSH shell currently released on hobbes and many other FTP sites. It is freely available and you can also obtain the source if you wish to build a modified copy for you own use. Unlike many of the earlier porting efforts of Unix code the OS/2 version is fully integrated into the source thus providing you the assurance that when the source changes, the OS/2 variants will be carried forward. The sources themselves are called pdksh, the public domain korn shell, and implement a very good emulation of the original AT&T Korn shell plus many POSIX enhancements. The configure script itself, however, does not require any Korn shell features but rather depends on the older Bourne shell syntax and semantics, of which a Korn shell is a superset. You should be able to use any good implementation of a Bourne shell to run this script. The shell itself can be called any name you wish. Its behavior does not
vary based on the name unlike some other Unix shell programs. To run the
configure script it should be named sh.exe. Using the sources you can
build many different variations of the shell using options in the
Configure scripts assume the presence of Unix commands so you will need to insure that you have the correct selection available for the shell and that they are in your current search path. If you get command not found errors when running the script you will need to find (and download if necessary) a copy of the appropriate command. There are several Unix commands that have exactly the same names as OS/2 commands so be sure the Unix versions are earlier in the search path. In Unix an executable is tagged with an attribute to make it known to the
system as an executable. In OS/2 this is done with an extension. This can
lead to unique problems when running the configure scripts. KSH knows all
of the standard OS/2 extensions plus .ksh and .sh; and, as a special
feature, it can even run commands that do not have any extensions. Most
often commands in Unix do not have any extensions and scripts either have
no extension or use the name of the shell as an extension. This is only a
Unix convention, not a requirement, and to execute a Unix command you must
type the exact filename. In OS/2 the .ksh or .sh extension tells the KSH
that this is an executable shell script. A file without an extension may
be either a script or a binary executable. Scripts need not necessarily be
a KSH shell scripts however. The standard Unix
Running Unix GNU Configure ScriptsKSH can be used to run GNU configure scripts, however, I can't guarantee that the results will match the true configuration for OS/2 since this is dependent on the way the individual configure scripts are written. You should expect that you may have to hand modify the configure script, the results of the configure, or at the very least check the results to insure that they look reasonable. Even in Unix itself the scripts may not always correctly identify a particular idiosyncrasy of a particular hardware platform configuration. To set up to run configure scripts you will need to have a copy of KSH
called
At some point the configure script will build a config.status script to
perform the final step. If this is not run using
' Many configure scripts actually build and execute small programs to test for certain features of the operating system or compiler. In OS/2 using EMX, the final link step for a program must have the .exe extension tied to the executable name or the linker will not link correctly. A few configure scripts already know about this requirement and will work OK, but, unfortunately most do not. You may need to modify the configure script to insure the correct executable name. Once the program is built it can be renamed to a name without an extension if KSH is being used to run it since often the script also checks to see if a file with this name was created by the compiler. A line similar to the following may work for you if you are using a version 2.0 configure: ac_link='${CC-cc} -o conftest.exe $CFLAGS $CPPFLAGS $LDFLAGS \ conftest.$ac_ext $LIBS && mv conftest.exe conftest'Figure 1) Modification for using Configure 2.0 This trick takes advantage of KSH's ability to run a command without an extension. Even with these changes you may still find that configure does not correctly identify some OS/2 features. Many configure scripts reuse a line like ac_lnk many times over the course of running the program, however some scripts use unique names each time they build a test program. For these configure programs it may be impractical to modify the script. EMX has a feature that permits it to attempt to fake this requirement for makefiles and configure scripts. By setting a compiler variable (usually LD, see EMX documentation for details) to include -Zexe you can force the link step to build an executable with the .exe extension on it and to create an empty file with just the name. This empty file is meant to satisfy Unix makefiles and may fool configure scripts as well. I say *may* because some configure scripts not only check for the existence of the executable name but also expect it to have size! These configure scripts wont be fooled. Unfortunately the KSH ability to run a file without an extension can cause
a conflict with the EMX feature to automatically build two files with the
same name but a different extension. KSH will try and execute the dummy
file and will fail. There are several ways correct this problem. If you
know the name of the file then an easy solution is to define an alias for
KSH use. For example the command
* Building The ExecutableOnce you have gotten configure to successfully run, you should find a config.h file containing the platform customization flags and a makefile in the directory containing the sources. You may need to edit the config.h file either now or as a result of errors that you define during your compilation attempt. In addition you will probably need to edit the Makefile. Makefile edits depend somewhat on which make command you use. I usually use either make from GNU or nmake from IBM. Both are available from hobbes. At the very least you should insure that the executable name ends with the .exe extension or modify the gcc flags to include -Zexe. It is likely that even with all of the changes and customizations you will
still need to put some #ifdef statements in the source to get it to perform
correctly for OS/2 use. I usually include a -DOS2 option in my makefile
GCC compiler flags to permit a
|