www.delorie.com/gnu/docs/zlibc/zlibc_28.html   search  
Buy GNU books!


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6. Porting zlibc

Zlibc has been tested on three variants of Unix so far: Linux, SunOs, Solaris. On all three platforms, zlibc has been compiled using GNU make and gcc. However, porting it to other platforms should be straightforward as long as they verify both of the following conditions:

  1. The target platform should have shared library support. The default Makefile links zlibc by supplying the flags -nostdlib -shared to gcc in addition to the usual CFLAGS. If your target platform needs different flags to make shared libraries, change the definition of the variable SHAREDCFLAGS in the Makefile.
  2. The target platform should supply a way to perform system calls directly without going through the library functions. Indeed, this is needed because we are redefining the library functions and thus the default functions become unavailable.

    Usually direct syscalls done by calling the syscall function. For instance, in order to perform open("test", O_RDONLY) directly, sycall(SYS_open, "test", O_RDONLY) is called.

    If your target platform uses a different way to perform direct system calls, you need to supply different definitions for the real_xxx functions in direct_sys.h. This is the case for AIX.

  3. The target platform should provide a way to instruct the dynamic linker to preload programs with extra object files not present in the shared library. Any symbols defined in that object file override equivalent symbols from libc. Usually this is done by pointing the LD_PRELOAD variable to the object file to be used. Unfortunately, I have found no way to achieve this on AIX. Any ideas about how to do this are welcome.

Many platforms, including Solaris, provide several aliases for their syscall stubs. It would be interesting to leave one of them alone, and use it as a "direct syscall" stub, but unfortunately, it turns out that in sometimes both stubs are used by the library! Thus, what would be an advantage, becomes actually a disadvantage, because we will need to override these aliases in addition to the canonical names. This is done in altnames.c. Change it as needed. In order to know the names of these aliases, try the following command: nm /lib/libc.so | grep lstat. This lists any library symbols with unlink in their name, which could be aliases.

If you have successfully ported zlibc to a new platform, could you drop me a note, so that I can include support for that platform in my next release. Thanks

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

  webmaster     delorie software   privacy  
  Copyright 2003   by The Free Software Foundation     Updated Jun 2003