Binutils with MCST patches
bfd | ||
binutils | ||
config | ||
gas | ||
gdb | ||
include | ||
ld | ||
readline | ||
configure | ||
configure.in | ||
INSTALL | ||
Makefile.in | ||
README.configure |
Configuration Last Mod Fri Apr 12 13:32:56 PDT 1991, by rich@sendai "Theory": In this document, the word "host" refers to the environment in which this source will be compiled. "host" and "host name" have nothing to do with the proper name of your host, like "ucbvax", "prep.ai.mit.edu" or "att.com". Instead they refer to things like "sun4" and "dec3100". Forget for a moment that this particular directory of source is the source for a development environment. Instead, pretend that it is the source for a simpler, more mundane, application, say, a desk calculator. Source that can be compiled in more than one environment, generally needs to be set up for each environment explicitly. The word "target" refers to the environment produced by compiling this source and installing the resulting binaries. For example, if configured for host sun4 and target sun4, this implies that we will compile on a sun4 to create a sun4 compilation environment. If configured for host sun3 and target a29k, this implies that we will compile on a sun3 to create an a29k compilation environment. Host sun3 only implies that the source will be compiled on a sun3. In fact, it need not be actually compiled on a sun3. If the appropriate native development tools, header files, libraries, and operating system support were available on a foobox, then source configured for a sun3 could be compiled on a foobox, resulting in a development environment for, using the previous example host+target pair, "a29k" on the foobox. Similarly, if the appropriate cross development tools, header files, and libraries were available on a dec3100, then source configured for host sun3 could be cross compiled to create an a29k development environment intended to be run on a sun3. Usage: Gdb's config has features not yet present in the uniform configuration scheme described here. For this reason, configuration of gdb must currently be done separately from that of the rest of this package. This will be corrected soon. For more information on the configuration of gdb, please refer to the documents in gdb.{your target} if it exists, otherwise gdb. By "configures", I mean that links, Makefile, .gdbinit, and config.status are built. Configuration is always done from the source directory. * "./configure name" configures this directory, perhaps recursively, for a single host+target pair where the host and target are both "name". If a previous configuration existed, it will be overwritten. * "./configure +host=hostname targetname" configures this directory, perhaps recursively, for a single host+target pair where the host is hostname and target is targetname. If a previous configuration existed, it will be overwritten. * "./configure +forcesubdirs +host=hostname targetname" creates a subdirectories Host-hostname and Host-hostname/Target-targetname and configures Host-hostname/Target-targetname. For now, makes should be done from Host-hostname/Target-targetname. "./configure +f name" works as expected. That is, it creates Host-name and Host-name/Target-name and configures the latter. Hacking configurations: The configure scripts essentially do three things, create subdirectories if appropriate, build a Makefile, and create links to files, all based on and tailored to, a specific host+target pair. The scripts also create a .gdbinit if appropriate but this is not tailored. The Makefile is created by prepending some variable definitions to a Makefile template called Makefile.in and then inserting host and target specific Makefile fragments. The variables are set based on the chosen host+target pair and build style, that is, if you use subdirectories or not. The host and target specific Makefile may or may not exist. If fragments * Makefiles can be editted directly, but those changes will eventually be lost. Changes intended to be permanent for a specific host should be made to the host specific Makefile fragment. This should be in ./config/hmake-host if it exists. Changes intended to be permanent for a specific target should be made to the target specific Makefile fragment. This should be in ./config/tmake-target if it exists. Changes intended to be permanent for the directory should be made in Makefile.in. To propogate changes to any of these, either use "make Makefile" or re-configure from the source directory. * configure can be editted directly, but those changes will eventually be lost. Changes intended to be permanent for a specific directory should be made to configure.in. Changes intended to be permanent for all configure scripts should be made to configure.template. Propogating changes to configure.in requires the presence of configure.template which normally resides in the uppermost directory you received. To propogate changes to either configure.template or a configure.in, use "configure +template=absolutepathtothetemplate". This will configure the configure scripts themselves, recursively if appropriate. * "configure -srcdir=foo" is not supported yet. At the moment, things will probably be configured correctly only for leaf directories, and even they will not have paths to libraries set properly.