Unanswered Questions

I've noticed that the BinUtils package contains a mingw32/bin directory beside of the bin directory, and the binaraies in mingw32/bin directory are byte-for-byte the same as the ones in bin.

I was curious to understand what this duplication is standing for.

With thanks :)

Yannick - Hibou57

Re: Unanswered Questions

keith's picture

Maybe it would have been better to ask on the mailing list.

This probably does merit a brief article on the wiki, but I'll have to get back to you on that. In brief:

  • Any tools you run from the command line need to be found in your PATH; the copies in <mingw-root>/bin serve that.
  • When you run a GCC front-end driver, it looks in its own target architecture specific local path first, (think cross-compilers for multiple target architectures, installed into a common directory hierarchy); <mingw-root>/mingw32/bin services that requirement for the mingw32 target.

Re: Unanswered Questions

Hibou57's picture

I understand,

I had thought the GCC driver was also looking for back end applications in the <mingw-root>/bin directory, using the name of the back end application (ex. i386-linux-ld when cross compiling beeing hosted on Windows and targeting Linux).

I know there is a way to create hard links on Windows, but it does not work on Windows 95/98, so this will break compatibility with this plateforme (so perhaps little wrapper applications).

I do have a lot of other questions about the directory structure... I will have a look at the mailing list, as you've pointed.

Beside of the mailing list, is there an official forum as well ?

Re: Unanswered Questions

keith's picture

The mailing list is the only officially supported forum; subscribing, and posting there really is the most likely way to get quick and pertinent responses to your questions.

Your thinking on the GCC driver's back-end search mechanism is reversed; it searches first for the simple name of the application, (e.g. ld), in its target architecture specific subdirectory, before falling back to other more generic locations, and ultimately to a $PATH search. In the case of a cross-compiler, (which is more likely to be GNU/Linux hosted, targetting mingw32, than the other way around), if it doesn't find the architecture specific local back-end immediately, it is then likely to select a native host specific alternative from the more generic locations; this will usually lead to compile time failures, or worse, to the generation of code which is invalid on the intended target.

The use of copies, rather than hard links, is less to do with Win-95/98 compatibility than with the fact that most common Windows archive tools don't comprehend them. The ln command in our own MSYS distribution can easily create them, (provided the system is installed on NTFS -- even the WinNT derived variants could be installed on FAT32, which doesn't support hard links). However, if we used that feature when creating the distribution tarball, and a user were to unpack that tarball with WinZip, or with a Windows version of 7Zip, he would end up with a broken installation; (we did have one release which was broken thus, with approximately a 24 hour download window before we fixed it).

You are welcome to substitute wrapper scripts for the duplicates, in your own installation, but we will not distribute in that format; the creation and maintenance of such scripts is simply an unnecessary burden on the package maintainer, who has more important issues to which to devote his time.

Site Status

Site maintenance completed May 25th, 2012 at 12:38 UTC