What I've found that makes porting more difficult is sometimes building all those makefiles and configuration headers. Under Linux and most Unix like O.S. you would run a configure script that guesses most of your system peculiarities (Name of the C/C++ compiler, which headers and libraries are present, whether a function is broken...). But OS/2 is not Unix --nor even similar-- and there are enough differences to break up those configuration scripts, even if you already have a good sh-like shell.
OK, it was the state of the question until now. This port of Autoconf introduces a set of scripts and macro files able to build scripts that work well under OS/2 with EMX using all those wonderful ports of GNU utilities. But hey, that's not all. Now those scripts will work under unix as well!
#include <sys/types.h>
line in every test,
so that EMX doesn't issue all those warnings.
SET AC_MACRODIR=c:/apps/autoconfBeware with slashes: you must use `/', not `\'.
set AWK=e:/usr/bin/gawk.exe
e:/usr +--->e:/usr/bin +--->e:/usr/info ... +--->e:/usr/local +--->e:/usr/local/bin +--->e:/usr/local/info ...and e:/usr/bin and e:/usr/local/bin are in the PATH environment variable. When installing, Autoconf chooses the root directory you tell it (in my system it could be either e:/usr or e:/usr/local), builds several directories inside it and uses them to stores script, texinfo and macro files. Let's say `root' is e:/usr/local. Then
[From within CMD.EXE] sh configure --prefix=your_root_directory [From within SH.EXE] configure --prefix=your_root_directorywhere sh is the name of your unix-like shell. This will tipically find m4, awk --and perl.exe in case you have it-- and create customized makefiles for autoconf.
For example, in the system described above, I would use
sh configure --prefix=e:/usr/local
Note: You can either use make.exe, or even call x11make.exe if you have the XFreeOS/2 programmer's toolkit. But never use a simple make as the XFreeOS/2 make.cmd script could get in your way.
make.exe installand you'll have the scripts, the macro files and the info files installed.
Note: if you ever need to move autoconf to another directory, you'll have to either reinstall using this procedure, or define the environment variables listed in "Install from the binaries".
[From within CMD.EXE] sh -c "autoconf --clean" [From within SH.EXE] autoconf --clean
autoconf --auxfiles
autoconf --cleanThis should be done every time configure is rebuilt or after anything in your system changed (new programs installed, new PATH, etc) so that configure finds out those changes.
autoconf
Alternatively, you can export environment variables before using configure overriding the checks it could do. See Tips and Tricks for more about this.
configure --helpwill inform you about the available options (programs to build, extensions, checks to avoid or include, etc), whereas
configure --prefix=d:/usrwill configure using default options and defining the root directory to be /usr.
In the configuration process Autoconf may introduce absolute pathnames in the code of your program. This will typically happen, either when config.h is created, or by explicit defines when compiling. You might have to add code to let the user override these paths.
OTOH, you might find hand-made rules in aclocal.m4 or in configure.in that check whether a path reference is absolute or not. Typically it looks like in this example:
... case "$LD" in /*) ac_program_LD="$LD";; *) #some other stuff ...This must be fixed in the following compatible mode:
... case "$LD" in /* | [a-zA-Z]:*) ac_program_LD="$LD";; *) #some other stuff ...The fixed rule recognizes drive unit names. Also, as the colon ":" is not a valid path character under unix, it causes no big harm.
CC=gcc MAKE=make.exe CXX=gcc CPP="gcc.exe -E" CFLAGS="-O2 -Zmt" CXXFLAGS="-O2 -Zmt" LDFLAGS="-Zexe -Zmt -Zcrtdll -Zsysv-signals -Zbin-files" CONFIG_SHELL=shNotice the -Zexe flag. It is here to ease your work: if you use it, you will not need to edit the Makefile. OTOH, it is a temporary solution. See below for more on program name extensions.
The flags can be overriden. Either edit the generated configure file or set environment variables
[From within CMD.EXE] set MAKE=x11make.exe set CFLAGS=-O2 set CFLAGS=-O2 set LDFLAGS=-Zexe -Zcrtdll -Zsysv-signals [From within SH.EXE] export MAKE=x11make.exe export CFLAGS=-O2 export CFLAGS=-O2 export LDFLAGS="-Zexe -Zcrtdll -Zsysv-signals"or let the configure program run and, at the end, edit config.status changing the variables to suit your needs. (See below)
The default settings are good for X11 programs and won't harm when porting any other kind of application. If you opt to use them, please follow these two rules (extracted from the XFreeOS/2 porting guide):
extern int errno;Autoconf-ready code shouldn't cause this problem but if it does, enclose the sentence with a
#ifdef __EMX__
, and make sure the program
or library includes #include <errno.h>
. This is a temporary
solution: you should tell the author of the application about this
unportable feature (we are not only speaking about OS/2) and recommend
him/her to check the existence of <errno.h>
with an
appropiate rule.
O_BINARY, O_TEXT, "t", "b"
) in
the code. If you do so, use #ifdef __EMX__
to selectively
introduce the patches.
[From within CMD.EXE] sh config.status [From within SH.EXE] config.statuswill reprocess all af the *.in files. This is useful when you want to discard changes introduced in the makefiles or in config.h.
s%@CFLAGS@%-O2 -Zmt%g s%@CXXFLAGS@%-O2 -Zmt%g s%@LDFLAGS@%-Zexe -Zmt -Zcrtdll -Zsysv-signals -Zbinfiles%gto
s%@CFLAGS@%-O2%g s%@CXXFLAGS@%-O2%g s%@LDFLAGS@%-Zexe -Zcrtdll -Zsysv-signals%gthus removing the already commented flags (See above).
The following sections explain how rules are to be modified in order to make them OS/2 compatible. These changes are simple ones and should be notified to the maintainers together with an explanation of where to get this port of Autoconf and its compatible nature.
Name | Definition | Output (OS/2) | Output (Unix) | Target |
---|---|---|---|---|
AC_EXE_NAME(file) | file${EXE_EXT} | file.exe | file | Binary executable file |
AC_SCR_NAME(file) | file${SCR_EXT} | file.cmd | file | Script file |
AC_LIB_NAME(file) | ${LIB_PRE}file${LIB_EXT} | file.a | libfile.a | Library file (Static) |
AC_OBJ_NAME(file) | file${OBJ_EXT} | file.o | file.o | Object file |
if test -s $ac_dir/ld; then ac_prog_LD=$ac_dir/ld else ... fishould become
if test -s $ac_dir/AC_EXE_NAME(ld); then ac_prog_LD=$ac_dir/AC_EXE_NAME(ld) else if test -s $ac_dir/AC_SCR_NAME(ld); then ac_prog_LD=$ac_dir/AC_SCR_NAME(ld) else ... fi fiThe fixed code now understands the right names in OS/2 and adds the possibility of the program (ld) being wrapped with a batch script. Notice the double fi.
An example of code that has to be fixed using this rule is this one:
AC_PATH_PROG(INETD, inetd, /usr/libexec/inetd, $PATH:/usr/libexec:/usr/sbin:/usr/etc:etc)The fixed version looks like this:
AC_PATH_PROG(INETD, inetd, /usr/libexec/inetd, AC_JOIN_PATHS($PATH,/usr/libexec,/usr/sbin,/usr/etc,etc)
AC_DEFUN(AC_LOOP_OVER_PATH, [ IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS="${IFS}$PATH_IFS" for ac_dir in ifelse($#, 2, [AC_FORMAT_PATH([$2$ac_dummy])], $FPATH); do $1 done IFS="$ac_save_ifs" ])
It takes two parameters:
An example of a rule that should be written using this macro is the following piece of code extracted form Libtool's aclocal.m4:
[case "$LD" in /*) ac_cv_path_LD="$LD" # Let the user override the test with a path. ;; *) IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS="${IFS}:" for ac_dir in $PATH; do test -z "$ac_dir" && ac_dir=. if test -f "$ac_dir/ld"; then ... fi done IFS="$ac_save_ifs" ;; esac])The fixed version is
[case "$LD" in /*|[a-zA-Z]:*) ac_cv_path_LD="$LD" # Let the user override the test with a path. ;; *) AC_LOOP_OVER_PATH( [ test -z "$ac_dir" && ac_dir=. if test -f "$ac_dir/AC_EXE_NAME(ld)"; then ... fi]) esac])
When reporting bugs, follow these steps:
[From CMD.EXE and SH.EXE:] sh -x d:/usr/local/bin/autoconf 2>&1 1>error0.logto invoke it and e-mail me the error0.log file. Notice the use of Autoconf's full path name and the lack of the -c option.
autoconf --debugto rebuild the configure script that doesn't seem to work.
configure 2>&1 error.logand e-mail me the error.log, config.log, config.status and config.cache files. You should also send me any *.in and *.m4 files. You can pack them with any well-known archiver (ZIP, tar+gzip, LZH, ZOO).
Remember: