Common tasks and useful tips for porting Unix software to OS/2

This page explains some common code changes often necessary to make Unix software work properly on OS/2. These changes are mainly related to various components shared among Unix programs. These changes are tracked here since we don't normally push upstream and hence we should apply them in each new project that we port and that uses these components.

Common tasks

Fix POTFILES generation

The fix is applied to po.m4 that creates rules for POTFILES generation. Unfortunately, the upstream version doesn't take DOS drive letters into account and hence creates incorrect relative paths in the generated POTFILES file (like ../D:/Coding/myproject/trunk/...). Here is a typical fix: r1009. When applied, configure and friends need to be regenerated in the source tree and then configure needs to be re-run to generate proper Makefiles.

Fix HAVE_ICONV detection

The fix is applied to iconv.m4 that detects if the HAVE_ICONV config.h macro should be set or not. Here is a typical fix: r1023 (originally this: r934). When applied, configure and friends need to be regenerated in the source tree and then configure needs to be re-run to generate a proper config.h.

Fix EOLs in git-version-gen

Some projects use the build-aux/git-version-gen script to define the project version in configure.ac. The "stock" version of this script doesn't understand CRLF as line terminators which leads to a corrupt configure. The fix is rather simple and can be seen here: r968.

Fix OS/2 DLL name in libtool

When libtool is used to generate project DLLs, such a DLL often gets a version number in its name (e.g. libpixman-1.so.0, where pixman-1 is the base DLL name and 0 is the major version number). However, on OS/2 the version information cannot follow the extension and hence it must be put into the name part. But the name part is limited to 8 chars so libtool has to cut the base DLL name by default to make the appended major version number fit the limit. In case of the pixman this would give us pixman-0.dll which looks misleading (the correct name is pixman10.dll in this case).

A proper solution here is to force libtool use a special, short version of the base name for the DLL file (and only for it — all other files, such as the import library name, should carry the original name so that the linker can find it). This is done using the -shortname libtool option. Where to add it varies from project to project but the typical place is the _la_LDFLAGS variable in Makefile.am for the library. See r1232 for a real-life example.

Have libtool adding a buildlevel string to the DLL

With the latest libtool it is possible to have a buildlevel string built into a dll. To do so you need to teach the Makefile how to handle it. Most likely it is the best practice to change Makefile.am and then do a sh -c "autoreconf -fvi". How to adjust a Makefile.am can be seen here: r1823

Add OS/2 specific build details to Autoconf-based packages

Method 1. If configure.ac already uses AC_CANONICAL_TARGET or AC_CANONICAL_HOST macros, then you can add the following excerpt to it to do OS/2-specific job ($target_os becomes $host_os if AC_CANONICAL_HOST is used instead of AC_CANONICAL_TARGET):

case "$host_os" in
os2*)
	# Increase stack size to 8MB
	export LDFLAGS="$LDFLAGS -Zstack 0x2000"
esac

Method 2. If the above AC_CANONICAL macros are not used, then it will be simpler to use uname to do the OS/2-specific job:

case `uname -s 2>/dev/null` in
OS/2)
	# Increase stack size to 8MB
	export LDFLAGS="$LDFLAGS -Zstack 0x2000"
esac

Note though that if you need to add such a block more than once, it makes sense to add AC_CANONICAL_TARGET right after AC_INIT to configure.ac and go with Method 1 described above.