| 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 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 |
| 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 |
| |
| |
| |
| |
