2

When I am running a line like:

./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu {*shortened*} \
--with-imap-ssl=/usr/include/openssl/ --enable-ftp --enable-mbstring --enable-zip

I understand what the "x86_64-redhat-linux-gnu" means descriptively, but I have questions?

1) Is there a list somewhere of all the choices? Either in each configure script or on the internet.

2) Does making the answer more specific or more generic have much of an effect on the outcome?

Thank you.

3

The --build and -host options are to configure scripts are standard configure options, and you very rarely need to specify them unless you are doing a cross-build (that is, building a package on one system to run on a different system). The values of these options are called "triples" because they have the form cpu-vendor-os. (Sometimes, as in your case, os is actually kernel-os but it's still called a triple.)

The base configure script is quite capable of deducing the host triple, and you should let it do that unless you have some really good evidence that the results are incorrect. The script which does that is called config.guess, and you'll find it somewhere in the build bundle (it might be in a build-aux subdirectory). If you're doing a cross-build and you need to know the host triple, the first thing to try is to run config-guess on the host system.

The values supplied (or guessed) for --host and --build are passed through another script called config.sub, which will normalize the values. (According to the autoconf docs, if config.sub is not present, you can assume that the build doesn't care about the host triple.) The developers of a specific software package might customize the config.sub script for the particular needs of their build, and there are a lot of different versions of the standard config.sub script, so you shouldn't expect config.sub from one software package to work on another software package, or even on a different version of the same software package.

Despite all the above, autoconf'ed software packages really should not need to know the names of the host os and vendor, except for identifying default filesystem layout so that they provide the correct default file locations.

You can read through config.sub to get an idea of the range of options which will be recognized, but it is not so easy to figure out how the values are used, or even if the values are used. The first field -- the cpu -- is the most likely to be used.

You can get a list of all the options by typing:

./configure --help

or, better,

./configure --help | less

since there are always a lot of options.

Other than the standard options (--build, --host and --target as above, and the options which override file locations), the specific options allowed by each configure script are different. Since they also tend to change from version to version of the software package, you should always check the configure script itself rather than relying on external documentation.

Unfortunately, the contents of the configure script's help are not always 100% complete, because they rely on the package developers to maintain them. Sometimes unusual or developer-only options are not part of the ./configure --help output, but that is usually an indication that the option should not be used in a normal install.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.