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