Please see the file INSTALL for generic build and installation instructions. This file details coreutils and system specific build instructions. ********************* Pre-C99 build failure --------------------- In 2009 we added this requirement: To build the coreutils from source, you must have a C99-conforming compiler, due to the use of declarations after non-declaration statements in several files in src/. There is code in configure to find and, if possible, enable an appropriate compiler. However, if configure doesn't find a C99 compiler, it continues nonetheless, and your build will fail. There used to be a "c99-to-c89.diff" patch you could apply to convert to code that even an old pre-c99 compiler can handle, but it was too tedious to maintain, so has been removed. *********************** HPUX 11.x build failure ----------------------- A known problem exists when compiling on HPUX on both hppa and ia64 in 64-bit mode (i.e., +DD64) on HP-UX 11.0, 11.11, and 11.23. This is not due to a bug in the package but instead due to a bug in the system header file which breaks things in 64-bit mode. The default compilation mode is 32-bit and the software compiles fine using the default mode. To build this software in 64-bit mode you will need to fix the system /usr/include/inttypes.h header file. After correcting that file the software also compiles fine in 64-bit mode. Here is one possible patch to correct the problem: --- /usr/include/inttypes.h.orig Thu May 30 01:00:00 1996 +++ /usr/include/inttypes.h Sun Mar 23 00:20:36 2003 @@ -489 +489 @@ -#ifndef __STDC_32_MODE__ +#ifndef __LP64__ ************************ OSF/1 4.0d and AIX build failures ------------------------ If you use /usr/bin/make on these systems, the build will fail due to the presence of the "[" target. OSF/1 make(1) appears to treat "[" as some syntax relating to locks, while AIX make(1) appears to skip the "[" target. To work around these issues the best solution is to use GNU make. Otherwise, simply remove all mention of "[$(EXEEXT)" from src/Makefile. ************************ 32 bit time_t build failures ------------------------ Although 32-bit builds fail if that forces time_t to be 32 bits, this can be fixed by using 64-bit builds. For example, on AIX where GCC defaults to 32 bits, one can use "./configure CC='gcc -maix64' AR='ar -X64'"; similarly, on Solaris one can configure with CC='gcc -m64'. If all else fails one can configure with --disable-year2038; however, this will mishandle timestamps after 2038, and please file bug reports for any such situations. ************************************************* "make check" failure on IRIX 6.5 and Solaris <= 9 ------------------------------------------------- Using the vendor make program to run "make check" fails on these two systems. If you want to run all of the tests there, use GNU make. ********************** Running tests as root: ---------------------- If you run the tests as root, note that a few of them create files and/or run programs as a non-root user, 'nobody' by default. If you want to use some other non-root username, specify it via the NON_ROOT_USERNAME environment variable. Depending on the permissions with which the working directories have been created, using 'nobody' may fail, because that user won't have the required read and write access to the build and test directories. I find that it is best to unpack and build as a non-privileged user, and then to run the following command as that user in order to run the privilege-requiring tests: sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root If you can run the tests as root, please do so and report any problems. We get much less test coverage in that mode, and it's arguably more important that these tools work well when run by root than when run by less privileged users. ********************** autotools considerations: ---------------------- WARNING: Now that we use the ./bootstrap script, you should not run autoreconf manually. Doing that will overwrite essential source files with older versions, which may make the package unbuildable or introduce subtle bugs. WARNING: If you modify files like configure.in, m4/*.m4, aclocal.m4, or any Makefile.am, then don't be surprised if what gets regenerated no longer works. To make things work, you'll have to be using appropriate versions of the tools listed in bootstrap.conf's buildreq string.