From: Keith M. <kei...@us...> - 2008-03-25 18:44:35
|
Summarising the follow-up discussion, and taking the opportunity to add my own two pennyworth:-- On Sunday 23 March 2008 12:45, Roland Schwarz wrote: > With the mingw 3.4.5 release it was possible to invoke > the compiler just by calling with an absolute path without > the need to set up the path variable before. > > This is not true anymore for 4.2.1. I get a CreateProcess: > No such file or directory error message instead. > Has this been changed intentionally? No. Assuming that you are using one of our pre-built binary packages for binutils-2.18.50, the follow-up discussion suggests that this is an inadvertent packaging bug; thanks for alerting us. On Sunday 23 March 2008 16:47, John E. / TDM wrote: > Looking at the output of `path-to-mingw\gcc.exe -print-search-dirs`, > it should be fairly obvious what's happening. For the programs search > directories, there is no path corresponding to the root "bin" > directory, which is where your binutils executables live. There is, > however, a path corresponding to "path-to-mingw\mingw32\bin", which > is an alternate location for the binutils tools. For a workaround, > you can try copying the binutils executables there. (Depending on > which binutils release you have, there may already be some empty > files there -- I have seen this packaging bug with the 2.18.50 > release.) On Monday 24 March 2008 01:07, Danny Smith wrote: > [path-to-mingw\mingw32\bin] is not the alternate location. This is > the first place the compuiler looks. That is where binutils package is > supposed to install them. On Monday 24 March 2008 02:48, John E. / TDM wrote: > That's good to know. Does this indicate a packaging bug in the > binutils 2.18.50 tech preview, since they were built with a different > target triplet (i686-pc-mingw32)? Yes. I do not want to point any "finger of blame", for witch hunts serve no useful purpose. The underlying cause of the problem lies in the complete absence of any agreed and formally documented policy on how the MinGW packages should be prepared for release; for that, the project team, as a whole, is collectively responsible. > If not, I think it should at least merit a warning to the effect > of "since this build uses a newer target triplet, you have to have the > bin directory in your PATH". It *is* a packaging bug. For those afflicted by it, this is a possible workaround, although perhaps not the most effective one. On Monday 24 March 2008 12:12, JonY wrote: > I noticed that some packages using autotools which would fail when > the mingw provided gcc 3.4.5 which was targeted at mingw32 and a > newer user built binutils which was targeted at i686-pc-mingw32 was > used. It was looking for the ld linker in the wrong place. As Danny pointed out, the correct installation path, as *he* specified it for his MinGW-GCC builds is /path/to/mingw/mingw32/{bin,lib}; if we accept that as the standard, (and it seems reasonable, and as good as any to me), then... > The newer binutils executables would reside in /mingw/bin and > /mingw/i686-pc-mingw32. The problem only happens when /mingw/mingw32 > containing the older binutils was removed. the implicit `i686-pc-mingw32' target specification used when building the binutils-1.18.50 binary package is only the apparent cause of the packaging bug; the real underlying cause is lack of an appropriately documented packaging methodology. The reason this didn't show up, until you removed the older binutils from /path/to/mingw/mingw32/{bin,lib} was that GCC was actually *using* these older tools; you may have thought you had installed the newer binutils, but you were never using it. > Problem fixed by using junction points to link mingw32 and > i686-pc-mingw32 together. This is another possible workaround, but I wouldn't classify it as a "fix"; the only ultimately acceptable "fix" is to rebuild the binary package, with the appropriately agreed target specification, repackage and replace the defective binary release tarballs on the SF download site, and mirrors. For those afflicted by this bug, a further possible workaround would be to physically *move* everything from /path/to/i686-pc-mingw32/{bin,lib} into the corresponding /path/to/mingw/mingw32/{bin,lib} trees, in place of any similarly named component files which are already there; of the three workarounds suggested, this would be my preferred choice, as I would expect it to restore everything to the state it should be in, to conform with Danny's previous de-facto build standard. On Monday 24 March 2008 11:51, Earnie Boyd wrote: > I thought the target was supposed to be stated without the triplet, > meaning --target=mingw32, for the distributed binaries since i686-pc > has little relevance to MinGW. I agree that `i686-pc', (as such, or with any other CPU designation), has little relevance for MinGW; formalising the de-facto use of just `mingw32' here makes sense to me. It does seem somehow anomalous to be required to specify *any* form of `--target=target_alias', for self-hosted (native) builds, or even of crossed-native builds, of any package; indeed, it would be unnecessary for building of the entire tool chain as a single integrated package. In the particular case of MinGW, however, it *is* necessary, to allow for mixing and matching of component packages at different release points, and from different maintainers. This particular problem has arisen because the binutils-2.18.50 tech preview has been built with no `--target=target_alias' specified, on an i686 host, so target_alias has been implicitly determined, by running config.guess, and the resultant `i686-pc-mingw32' does not conform to the de-facto mingw32 standard. There is a lesson to be learnt here; let's not ignore it. We should take this discussion to the developers' list, where we formally agree, and document, a standard procedure for building MinGW packages for public release, so that future maintainers can understand the reasons for, and continue to follow, the standards in use today. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-03-25 19:32:37
|
Quoting Keith Marshall <kei...@us...>: > > There is a lesson to be learnt here; let's not ignore it. We should > take this discussion to the developers' list, where we formally agree, > and document, a standard procedure for building MinGW packages for > public release, so that future maintainers can understand the reasons > for, and continue to follow, the standards in use today. > We should carry it further and add a documented section for this in the wiki. Somewhere in the bowels of ancient mingw-dvlpr threads there should be a discussion on this with an agreement to use --prefix=/mingw --host=mingw32 for all distributed binary packages. I tried looking for the thread before responding and gave up after about five minutes. I did find examples[1] from Danny of his configure statement for an 2.95.3 version of GCC. [1] http://sourceforge.net/mailarchive/message.php?msg_id=20010516025237.22456.qmail%40web6402.mail.yahoo.com Earnie |
From: Keith M. <kei...@us...> - 2008-03-25 20:12:49
|
On Tuesday 25 March 2008 19:32, Earnie Boyd wrote: > Quoting Keith Marshall <kei...@us...>: > > There is a lesson to be learnt here; let's not ignore it. We > > should take this discussion to the developers' list, where we > > formally agree, and document, a standard procedure for building > > MinGW packages for public release, so that future maintainers can > > understand the reasons for, and continue to follow, the standards > > in use today. > > We should carry it further and add a documented section for this in > the wiki. That's what I had in mind; first discuss and agree the requirements here, then document and publish on the wiki or web site. > Somewhere in the bowels of ancient mingw-dvlpr threads > there should be a discussion on this with an agreement to use > --prefix=/mingw --host=mingw32 for all distributed binary packages. > I tried looking for the thread before responding and gave up after > about five minutes. I did find examples[1] from Danny of his > configure statement for an 2.95.3 version of GCC. Danny has always provided his build script, AFAICT. However, IMHO that alone isn't sufficient; it shows the `how', but it doesn't explain the `why'. Without that extra detail, a future maintainer could easily, as I did, assume that --target=mingw32 is redundant -- for a self-hosted build it normally would be -- whereas in this case it is essential. OTOH, --host=mingw32 should not be necessary for a self-hosted build, and indeed, for a crossed-native build such as I do, it would more than likely be just plain wrong. These more recent references show how I built binutils, for the purpose of regenerating the source tarball in fully `distributable' condition: http://article.gmane.org/gmane.comp.gnu.mingw.devel/2678 http://article.gmane.org/gmane.comp.gnu.mingw.user/25029 For this purpose, it was good enough, but it isn't quite correct for generating a binary distribution. Nonetheless, with a few minor, but critical corrections, it could form the basis for developing a formally standardised procedure for building binutils. Augment that with the corresponding info relating to GCC, mingw-runtime and w32api, and we're well on the way. Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2008-03-26 01:56:36
|
Apologies all, I've been really busy at work so I haven't been following the lists as closely as I normally do. > These more recent references show how I built binutils, for the purpose > of regenerating the source tarball in fully `distributable' condition: > http://article.gmane.org/gmane.comp.gnu.mingw.devel/2678 > http://article.gmane.org/gmane.comp.gnu.mingw.user/25029 I've followed Keith's examples and generated a new binutils distribution with the following options: $ ../binutils-2.18.50/configure --prefix=/mingw/ --build=mingw32 --host=mingw32 --target=mingw32 --with-gcc --with-gnu-as --with-gnu-ld --disable-nls $ make CFLAGS="-s -O2 -mms-bitfields -mtune=i686" $ make prefix=`cd ../dist;pwd` install The build is available here: http://emergedesktop.org/mingw/binutils-2.18.50-20080109-2.tar.gz Keith, perhaps you can take a quick look, once I get the OK I'll upload it to SF and post an announcement. Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Chris S. <ir0...@gm...> - 2008-03-26 15:17:45
|
I've uploaded the tarball again, for some reason the original archive had 0 byte binaries in the mingw32/bin directory: http://emergedesktop.org/mingw/binutils-2.18.50-20080109-2.tar.gz Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2008-03-26 19:29:31
|
On Wednesday 26 March 2008 01:56, Chris Sutcliffe wrote: > I've followed Keith's examples and generated a new binutils > distribution with the following options: > > $ ../binutils-2.18.50/configure --prefix=/mingw/ --build=mingw32 > --host=mingw32 --target=mingw32 --with-gcc --with-gnu-as > --with-gnu-ld --disable-nls > $ make CFLAGS="-s -O2 -mms-bitfields -mtune=i686" > $ make prefix=`cd ../dist;pwd` install You missed this step: | $ find . -type f -iname dir -exec rm -i {} + | | Note [the second of] the two find commands. The first cleans up the | source tree, if the original tarball was created for an original | source tree checked out from CVS, (as was the case for Danny's 2.17.50 | release); the second expunges any info `dir' files, which should | *never* be included in any binary distribution package; > The build is available here: > > http://emergedesktop.org/mingw/binutils-2.18.50-20080109-2.tar.gz > > Keith, perhaps you can take a quick look, once I get the OK I'll > upload it to SF and post an announcement. > I've uploaded the tarball again, for some reason the original archive > had 0 byte binaries in the mingw32/bin directory: It looks superficially ok, but you do need to repackage your dist tree once more, *after* you've removed that offending `info/dir' file; that will break the existing info database of any user who cares. Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-03-28 19:49:03
|
On Wednesday 26 March 2008 01:56, Chris Sutcliffe wrote: > > These more recent references show how I built binutils, for the > > purpose of regenerating the source tarball in fully `distributable' > > condition: http://article.gmane.org/gmane.comp.gnu.mingw.devel/2678 > > http://article.gmane.org/gmane.comp.gnu.mingw.user/25029 > > I've followed Keith's examples and generated a new binutils > distribution with the following options: > > $ ../binutils-2.18.50/configure --prefix=/mingw/ --build=mingw32 > --host=mingw32 --target=mingw32 --with-gcc --with-gnu-as > --with-gnu-ld --disable-nls > $ make CFLAGS="-s -O2 -mms-bitfields -mtune=i686" > $ make prefix=`cd ../dist;pwd` install Hmm. Seeing that all spelt out just reinforces the impression of how anomalous build = host = target = mingw32 is. Logically, one one think that, since this is a self hosted build, none of them should be needed. Unfortunately, if they are omitted, the build process guesses the target type as `i?86-pc-mingw32', and generates a tool chain structure which is incompatible with the way Danny built all our past GCC releases. When I originally worked through this exercise, I used my cross hosted i586-mingw32 tool chain, configured with `--build=i686-pc-linux' and `--host=i586-mingw32'. I didn't specify --target, since I was building a tool chain which would run on an i586-mingw32 host, targetting a similar host; thus, logically the tools would be self hosted, and any specification of --target would be redundant. This resulted in a full build of the tool chain, but naturally, I ended up with a directory name of i586-mingw32 where a standard MinGW build would have mingw32. I next tried simply adding a `--target=mingw32' to my original configure command, leaving it otherwise unchanged. This did have the effect, as expected, of building the tool chain with those components needed to support the compiler correctly placed in a `mingw32' directory, but now the public versions of the tools, and their associated man pages were all qualified by the addition of a `mingw32-' prefix on the file names. Thinking about it, that makes sense, for I've now configured it as a canadian cross, to run on an i586-mingw32 host, but to generate code for a *different* type of host, namely `mingw32'; thus the tool chain is named, to appropriately identify that target. Additionally, having built the binutils using this canadian cross method, I observed that only one of the expected libraries was built, (libiberty.a), and others that I expected were missing. I don't know why that is, and I don't have the energy to investigate further; the messages generated during the `make install' did include warnings about *.la modules not being installed, and their associated *.a modules were also missing, so I guess it's a libtool issue, but as I've never used libtool, I don't consider myself qualified to comment. The lesson here is, that to build the crossed native tool chain to both run on *and* target a `mingw32' host, we need a cross compiler which itself *directly* targets `mingw32', from the build machine. Thus, I built a new linux-x-mingw32 cross compiler, invoked for --host=mingw32 rather than --host=i586-mingw32. Sure enough, when I use that with just `--build=i686-pc-linux --host=mingw32', and omitting the --target spec altogether, I can successfully reproduce the structure of Chris' build, as I would expect. Not satisfied with this, I decided to build it again, but self hosted on the Win2K box at work -- and what a painful exercise that turned out to be. A job which completes in five or six minutes on my Ubuntu-6.06-LTS box took a full hour, on the similarly specced Win2K box, only to have it blow up at the end, because binutils-2.18.50/ld/deffilep.[ch] are missing from the binutils-2.18.50-20080109-src.tar.gz I downloaded from our SF site this morning. (I thought this had been fixed, but it was apparently overlooked; I've taken the liberty of adding an updated source tarball to Chris' latest SF release). Anyway, having eventually completed this exercise, I can confirm that neither the --host nor the --target spec is absolutely necessary in the above command, (although it does no harm to specify them in *addition* to --build); the --build spec alone is necessary and sufficient. Why should it be --build and not --host or --target? Well, the configure paradigm begins by identifying the build type; if it isn't explicitly defined by a --build spec, it is guessed, and set to the full canonical triplet, (`uname -m`-pc-mingw32, for the mingw32 build case, where we want it to simply be mingw32). Next, the runtime host is identified; if this isn't explicitly set with --host, it defaults to the same as the build spec, either as set by --build, or as guessed. Technically, it is incorrect to specify --host without --build; if the explicitly specified --host differs from the guessed --build, configure will set up the build for cross compilation, which isn't what we want for a self hosted build. Finally, configure identifies the target spec; again, if this isn't explicitly set, by a --target option, then it defaults to the setting established for --host, either as specified explicitly, or as itself inherited from --build. At this point, if the target spec differs from the host spec, then configure sets up the build to create a set of tools for deployment as a cross tool chain. You are welcome to try this for yourselves, (it takes forever to try each of the three cases on a Win32 box, if your's is as slow as mine); I already knew what to expect, but experimental proof is always better than assumed knowledge. To summarise: - Specifying only --build=mingw32 will DTRT; - Specifying only --host=mingw32 may *accidentally* DTRT, (I declined to try this one), but is technically incorrect; - Specifying only --target=mingw32 does *not* DTRT. The bottom line of all this is, for a self hosted build of binutils for public distribution, the *minimum* acceptable command sequence is: $ path/to/binutils-src configure --prefix=C:/mingw --build=mingw32 \ --with-gcc --with-gnu-as --with-gnu-ld --disable-nls $ make CFLAGS='-s -O2 -mms-bitfields -mtune=i686' $ make prefix=/path/to/dist/image install $ ( cd /path/to/dist/image ; tar cf - ) | gzip -c > $BIN_TARFILE with `/path/to/dist/image' referring to a location on a FAT file system; (to ensure that the installed image has no hard links)[1]. Alternatively, for anyone wishing to build such packages on a cross host platform, the cross compiler *must* be configured for a target which is identically equal to `mingw32', (*not* i386-pc-mingw32, nor any of the other variants we often see)[2]. With this proviso, the build commands are identically the same, *except* that: `--build=mingw32' is replaced by `--build=build-id --host=mingw32' and possibly: `--with-sysroot=/whatever' may be required. [1] This is also necessary, for cross hosted builds. [2] With this in mind, we should probably modify our cross compiler build scripts, to make the default target identifier identically equal to `mingw32', instead of the current `i386-mingw32' default. Regards, Keith. |
From: NightStrike <nig...@gm...> - 2008-03-26 04:16:29
|
On 3/25/08, Keith Marshall <kei...@us...> wrote: > > The newer binutils executables would reside in /mingw/bin and > > /mingw/i686-pc-mingw32. The problem only happens when /mingw/mingw32 > > containing the older binutils was removed. > > the implicit `i686-pc-mingw32' target specification used when building > the binutils-1.18.50 binary package is only the apparent cause of the > packaging bug; the real underlying cause is lack of an appropriately > documented packaging methodology. > > Problem fixed by using junction points to link mingw32 and > > i686-pc-mingw32 together. > > This is another possible workaround, but I wouldn't classify it as > a "fix"; the only ultimately acceptable "fix" is to rebuild the binary > package, with the appropriately agreed target specification, repackage > and replace the defective binary release tarballs on the SF download > site, and mirrors. > On Monday 24 March 2008 11:51, Earnie Boyd wrote: > > I thought the target was supposed to be stated without the triplet, > > meaning --target=mingw32, for the distributed binaries since i686-pc > > has little relevance to MinGW. > > I agree that `i686-pc', (as such, or with any other CPU designation), > has little relevance for MinGW; formalising the de-facto use of just > `mingw32' here makes sense to me. If you want to be able to have x86_64 support merge back in to mingw, then supporting the CPU designation is advantageous. To that end, supporting the gnu standard canonicalization fully is advantageous. With the way I build things, I can have both i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the same root directory structure. However, the requirement of the lone "mingw32" directory makes that difficult. |
From: Earnie B. <ea...@us...> - 2008-03-26 11:44:58
|
Quoting NightStrike <nig...@gm...>: >> >> I agree that `i686-pc', (as such, or with any other CPU designation), >> has little relevance for MinGW; formalising the de-facto use of just >> `mingw32' here makes sense to me. > > If you want to be able to have x86_64 support merge back in to mingw, > then supporting the CPU designation is advantageous. > The host/target becomes mingw64 is all. > To that end, supporting the gnu standard canonicalization fully is > advantageous. With the way I build things, I can have both > i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the > same root directory structure. However, the requirement of the lone > "mingw32" directory makes that difficult. > So you can with --host=mingw32 and --host=mingw64 as well. The triplet is really confusing, especially when i686 has no real value. Earnie |
From: NightStrike <nig...@gm...> - 2008-03-26 13:08:29
|
On 3/26/08, Earnie Boyd <ea...@us...> wrote: > > Quoting NightStrike <nig...@gm...>: > > > >> > >> I agree that `i686-pc', (as such, or with any other CPU designation), > >> has little relevance for MinGW; formalising the de-facto use of just > >> `mingw32' here makes sense to me. > > > > If you want to be able to have x86_64 support merge back in to mingw, > > then supporting the CPU designation is advantageous. > > > > The host/target becomes mingw64 is all. There are many many discussions over mingw64 NOT meaning 64-bit windows. For this reason (and others), the trailing number has been removed from mingw for canonicalized triplets. As a point of fact, the triplet for Win64 is x86_64-pc-mingw32, and will eventually become just x86_64-pc-mingw. > > To that end, supporting the gnu standard canonicalization fully is > > advantageous. With the way I build things, I can have both > > i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the > > same root directory structure. However, the requirement of the lone > > "mingw32" directory makes that difficult. > > > > So you can with --host=mingw32 and --host=mingw64 as well. The triplet > is really confusing, especially when i686 has no real value. I have 3 questions on this -- (1) Why do you and others keep saying that the cpu choice has no real value? (2) Why is the triplet confusing? (3) Why does mingw break the paradigms set up by every other gcc target? |
From: Earnie B. <ea...@us...> - 2008-03-26 18:06:20
|
Quoting NightStrike <nig...@gm...>: > On 3/26/08, Earnie Boyd <ea...@us...> wrote: >> >> Quoting NightStrike <nig...@gm...>: >> >> >> >> >> >> I agree that `i686-pc', (as such, or with any other CPU designation), >> >> has little relevance for MinGW; formalising the de-facto use of just >> >> `mingw32' here makes sense to me. >> > >> > If you want to be able to have x86_64 support merge back in to mingw, >> > then supporting the CPU designation is advantageous. >> > >> >> The host/target becomes mingw64 is all. > > There are many many discussions over mingw64 NOT meaning 64-bit > windows. For this reason (and others), the trailing number has been > removed from mingw for canonicalized triplets. As a point of fact, > the triplet for Win64 is x86_64-pc-mingw32, and will eventually become > just x86_64-pc-mingw. > And who the hell made that decision without appropriate discussion here? x86_64-pc-mingw32 of course is meaningless. x86_64-pc-mingw64 is what it should be. >> > To that end, supporting the gnu standard canonicalization fully is >> > advantageous. With the way I build things, I can have both >> > i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the >> > same root directory structure. However, the requirement of the lone >> > "mingw32" directory makes that difficult. >> > >> >> So you can with --host=mingw32 and --host=mingw64 as well. The triplet >> is really confusing, especially when i686 has no real value. > > I have 3 questions on this -- (1) Why do you and others keep saying > that the cpu choice has no real value? (2) Why is the triplet > confusing? (3) Why does mingw break the paradigms set up by every > other gcc target? > Because it only reflects the build system since the target is i386 with tunings toward i686. Since i686 isn't really targeted then it is therefore meaningless. MinGW doesn't break any paradigm, it chooses to allow those using less than i686 to use its distributions without the need to be specific for any one CPU model. x86_64-pc-mingw64 is correct because x286_64 will happen just as i186, i286, i386, i486, etc did. Earnie |
From: NightStrike <nig...@gm...> - 2008-03-26 18:40:47
|
On 3/26/08, Earnie Boyd <ea...@us...> wrote: > Quoting NightStrike <nig...@gm...>: > > On 3/26/08, Earnie Boyd <ea...@us...> wrote: > >> Quoting NightStrike <nig...@gm...>: > >> >> > >> >> I agree that `i686-pc', (as such, or with any other CPU designation), > >> >> has little relevance for MinGW; formalising the de-facto use of just > >> >> `mingw32' here makes sense to me. > >> > > >> > If you want to be able to have x86_64 support merge back in to mingw, > >> > then supporting the CPU designation is advantageous. > >> > > >> > >> The host/target becomes mingw64 is all. > > > > There are many many discussions over mingw64 NOT meaning 64-bit > > windows. For this reason (and others), the trailing number has been > > removed from mingw for canonicalized triplets. As a point of fact, > > the triplet for Win64 is x86_64-pc-mingw32, and will eventually become > > just x86_64-pc-mingw. > > > > And who the hell made that decision without appropriate discussion > here? x86_64-pc-mingw32 of course is meaningless. x86_64-pc-mingw64 > is what it should be. First, your constant aggressive tone is neither warranted nor appreciated. Please behave civilly. As to your question, it was Ben Elliston and Nick Clifton, as I recall. You can check the mailing lists and the changes to config.guess. There's also a post from Brian Dessent, as I recall (though it was over a year ago and wasn't one of the many posts by Brian that I saved), that explains why the 32 in mingw32 shouldn't specify the bit-width of the cpu. I believe he also mentioned in there that i686-pc-mingw32 is an appropriate target name. Kai was originally making patches that targetted x86_64-pc-mingw64, but all that stopped once there was reached consensus between binutils and gcc. If you were not part of that discussion, then maybe you'd like to raise it with the people that drove the change. Talking on this list about issues in binutils and gcc won't involve the right people. > >> > To that end, supporting the gnu standard canonicalization fully is > >> > advantageous. With the way I build things, I can have both > >> > i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the > >> > same root directory structure. However, the requirement of the lone > >> > "mingw32" directory makes that difficult. > >> > > >> > >> So you can with --host=mingw32 and --host=mingw64 as well. The triplet > >> is really confusing, especially when i686 has no real value. > > > > I have 3 questions on this -- (1) Why do you and others keep saying > > that the cpu choice has no real value? (2) Why is the triplet > > confusing? (3) Why does mingw break the paradigms set up by every > > other gcc target? > > > > Because it only reflects the build system since the target is i386 with > tunings toward i686. Since i686 isn't really targeted then it is > therefore meaningless. MinGW doesn't break any paradigm, it chooses to > allow those using less than i686 to use its distributions without the > need to be specific for any one CPU model. x86_64-pc-mingw64 is > correct because x286_64 will happen just as i186, i286, i386, i486, etc > did. The paradigm is that target-specific binaries and libraries should in in subdirectories of the target triplet directory. So for instance, i386-pc-mingw32/bin holds gcc.exe, whereas /bin holds i386-pc-mingw32-gcc.exe, or the default gcc.exe for the system (that is, if you are building for i386 instead of some other target, like i686). This makes it easy to have multiply-targetted compilers installed in the same root structure. In actuality, gcc currently is hard coded to look in /mingw/lib for libraries during a build of a cross compiler, which causes collisions now that there are multiple possible targets for mingw platforms. That's easy to work around, but it could be handled more elegantly. I really don't understand why you would not want to make it clear what CPU you are targetting (i386, i686, x86_64, etc.), and if you are willing to explain it in a calm manner, I'm willing to listen. |
From: Keith M. <kei...@us...> - 2008-03-26 20:47:39
|
On Wednesday 26 March 2008 18:40, NightStrike wrote: > > > There are many many discussions over mingw64 NOT meaning 64-bit > > > windows. For this reason (and others), the trailing number has > > > been removed from mingw for canonicalized triplets. As a point > > > of fact, the triplet for Win64 is x86_64-pc-mingw32, and will > > > eventually become just x86_64-pc-mingw. > > > > And who the hell made that decision without appropriate discussion > > here? x86_64-pc-mingw32 of course is meaningless. > > x86_64-pc-mingw64 is what it should be. > > First, your constant aggressive tone is neither warranted nor > appreciated. Please behave civilly. Well, Earnie may have adopted an aggressive tone, but I can readily understand the frustration that has led to it. > As to your question, it was Ben Elliston and Nick Clifton, as I > recall. Ben Elliston and Nick Clifton have no business pushing this decision through, without the courtesy of even a mention to those who officially maintain MinGW. You also mentioned Brian Dessent, who, while he is a frequent contributor to discussion on MinGW lists, has no official standing with the project, and isn't authorised in any way to speak on our behalf. So, to return to your question, what on earth could mingw64 possibly mean, if not MinGW for a 64-bit platform. The canonical form of a host triplet is CPU-VENDOR-OSTYPE. If the OSTYPE is mingw32, that is unambiguously MinGW for any one of the i[34567]86 processor family, so the CPU and VENDOR fields are completely redundant; indeed, what VENDOR does `pc' signify anyway? IBM? Sun? Fred Bloggs? It is completely meaningless, and might as well be discarded; the equally acceptable i386-unknown-mingw32 is preferable, IMO. Right. VENDOR is redundant. It conveys no useful information, when the only platform targetted by the OSTYPE is singularly identified, as it is in the case of OSTYPE == mingw32, (which targets i[34567]86 generic family processors *exclusively*). By the same token, CPU is redundant too, because it is unambiguously identified when OSTYPE == mingw32, just as OSTYPE == mingw64 would be singularly unambiguous; in either case config.sub can unambiguously canonicalise the target, *solely* on either one of these OSTYPEs: OSTYPE == mingw32 ==> i386-unknown-mingw32 OSTYPE == mingw64 ==> x86_64-unknown-mingw64 so why burden us with redundant information? We may just as well dispense with the CPU and VENDOR fields, and still have the appropriate tool chain unambiguously specified by just the OSTYPE name. > > >> > To that end, supporting the gnu standard canonicalization > > >> > fully is advantageous. With the way I build things, I can > > >> > have both i686-pc-mingw and x86_64-pc-mingw targetted > > >> > compilers installed in the same root directory structure. > > >> > However, the requirement of the lone "mingw32" directory > > >> > makes that difficult. I don't see why. The name of a tool chain does not *need* to be identified by a fully qualified canonical triplet; as long as each independent tool chain has a unique prefix, any number can live quite happily together -- indeed, as of today, I have a `mingw32' tool chain and my original `i586-mingw32' chain, co-existing in complete harmony, (and I have never included the meaningless VENDOR = pc component). > > > I have 3 questions on this -- (1) Why do you and others keep > > > saying that the cpu choice has no real value? Simply because it is already implicit in the OSTYPE == mingw32; why do you need the tautology of saying i386 twice? (Do notice that publicly distributed MinGW binaries target generic i[34567]86, so it is quite pointless to declare it to be any *specific* member of the family). > > > (2) Why is the triplet confusing? Which member of the i[34567]86 family is appropriate? To specify any particular one, other than perhaps basic i386, would be *wrong*. > > > (3) Why does mingw break the paradigms set up by every other gcc > > > target? Other targets may need the full triplet; `linux' on its own would be horrendously ambiguous, because it supports so many *different* CPU architectures. Some CPU types exhibit different characteristics, when sourced from different vendors. For tools targetting such platforms, the additional information is necessary to avoid ambiguity. mingw32 and mingw64 are completely unambiguous, so there is no need for the redundancy in specifying the tool chain prefix. > The paradigm is that target-specific binaries and libraries should in > in subdirectories of the target triplet directory. So for instance, > i386-pc-mingw32/bin holds gcc.exe, whereas /bin holds > i386-pc-mingw32-gcc.exe, The same holds identically true for ${prefix}/bin/mingw32-gcc.exe and ${prefix}/mingw32/bin/gcc.exe; the additional i386-pc- prefix is redundant and unnecessary. > or the default gcc.exe for the system (that > is, if you are building for i386 instead of some other target, like > i686). There is no point in discriminating between i386-mingw32 and i686-mingw32; these would be the same tool chain. > This makes it easy to have multiply-targetted compilers > installed in the same root structure. And it is equally straightforward with the abbreviated prefix; the only requirement is that the individual tool chains have *unique* prefixes; they do *not* need to be named with the full canonical triplet. Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-04-21 20:46:21
|
On Wednesday 26 March 2008 20:49, Keith Marshall wrote: > So, to return to your question, what on earth could mingw64 possibly > mean, if not MinGW for a 64-bit platform. The canonical form of a > host triplet is CPU-VENDOR-OSTYPE. If the OSTYPE is mingw32, that is > unambiguously MinGW for any one of the i[34567]86 processor family, Actually, this isn't strictly true; mingw32 is unambiguously MinGW for Microsoft's Win32 /operating/ /system/, *irrespective* of whichever processor it may be running on; just as Win16 ran for years on 32-bit processors, (did anyone /ever/ run it /usefully/ with a 16-bit CPU?), Win32 can run on 64-bit processors. > so the CPU and VENDOR fields are completely redundant; indeed, what > VENDOR does `pc' signify anyway? IBM? Sun? Fred Bloggs? It is > completely meaningless, and might as well be discarded; the equally > acceptable i386-unknown-mingw32 is preferable, IMO. > > Right. VENDOR is redundant. It conveys no useful information, when > the only platform targetted by the OSTYPE is singularly identified, > as it is in the case of OSTYPE == mingw32, (which targets i[34567]86 > generic family processors *exclusively*). By the same token, CPU is > redundant too, because it is unambiguously identified when OSTYPE == > mingw32, just as OSTYPE == mingw64 would be singularly unambiguous; > in either case config.sub can unambiguously canonicalise the target, > *solely* on either one of these OSTYPEs: > > OSTYPE == mingw32 ==> i386-unknown-mingw32 Here, since it is possible to run Win32 on 64-bit processors, there could be a case for the canonical form `x86_64-unknown-mingw32', but does it convey anything /useful/ (to the tool chain), that isn't already implicit in the non-canonical form, `mingw32'? > OSTYPE == mingw64 ==> x86_64-unknown-mingw64 And here, this remains unambiguous only until Intel/AMD introduce the x86_128 architecture, and Microsoft aren't ready with Win128; then we will no doubt see Win64 running on x86_128. But, I continue to stand by this... > so why burden us with redundant information? We may just as well > dispense with the CPU and VENDOR fields, and still have the > appropriate tool chain unambiguously specified by just the OSTYPE > name. ...since `mingw32' and `mingw64' actually have more to do with the OS association, (Win32 vs. Win64), than any particular processor affinity. Regards, Keith. |
From: Charles W. <cwi...@us...> - 2008-04-22 02:06:38
|
Keith Marshall wrote: > But, I continue to stand by this... > >> so why burden us with redundant information? We may just as well >> dispense with the CPU and VENDOR fields, and still have the >> appropriate tool chain unambiguously specified by just the OSTYPE >> name. > > ...since `mingw32' and `mingw64' actually have more to do with the OS > association, (Win32 vs. Win64), than any particular processor affinity. I could see the CPU field indicating the default instruction set used by the compiler -- that is, the default -march (-mcpu on gcc-3.x) setting. Unless that is going to remain i386 from here to eternity. (err. oops: *ALL* of the msys-build-<PKG> scripts I have been using for the MSYS-1.0.11 packages include this: opt_flags="-fnative-struct -O3 -s -mcpu=pentium" (native-struct and not ms-bitfields because the compiler is gcc-2.95.3, but the important bit for this discussion is -mcpu...) And if you keep the CPU...well, -unknown-/-pc- provides no information, but keeping the config triple a *triple* is worth something. maybe. if only just for consistency with all the other platforms that canonicalize to an actual 3-element "triple". There's one other wrinkle that I'm not sure has been mentioned: Danny had been using a -dw2 suffix to indicate the *compiler's* -- not necessarily the *platform* exception handling mode. I don't know if the current plans for gcc-4.x will continue to include separate releases of gcc for both dwarf2 and sjlj. But if so, then this discussion should also include: foo-dw2 and foo-sjlj or foo-dw2 and foo (implicit sjlj) or foo (implicit dw2) and foo-sjlj or just "foo" and buyer beware. -- Chuck |
From: Aaron W. L. <aar...@aa...> - 2008-04-22 04:44:05
|
Charles Wilson wrote: > I don't know if the > current plans for gcc-4.x will continue to include separate releases of > gcc for both dwarf2 and sjlj. But if so, then this discussion should > also include: > > foo-dw2 and foo-sjlj This is too much insanity. I've proposed here <http://sourceforge.net/mailarchive/message.php?msg_name=47F6B2DE.5080709%40aaronwl.com> only supporting Dwarf exceptions GCC4 and forward. I do not plan to produce GCC4 binaries that support SJLJ exceptions unless someone produces a compelling argument. |
From: Dave K. <dav...@ar...> - 2008-04-23 21:12:29
|
Aaron W. LaFramboise wrote on : > Charles Wilson wrote: > >> I don't know if the >> current plans for gcc-4.x will continue to include separate releases of >> gcc for both dwarf2 and sjlj. But if so, then this discussion should >> also include: >> >> foo-dw2 and foo-sjlj > > This is too much insanity. I've proposed here > <http://sourceforge.net/mailarchive/message.php?msg_name=47F6B > 2DE.5080709%40aaronwl.com> only supporting Dwarf exceptions GCC4 and > forward. I do not plan to produce GCC4 binaries that support SJLJ > exceptions unless someone produces a compelling argument. I propose precisely the same thing for GCC4 on Cygwin, and am working on patches to that effect. I see you got accepted on GSoC! Congratulations, and if there's anything I can do to help out, feel free to ask anytime; I'd be glad to contribute some of my spare time, because I share the goals of your project. cheers, DaveK -- Can't think of a witty .sigline today.... |
From: Earnie B. <ea...@us...> - 2008-04-22 11:56:34
|
Quoting Charles Wilson <cwi...@us...>: > > Unless that is going to remain i386 from here to eternity. (err. oops: > *ALL* of the msys-build-<PKG> scripts I have been using for the > MSYS-1.0.11 packages include this: > > opt_flags="-fnative-struct -O3 -s -mcpu=pentium" > (native-struct and not ms-bitfields because the compiler is gcc-2.95.3, > but the important bit for this discussion is -mcpu...) > -mcpu=pentium instructs the compiler to build the executable so that it uses pentium instruction if pentium instruction is available. Defaulting to an march=i586 may be desirable at this date since I doubt that anyone is using i386 or i486 and if they are they can use the older builds. However it still isn't necessary to confuse most users and indicate the CPU within the filename structure. Lets leave target=mingw32 or target=mingw64 as the indicators for which platform; Keith has already expounded more verbosely than I ever could on the subject as to why. > > And if you keep the CPU...well, -unknown-/-pc- provides no information, > but keeping the config triple a *triple* is worth something. maybe. if > only just for consistency with all the other platforms that canonicalize > to an actual 3-element "triple". > Not for OUR distributed binaries. If someone who is so technologically inclined wants it, they should be able to build it with the appropriate triplets. It's insane to confuse users with this nonsense. It's nonsense because it doesn't really give any definition to the distributed binary; but does give possible confusion. Earnie |
From: Keith M. <kei...@us...> - 2008-03-27 20:00:14
|
On Wednesday 26 March 2008 15:17, Chris Sutcliffe wrote: > I've uploaded the tarball again, for some reason the original archive > had 0 byte binaries in the mingw32/bin directory: I didn't notice this, when I checked out your original archive. I'd downloaded it, and installed it into a sandboxed clone of my regular MinGW installation, and everything worked perfectly. Inspection of the original archive with `tar ztvf ...' reveals the explanation: the executables in mingw32 are indeed shown as zero size, but they are also recorded as links to their counterparts in bin, which are the actual executable images in the tarball, and so non-zero size. When this archive is unpacked with MSYS tar, on NTFS the links are re-established, (`ls -l' shows link counts of two), and it all `Just Works(TM)'. On FAT32, where file-to-file hard links are not supported, MSYS tar will still DTRT, and resolve those links by creating copies of the respective files, so again, everything will `Just Work(TM)'. So, all well and good for you and me; we will use MSYS tar to install MinGW packages, but Joe User is just as likely to use WinZip, or 7-Zip, or some other archiving tool of his choice. I just checked it with WinZip-9.0, and that doesn't recognise that the 'mingw32/bin' even exists in the archive! Thus, it simply isn't acceptable for us to distribute archives which rely on the archiving tool to to reinstate file-to-file links, which have been recorded on archive creation, if we wish to support users of such naive Win32 archiving tools, rather than require every user to adopt MSYS. In my sample build procedure, I suggested using: $ tar czhf $RELEASE_DIR/binutils-2.18.50-20071123-bin.tar.gz * as the command to create the binary release tarball, (obviously with the version number and snapshot serialisation adjusted as appropriate). Do please note the `h' flag, amongst the `czhf'; it is this which ensures that all necessary files are *copied* to the archive, rather than linked, as they would be if this flag is omitted. To ensure integrity of our release tarballs, I would suggest that this `h' flag should be mandatory, when creating the archives. The above sample command also raises two other potential discussion points: first note that I've used `z' --> `.tar.gz' as the compression standard, and second that I've included a `-bin' qualifier for the archive name. Some might argue for `j' --> `.tar.bz2' for the compression standard, since it generally, (but not always), results in smaller archives, and we've certainly used that for some of our releases, particularly for the MSYS packages. While it may be fair to assume that MSYS users will install MSYS packages using MSYS' own tar command, so they can readily handle this format, I don't think it should be adopted for the more general case of MinGW packages. Yes, I know there are better archive tools for Win32 than WinZip, but AFAIK it is still widely used, and it does not support bzipped archives, but it does support `.tar.gz'. If we adopt `.tar.bz2' format, then we will alienate potential users who do not wish to use MSYS, and who do want to use WinZip; not good. On the subject of the `-bin' qualifier, my mind is less firmly made up. In the past, we have more often released binary packages without such a qualifier, than we have with, although there are examples to be found. My own opinion leans toward including it, at least for future binary releases in `.tar.gz', (or in `.tar.bz2'), or in `.zip' format, as it does help to emphasise that the package is indeed a binary release; OTOH, for those packages released in self extracting `.exe' format, I suspect that such a qualifier would be redundant, (unless we were to start releasing source archives in such format, which I do not think we should ever do). However, this is a level of detail, on which I will willingly accede to majority preference. Any comments? Regards, Keith. |
From: Aaron W. L. <aar...@aa...> - 2008-03-27 21:13:46
|
I'm about to upload some GCC 'tech previews' within the next few days so this discussion is timely. See below. Keith Marshall wrote: > In my sample build procedure, I suggested using: Where is this 'sample build procedure'? > To ensure integrity > of our release tarballs, I would suggest that this `h' flag should be > mandatory, when creating the archives. I agree. I think it is premature to use links in MinGW packages, as as the benefit is minimal, archiver support is poor, hard links are surprising to many Windows uses (and many Windows programs), and most installations still do not support file soft links. > The above sample command also raises two other potential discussion > points: first note that I've used `z' --> `.tar.gz' as the compression > standard I agree. .tar.gz is a file format that has substantial support and all of the capabilities that MinGW needs. Chasing the latest compression fad, whether its bzip2, lzma, rzip, or 7zip is probably not productive when the marginal gains do not offset the increased difficulty of decompression. Universality is the primary goal; compression ratio is secondary. > and second that I've included a `-bin' qualifier for the > archive name. So source releases will still have -src? If so, -bin may not add anything. I don't care either way, but the more qualifiers that are added, the more difficult it may be for users to figure out which packages they need. |
From: Keith M. <kei...@us...> - 2008-03-27 21:56:48
|
On Thursday 27 March 2008 21:13, Aaron W. LaFramboise wrote: > > In my sample build procedure, I suggested using: > > Where is this 'sample build procedure'? It is in the reference I provided earlier in the thread -- it was specific to binutils, and framed for cross compiling: http://article.gmane.org/gmane.comp.gnu.mingw.devel/2678 so would need adaptation for self hosted builds, and for GCC, etc. I offered it primarily as a basis for further discussion. > > and second that I've included a `-bin' qualifier for the > > archive name. > > So source releases will still have -src? Yes. > If so, -bin may not add anything. It may not add anything, but IMO it removes potential ambiguity. It is easier to direct someone to look for a `-bin' package, than to look for one with no qualifier, when they want a binary package. > I don't care either way, I don't feel strongly enough about it to insist upon it, but I thought it worthy of consideration. > but the more qualifiers that are added, the > more difficult it may be for users to figure out which packages they > need. We should specify a minimal, well defined set. I suggest: -src source package, as at present. -bin binary package, i.e. pre-built executable programs, and any supporting DLLs they may require; this should, in general, be a fully self-contained package. -dev (or maybe -devel), a package providing precompiled static libraries, import libraries and associated header files, for optional extra feature support, (i.e. additional to the standard system libs and headers, which would remain integral to the GCC and binutils `-bin' packages). -dll stand alone DLLs associated with `-dev' packages, when there is no `-bin' package with which these would be logically associated. Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2008-03-28 00:16:01
|
Hey Keith, > So, all well and good for you and me; we will use MSYS tar to install > MinGW packages, but Joe User is just as likely to use WinZip, or 7-Zip, > or some other archiving tool of his choice. I just checked it with > WinZip-9.0, and that doesn't recognise that the 'mingw32/bin' even > exists in the archive! Thus, it simply isn't acceptable for us to > distribute archives which rely on the archiving tool to to reinstate > file-to-file links, which have been recorded on archive creation, if we > wish to support users of such naive Win32 archiving tools, rather than > require every user to adopt MSYS. FWIW, 7-zip doesn't resolve the links either, so they are 0 size files when extracted. > In my sample build procedure, I suggested using: > > $ tar czhf $RELEASE_DIR/binutils-2.18.50-20071123-bin.tar.gz * > > as the command to create the binary release tarball, (obviously with the > version number and snapshot serialisation adjusted as appropriate). Do > please note the `h' flag, amongst the `czhf'; it is this which ensures > that all necessary files are *copied* to the archive, rather than > linked, as they would be if this flag is omitted. To ensure integrity > of our release tarballs, I would suggest that this `h' flag should be > mandatory, when creating the archives. I tried this (using the 'h' option), unfortunately it didn't help. Is this a possible issue with MSYS tar? Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Earnie B. <ea...@us...> - 2008-03-28 12:55:54
|
Quoting Keith Marshall <kei...@us...>: > > Some might argue for `j' --> `.tar.bz2' for the compression standard, > since it generally, (but not always), results in smaller archives, and > we've certainly used that for some of our releases, particularly for > the MSYS packages. While it may be fair to assume that MSYS users will > install MSYS packages using MSYS' own tar command, so they can readily > handle this format, I don't think it should be adopted for the more > general case of MinGW packages. Yes, I know there are better archive > tools for Win32 than WinZip, but AFAIK it is still widely used, and it > does not support bzipped archives, but it does support `.tar.gz'. If > we adopt `.tar.bz2' format, then we will alienate potential users who > do not wish to use MSYS, and who do want to use WinZip; not good. > I prefer bz2. The installer handles it and we can provide a mingw-tar and mingw-bzip2 for the extraction via the command line. If someone is so inclined we could even offer a GUI version. Earnie |
From: Keith M. <kei...@us...> - 2008-04-21 20:46:30
|
On Friday 28 March 2008 12:55, Earnie Boyd wrote: > > Some might argue for `j' --> `.tar.bz2' for the compression > > standard, since it generally, (but not always), results in smaller > > archives, and we've certainly used that for some of our releases, > > particularly for the MSYS packages. While it may be fair to assume > > that MSYS users will install MSYS packages using MSYS' own tar > > command, so they can readily handle this format, I don't think it > > should be adopted for the more general case of MinGW packages. > > Yes, I know there are better archive tools for Win32 than WinZip, > > but AFAIK it is still widely used, and it does not support bzipped > > archives, but it does support `.tar.gz'. If we adopt `.tar.bz2' > > format, then we will alienate potential users who do not wish to > > use MSYS, and who do want to use WinZip; not good. > > I prefer bz2. The installer handles it ... With respect, I'm not exactly enthralled by the present installer ... > ... we can provide a mingw-tar and mingw-bzip2 for the extraction via > the command line. Perhaps, although I'm sure we'd still get complaints from users who seem to have a pathological dislike for the command line. A bigger issue, than the choice of compression format, is the use of file link references within the archive. If we accept that we will use these, (and tar does so by default), then we really do preclude the more common Windows archiving tools, so we need to publicise that limitation more forcibly. We also need to ensure that any mingw-tar which we provide handles such links, just as its MSYS counterpart does. > If someone is so inclined we could even offer a GUI version. Indeed, I think we would probably need to do so. FWIW, I've recently been playing with wxWidgets. As an evaluation project, I chose something I'd originally thought about as a scripted addition to the portmaker codebase -- a dependency tracking extension for mingwPORTs. So, I set out to create a toy package management tool, but the awesome capabilities of wxWidgets are leading me to the conclusion that what I've developed could very easily become much more than the toy I had originally intended -- possibly a basis for a future MinGW package management tool. Alternatively, we could consider adapting the current Cygwin setup tool to our needs. Whatever we ultimately decide, I think we need something which is: 1) Much more flexible than the current installer, in terms of the installation choices offered to the user, while still maintaining an automatic basic install selection, as default for newcomers. 2) Able to support installation of *all* packages which are available for download from the SF project page, as optional extensions to the base system installation; (both MinGW and MSYS). 3) Able to track, and resolve, dependencies between packages, to ensure that all prerequisites are automatically satisfied, particularly for optionally installed packages. Regards, Keith. |
From: Gianluca S. <gi...@gm...> - 2008-04-21 22:00:16
|
On Mon, Apr 21, 2008 at 4:17 PM, Keith Marshall <kei...@us...> wrote: > > Whatever we ultimately decide, I think we need something which is: > > 1) Much more flexible than the current installer, in terms of the > installation choices offered to the user, while still maintaining an > automatic basic install selection, as default for newcomers. > > 2) Able to support installation of *all* packages which are available > for download from the SF project page, as optional extensions to the > base system installation; (both MinGW and MSYS). > > 3) Able to track, and resolve, dependencies between packages, to ensure > that all prerequisites are automatically satisfied, particularly for > optionally installed packages. > Maybe also: 4) able to query the SF page for availability of updated packages ? |