I recently needed to investigate how to build Bash under Msys. Unfortunately, I found the existing pages a little confusing and they seemed to miss out some information. So, after some tinkering with environments, I've come up with the following steps that should guarantee an environment suitable for building Bash.

I have tried this successfully on two different computers both using Windows XP. This page consolidates information from other pages on this wiki.

Termios.h man page Prolog. This manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (consult the corresponding.

• From the SourceForge MinGW/MSYS web page ( download and install the following files in the order given; note the additonal instructions for some of the steps: • MinGW-5.1.4.exe (Windows installer). • I used H: MinGW as the installation folder. • MSYS-1.0.10.exe (Windows installer). • I used H: MSYS 1.0 as the installation folder.

• As part of the MSYS installation you can set up MSYS's /etc/fstab to mount your MinGW installation. It's easiest to do this in the penultimate step of the installer in the command prompt it displays. The default (which I used) was to mount H: Mingw as /mingw • msysDTK-1.0.1.exe (Windows installer).

• Install this 'over' the MSYS installation from the previous step, i.e. Set the installation folder to be the same as that for MSYS. In my example, this was H: MSYS 1.0. This exe is found under the heading 'msysDTK-1.0.1' which might need to be 'expanded' by clicking on the '+' button next to the heading name. • flex-2.5.33-MSYS-1.0.11-1.tar.bz2 • Extract 'over' the MSYS installation. • bison-2.3-MSYS-1.0.11-1.tar.bz2 • Extract 'over' the MSYS installation. • regex-0.12-MSYS-1.0.11-1.tar.bz2 • Extract 'over' the MSYS installation.

• bash-3.1-MSYS-1.0.11-1-src.tar.bz2 -- source code for Bash. • Extract into /home/ to get /home//bash-3.1-MSYS-1.0.11-1 Note that / = root of MSYS installation, i.e H: MSYS 1.0. • As per the instructions at I downloaded and unpacked the archive which is available from the MinGW SourceForge page. It should be extracted 'over' the MSYS installation and it doesn't overwrite anything that is in the MSYS installation. It simply adds more files. • The header file termios.h needs to be updated for building Bash. Change line 48 of /lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h (in the MSYS installation) from #define CTRL('c'h) ((ch)&0x1F) to #define CTRL(ch) ((ch)&0x1F) (Taken from • Start the MSYS build environment - double click the MSYS icon on the desktop.

This will open a shell with title MINGW. Enter the command 'msysdvlpr' and hit enter.

This will open a new shell window with title MSYS which has the MSYS build environment set up. You must use this new window for the remaining steps. The first shell can be closed after the new one has started. • cd to /home//bash-3.1-MSYS-1.0.11-1 and make a subdirectory to build in. For some strange reason, the MSYS build environment doesn't like building in the same folder as the source code (did I read this correctly???). Let's say you created /home//bash-3.1-MSYS-1.0.11-1/my_build • cd to /home//bash-3.1-MSYS-1.0.11-1/my_build • Set the variable MSYS_PREFIX=/usr • OPTIONAL: if you wish, you can alter the function 'shell_version_string' in the C file /home//bash-3.1-MSYS-1.0.11-1/version.c to have some additional text to indicate that it really is your version of Bash running when you 'echo $BASH_VERSION'. • Run./configure --prefix=$MSYS_PREFIX (Can take a very long time if your machine is older than about 2 or 3 years).

• Run 'make' to build Bash. Note: you might need to create /home// yourself as I don't recall if the MinGW or MSYS installers seem to. I think one does and the other doesn't, if I recall correctly. See also the following for more hints and suggestions: [FIXME: these references all point to the old, now-defunct MinGWiki; the original pages need to be migrated]. MinGW/MSYS Source Forge home page: Notes: • I hope this doesn't tread on anyone's toes, but even our Linux guru at work had trouble setting this up in the first instance. So apologies in advance if it does • I was also able to build make and the coreutils (except for some man-page errors) with the same build environment.

• NOTE (14 October 2008): looks like this page needs a bit of an update as some of the locations have changed. I'll try to do it one weekend in October 2008! Thanks for that.

Yes, we know we have a security problem: I have been removing inappropriate 'wow' related junk since around Christmas 2008, and blocking the accounts used to create it; ('wow_account' has been blocked for several days). Unfortunately, SourceForge have blocked the communications channels required to establish user bona-fides, when an account is created; thus we are forced to either:-- • Allow any user to create an account, and immediately create or modify wiki content, without additional validation; (this is the current configuration). • Allow any user to create an account, but require them to submit all proposed postings for approval, until such time as they have demonstrated trustworthiness. If the wiki abuse continues, we may have to adopt the latter policy; however, while the spam remains manageable, we prefer not to do so, as this would not be in the wiki spirit of publicly co-operative site maintenance. Quote: For some strange reason, the MSYS build environment doesn't like building in the same folder as the source code (did I read this correctly???) It's actually dependent on the source package you are building; some will allow building in the source directory, some will not. IIRC, GCC itself will not even permit building in any subdirectory of the source tree. However, why do you consider this strange?

It is, in fact, good practice to always build in a different directory from the source; any package which does not support such building, (commonly known as `VPATH' or `out-of-source' building), is deficient, IMO. Directing you to build in a separate directory is merely encouraging good practice.

I thought it was strange compared to the many, many Linux packages that I have 'built' following the standard 'tar, configure, make' routine. I think I was being a bit imprecise here; by 'built' I meant run 'configure' and 'make'. I don't ever recall having to create a subdirectory of the untar'd package in order to run configure from. In particular, I have built bash on Linux and didn't need to create a subdirectory to run configure and make in.

Hence, it seemed strange to find that for MSYS it was suggested to do so. Or, have I've completely mis-read something and that's not what it meant at all? Sorry for the delay -- I missed this follow up, when you posted it.

I think it strange that you even consider building 'in-source'; there are so many advantages to keeping the build and source directories separate, that I just use this technique as a matter of course. Sure, there are many packages which will support building either way, and it is a matter of personal preference which you choose; there are, however, some packages which simply cannot be built 'in-source', under any circumstances, while there are others, (broken, IMO), which can only be built 'in-source'. As to why some packages can be built 'in-source' on GNU/Linux, but require 'out-of-source' building on MS-Windows, there can be any number of reasons for this. One, which immediately comes to mind, is make-goal conflicts introduced by the case insensitive nature of the MS-Windows file system; autoconf is one package which exhibits such a conflict, requiring an 'out-of-source' build on MS-Windows, where GNU/Linux can happily support building either in or out-of source. A further point: you say 'I don't recall ever having to create a subdirectory of the untarred package.' You should not do this anyway; it is better to create the build directory as a sibling of the top level source directory, not as a descendant of it. (In fact, if you ever try to build GCC 'in-source', or in any descendant of the top level source directory, then your build will fail miserably, on any platform).

I also missed your posting. Whilst a long-time user of Linux, I'm relatively new to building applications on Linux, so naturally I tend to follow the build and installation instructions supplied with the tar.gz packages. I'd be first to admit my memory isn't perfect, but as far as I remember, almost all of them imply that you should build 'in-source', which is why I thought it strange to create a separate build directory.

Here are a couple of examples: --------------------------Python 2.6.1-------------------------- To start building right away (on UNIX): type './configure' in the current directory and when it finishes, type 'make'. This creates an executable './python'; to install in /usr/local, first do 'su root' and then 'make install'. --------------------------Bash Basic Installation ====== These are installation instructions for Bash. The simplest way to compile Bash is: 1. `cd' to the directory containing the source code and type `./configure' to configure Bash for your system. Urdu Poem Video Free Download here.

If you're using `csh' on an old version of System V, you might need to type `sh./configure' instead to prevent `csh' from trying to execute `configure' itself. Running `configure' takes some time. While running, it prints messages telling which features it is checking for. Type `make' to compile Bash and build the `bashbug' bug reporting script. It's these types of instructions that made me regard building 'in-source' to be 'standard'. Should these instructions be considered as being in need of improvement? I do, however, accept your point that it is good practise to keep the source tree clean, so I do try to do so when possible.

Regarding your comment regarding the sibling directory, I was referring to the my_build directory in the following: /home//bash-3.1-MSYS-1.0.11-1/my_build and when I said 'subdirectory', I meant a descendant of /home//bash-3.1-MSYS-1.0.11-1 - the 'top level package directory'. Did you mean that it should be a sibling of /home//bash-3.1-MSYS-1.0.11-1?? If I understand correctly what you mean by 'top level source directory', /home//bash-3.1-MSYS-1.0.11-1/my_build is a sibling of it, and /home//bash-3.1-MSYS-1.0.11-1 is what I call the 'top level package directory' that contains the 'top level source directory'. Or is your 'top level source directory' what I refer to as the 'top level package directory'?

Saying that you may build in-source doesn't necessarily imply that you should, but yes, those packages which suggest this practice do their users a disservice, IMO; the advantages of an out-of-source build are much too significant, to be dismissed in such cavalier fashion. Art Of Prometheus Pdf Writer. I consider any package which cannot be built out-of-source to be broken. Conversely, there are some packages which simply cannot be built in-source. GCC is one such; try it, and it will fail spectacularly. Even trying to build it at any subdirectory level within its source tree will result in guaranteed failure.

By sibling, I mean a directory with the same parent as the top level directory in the individual package's source tree. I typically set it up like this: all-package-sources::-- foo-package::-- build::::-- foo-package:: (where 'build' is a sibling of 'foo-package', and therefore, 'build/foo-package' is a nephew), and then do: $ cd all-package-sources/build/foo-package $././foo-package/configure. But it doesn't need to be that immediate; you could even have the source tree on a read-only file system, and should still be able to build, with the build tree on a completely different file system device.