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