|
From: | Bruno Haible |
Subject: | Re: INSTALL updates |
Date: | Fri, 23 Jun 2023 17:42:07 +0200 |
Paul Eggert wrote: > > There are more and more random users, who are not experts and who try the > > git checkout of a GNU package, rather than the newest release. And then > > wonder, for example, why the INSTALL file suggests to run './configure' > > although no 'configure' file is present. [1] > > [1] https://savannah.gnu.org/bugs/?62196 > > Good point. And this is not the only reason INSTALL is out of date. I > took a shot at fixing this by installing the second attached patch into > Autoconf and propagating it into Gnulib. Comments welcome of course. Thanks for doing this modernization! Comments: * I find the mention of 'bootstrap' and autopull.sh + autogen.sh well done: it goes into enough detail so that people who did a 'git clone ...' are not stuck, while at the same time keeping the focus on the tarball users. * The wording regarding --build and --host is misleading and, IMO, backwards. Reasons: 1) './configure --help' says --build=BUILD configure for building on BUILD [guessed] --host=HOST cross-compile to build programs to run on HOST [BUILD] whereas in the INSTALL file we read: ‘--build=TYPE’ Build for architecture TYPE. The latter is wrong, IMO. "Build for", in my understanding, is --host=TYPE. 2) I have experience building for many system types, and I only give the --host option, never the --build option. * The --build type is always guessed correctly. And if it were not guessed correctly, it's not enough to specify --build. It should also be reported upstream. * The term "cross-compiler" is ambiguous, because is it "cross compiling" when - compiling for i386-linux-gnu on a x86_64-linux-gnu machine? - compiling for aarch64-linux-gnu on a x86_64-linux-gnu machine that has the binfmt support enabled for executing aarch64 binaries through qemu? - compiling for i386-w64-mingw32 on a x86_64-pc-cygwin host? Different people will given different responses to these questions. 3) Cross-compilation can easily run into trouble when one specifies CC or --host but not both. The text should recommend to specify both in this case. 4) The section "System Type" starts with a hint to a use-case: "Usually, assuming the package is built to be run on the *same* architectures ..." but then gets back to this use-case way too late, only after having explained two other use-cases. A proper doc structure should mention the three use-cases one by one. 5) It mentions the --target option before mentioning --host. But many more people use cross-compilation (including the three cases above) than there are people who build GCC themselves. Find here a proposed patch. For ease of review, find also the HTML-formatted chapter: `makeinfo --html --no-split install.texi`.
0001-INSTALL-Clarify-build-host-target-and-the-system-typ.patch
Description: Text Data
Next: Compilers and Options Installation InstructionsCopyright © 1994–1996, 1999–2002, 2004–2017, 2020–2023 Free Software Foundation, Inc. Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without warranty of any kind.
Basic InstallationBriefly, the following shell commands: test -f configure || ./bootstrap ./configure make make install should configure, build, and install this package.
The The following more-detailed instructions are generic; see the README file for instructions specific to this package. Some packages provide this INSTALL file but do not implement all of the features documented below. The lack of an optional feature in a given package is not necessarily a bug. More recommendations for GNU packages can be found in Makefile Conventions in GNU Coding Standards. If the The It can also use an optional file (typically called config.cache and enabled with --cache-file=config.cache or simply -C) that saves the results of its tests to speed up reconfiguring. Caching is disabled by default to prevent problems with accidental use of stale cache files. If you need to do unusual things to compile the package, please try to
figure out how The file configure.ac (or configure.in) is used to create
configure by a program called The simplest way to compile this package is:
Next: Compiling For Multiple Architectures, Previous: Basic Installation Compilers and OptionsSome systems require unusual options for compilation or linking that the
You can give ./configure CC=gcc CFLAGS=-g LIBS=-lposix See Defining Variables and Preset Output Variables in Autoconf for more details. Next: Installation Names, Previous: Compilers and Options Compiling For Multiple ArchitecturesYou can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you can use GNU With a non-GNU Some platforms, notably macOS, support “fat” or “universal” binaries, where a single binary can execute on different architectures. On these platforms you can configure and compile just once, with options specific to that platform. Next: Optional Features, Previous: Compiling For Multiple Architectures Installation NamesBy default, ‘make install’ installs the package’s commands under
/usr/local/bin, include files under /usr/local/include, etc.
You can specify an
installation prefix other than /usr/local by giving
You can specify separate installation prefixes for architecture-specific
files and architecture-independent files. If you pass the option
--exec-prefix=prefix to In addition, if you use an unusual directory layout you can give options like --bindir=dir to specify different values for particular kinds of files. Run ‘configure --help’ for a list of the directories you can set and what kinds of files go in them. In general, the default for these options is expressed in terms of ‘${prefix}’, so that specifying just --prefix will affect all of the other directory specifications that were not explicitly provided. The most portable way to affect installation locations is to pass the
correct locations to The first method involves providing an override variable for each
affected directory. For example, ‘make install
prefix=/alternate/directory’ will choose an alternate location for all
directory configuration variables that were expressed in terms of
‘${prefix}’. Any directories that were specified during
The second method involves providing the ‘DESTDIR’ variable. For
example, ‘make install DESTDIR=/alternate/directory’ will prepend
‘/alternate/directory’ before all installation names. The approach
of ‘DESTDIR’ overrides is not required by the GNU Coding
Standards, and does not work on platforms that have drive letters. On
the other hand, it does better at avoiding recompilation issues, and
works well even when some directory options were not specified in terms
of ‘${prefix}’ at Next: Specifying a System Type, Previous: Installation Names Optional FeaturesIf the package supports it, you can cause programs to be installed with
an extra prefix or suffix on their names by giving Some packages pay attention to --enable-feature
and --disable-feature options
to Some packages offer the ability to configure how verbose the execution
of Next: Creating binaries for a different system type, Previous: Optional Features Specifying a System TypeThe following sections go into details regarding situations where you may have to specify a system type, either through the option --host=type, or through the option --build=type, or – in the case of compilers – through --target=type. A system type type can either be a short name like ‘mingw64’, or a canonical name like ‘x86_64-pc-linux-gnu’ which has the form: cpu-company-system where system can have one of these forms: os kernel-os See the file config.sub for the possible values of each field. If config.sub isn’t included in this package, then this package doesn’t need to know any machine type. The file config.sub is a program that validates and canonicalizes a system type. It can do canonicalization, as in $ sh config.sub x86_64-linux x86_64-pc-linux-gnu $ sh config.sub arm64-linux aarch64-unknown-linux-gnu It also validates the parts. For example, this interaction tells you that “crusoe” is not a valid cpu architecture name: $ sh config.sub crusoe-linux Invalid configuration `crusoe-linux': machine `crusoe-unknown' not recognized Next: Fixing a “cannot guess build type” error, Previous: Specifying a System Type Creating binaries for a different system typeWhen you want to create binaries that will run on a different machine type than the one you are building on, you need to specify both
For example, to create binaries intended to run on a 64-bit ARM processor: ./configure --host=aarch64-linux-gnu \ CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ If you do this on a machine that can execute such binaries (e.g. by
virtue of the Next: Configuration options specific to a compiler, Previous: Creating binaries for a different system type Fixing a “cannot guess build type” errorIn rare cases, it may happen that If this resolves the problem, feel free to report the solution to the maintainers of this package. Otherwise, it means that your system is not yet supported by config.guess and config.sub. As a workaround, you can use a configure option --build=type, where type comes closest to your system type. Also, you’re welcome to file a report to config-patches@gnu.org. Next: Sharing Defaults, Previous: Fixing a “cannot guess build type” error Configuration options specific to a compilerIf you are building a compiler, and this compiler should generate code for a system type that is different from the one on which the compiler binaries shall run on, use the option --target=type to select the type of system for which the compiler should produce code. Next: Defining Variables, Previous: Configuration options specific to a compiler Sharing DefaultsIf you want to set default values for
Next: Defining VariablesVariables not defined in a site shell script can be set in the
environment passed to ./configure CC=/usr/local2/bin/gcc causes the specified Unfortunately, this technique does not work for CONFIG_SHELL=/bin/bash ./configure CONFIG_SHELL=/bin/bash Previous: Defining Variables
|
[Prev in Thread] | Current Thread | [Next in Thread] |