README-install

   1 Please see the file INSTALL for generic build and installation instructions.
   2 This file details coreutils and system specific build instructions.
   3
   4
   5 *********************
   6 Pre-C99 build failure
   7 ---------------------
   8
   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.
  18
  19
  20 ***********************
  21 HPUX 11.x build failure
  22 -----------------------
  23
  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:
  33
  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__
  39
  40
  41 ************************
  42 OSF/1 4.0d and AIX build failures
  43 ------------------------
  44
  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.
  51
  52
  53 ************************
  54 32 bit time_t build failures
  55 ------------------------
  56
  57 On systems where it's determined that 64 bit time_t is supported
  58 (indicated by touch -t <some time after 2038>), but that coreutils
  59 would be built with a narrower time_t, the build will fail.
  60 This can be allowed by passing TIME_T_32_BIT_OK=yes to configure,
  61 or avoided by enabling 64 bit builds.  For example GCC on AIX defaults
  62 to 32 bit, and to enable the 64 bit ABI one can use:
  63 ./configure CFLAGS=-maix64 LDFLAGs=-maix64 AR='ar -X64'
  64
  65
  66 *************************************************
  67 "make check" failure on IRIX 6.5 and Solaris <= 9
  68 -------------------------------------------------
  69
  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.
  72
  73
  74
  75 **********************
  76 Running tests as root:
  77 ----------------------
  78
  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:
  89
  90   sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root
  91
  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.
  96
  97
  98
  99 **********************
 100 autotools considerations:
 101 ----------------------
 102
 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.
 107
 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.