1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
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 ac_year2038_required=no;
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.
|
