From: Thomas T. <tho...@ya...> - 2006-11-06 17:00:19
|
> Date: Mon, 06 Nov 2006 08:23:13 -0500=0A> From: Earnie Boyd <earnie@users= .sourceforge.net>=0A> Subject: Re: [Mingw-users] Scott Meyers on building g= cc 4.1 on minGW=0A> and msys=0A> To: min...@li...=0A>= Message-ID: <200...@ma...>=0A> Content-T= ype: text/plain; charset=3DISO-8859-1; format=3D"flowed"=0A=0A> Quoti= ng Thomas Tutone <tho...@ya...>:=0A=0A>> Scott Meyers has posted= an article on his website on how to build gcc =0A>> 4.1 using minGW and ms= ys. The article just annotates (slightly) a =0A>> posting from the gcc-hel= p mail list on how to do this.=0A>>=0A>> Scott Meyers' article:=0A>>=0A>> h= ttp://www.aristeia.com/Misc/gcc4ForWindows_frames.html=0A>>=0A>> The origin= al posting from the gcc-help mail list:=0A>>=0A>> http://gcc.gnu.org/ml/gcc= -help/2006-09/msg00000.html=0A>>=0A=0A> Can we add this information to the = MinGWiki? I prefer the content be =0A> ported to the wiki rather than link= s to the information. Thomas can =0A> you please ask Scott for permission = to do so and then would you be =0A> willing to add a page to the wiki?=0A= =0ASure. BTW, I tried it out over the weekend, and was able to build gcc 4= .1.1 from source without much trouble. I did have trouble building binutil= s from source using the same instructions. =0A=0ABest regards,=0A=0ATom=0A= =0A |
From: Danny S. <dan...@cl...> - 2006-11-07 18:08:46
|
> /bin/sh ../../binutils/../ylwrap ../../binutils/arparse.y y.tab.c > arparse.c y.tab.h arparse.h y.output arparse.output -- > /home/keith/tmp/mingw-3.4.5/binutils-2.17.50-20060716-1-src/missing > bison -y -d > WARNING: `bison' missing on your system. You should only need it if > you modified a `.y' file. You may need the `Bison' package > in order for those modifications to take effect. You can get > `Bison' from any GNU archive site. > . > . > /bin/sh ../../binutils/../ylwrap > ../../binutils/arlex.l lex.yy.c arlex.c -- > /home/keith/tmp/mingw-3.4.5/binutils-2.17.50-20060716-1-src/missing > flex > WARNING: `flex' is missing on your system. You should only need it if > you modified a `.l' file. You may need the `Flex' package > in order for those modifications to take effect. You can get > `Flex' from any GNU archive site. > > And yes, I consider this a bug in `binutils'; users downloading and > building from an unmodified release tarball should NOT need to have > either of these tools installed. I'll file a bug report, when I > can find the time. It would be a binutils bug if this were an official release. Actually binutils-2.17.50-20060716-1-src it is just a CVS sanpshot. If anything it is my bug, since I just gzipped up the CVS srcs. Danny |
From: Keith M. <kei...@us...> - 2006-11-07 19:44:34
|
On Tuesday 07 November 2006 6:08 pm, Danny Smith wrote: > > WARNING: `flex' is missing on your system. You should only need it > > if you modified a `.l' file. You may need the `Flex' package in > > order for those modifications to take effect. You can get `Flex' > > from any GNU archive site. > > > > And yes, I consider this a bug in `binutils'; users downloading and > > building from an unmodified release tarball should NOT need to have > > either of these tools installed. I'll file a bug report, when I > > can find the time. > > It would be a binutils bug if this were an official release. Actually > binutils-2.17.50-20060716-1-src it is just a CVS sanpshot. > > If anything it is my bug, since I just gzipped up the CVS srcs. Thanks for clarifying this, Danny. Can you please cut a proper `dist' release, for the `Current' package set? CVS snapshots don't really belong there; that's why we have the the `Snapshot' package set. FWIW, I've put together a new cross-compiler build script package; most of it's already in the CVS on SourceForge: http://mingw.cvs.sourceforge.net/mingw/xscripts/ This extends Michael's existing script, adding interactive operation, and automatic download of source packages from our own SF file release mirrors; it would really be better if those packages it's configured to download are full releases, not merely CVS snapshots. I hope to cut a pre-release snapshot of this, maybe tonight, probably tomorrow, which I will add to the `Snapshot' package set; any comments will be appreciated. Regards, Keith. |
From: Danny S. <dan...@cl...> - 2006-11-07 20:27:37
|
> > It would be a binutils bug if this were an official=20 > release. =A0Actually > > binutils-2.17.50-20060716-1-src =A0it is just a CVS sanpshot. > > > > If anything it is my bug, since I just gzipped up the CVS srcs. >=20 > Thanks for clarifying this, Danny. Can you please cut a=20 > proper `dist'=20 > release, for the `Current' package set? CVS snapshots don't really=20 > belong there; that's why we have the the `Snapshot' package set. =20 Historically (since 1999), for both cygwin and mingw, binutils distro have been based on CVS snapshots, rather than official binutils releases. Releases used to be more sporadic than they are now and CVS HEAD was sooo much better than the latest release with respect to PE-COFF specific bug-fixes and enhancements that nobody careed much about the official release. That's changed somewhat, but still I would not want to use official binutils 2.17 . For one thing the speed improvements since the release are very impressive. For another, I can now biuld things for ARM-WINCE. >From now on I'll upload binutils distros updates to to "Snapshots", if that's what you want, but roll the source release with whatever the --regenerate-files-in-source-dir configure switch is. When 2.18 come out I'll put it in current. Hopefully enough people use the Snapshots package so that 2.18 gets good mingw32 testing. =20 |
From: Keith M. <kei...@to...> - 2006-11-07 09:45:53
|
Thomas Tutone wrote: > I did have trouble building binutils from source using the > same instructions. Do you have `flex' and `bison' installed, and in your PATH? Although `configure' throws out only these WARNINGS: /bin/sh ../../binutils/../ylwrap ../../binutils/arparse.y y.tab.c arparse.c y.tab.h arparse.h y.output arparse.output -- /home/keith/tmp/mingw-3.4.5/binutils-2.17.50-20060716-1-src/missing bison -y -d WARNING: `bison' missing on your system. You should only need it if you modified a `.y' file. You may need the `Bison' package in order for those modifications to take effect. You can get `Bison' from any GNU archive site. . . /bin/sh ../../binutils/../ylwrap ../../binutils/arlex.l lex.yy.c arlex.c -- /home/keith/tmp/mingw-3.4.5/binutils-2.17.50-20060716-1-src/missing flex WARNING: `flex' is missing on your system. You should only need it if you modified a `.l' file. You may need the `Flex' package in order for those modifications to take effect. You can get `Flex' from any GNU archive site. I've found that they are nothing of the sort! These come from a cross build of `binutils' on my Linux box, but I'd imagine the results would be similar building under MSYS. Even though I did NOT modify ANY `.y' or `.l' file, the build crapped out with an "unresolved reference to `yyparse'" error message. Installing `bison' got past this, only to replace it with an unresolved `yylex'; installing `flex' as well was the solution, which allowed me to complete a successful `binutils' build. And yes, I consider this a bug in `binutils'; users downloading and building from an unmodified release tarball should NOT need to have either of these tools installed. I'll file a bug report, when I can find the time. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-11-07 12:27:49
|
Quoting Keith MARSHALL <kei...@to...>: > > And yes, I consider this a bug in `binutils'; users downloading and > building from an unmodified release tarball should NOT need to have > either of these tools installed. I'll file a bug report, when I > can find the time. > Actually this has to do with the timestamps of the generated files compared to the timestamps of the source file that creates the destination. I usually will touch the generated file names in the src distribution to ensure that I don't regenerate these files. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Easy Blogger Creator: <a href="http://give-me-an-offer.com/1006/">Offer 1006</a> 4 Seasons Wine - Buy 6, Get 6 Free <a href="http://give-me-an-offer.com/1007/">Offer 1007</a> |
From: Keith M. <kei...@to...> - 2006-11-07 13:28:05
|
Earnie Boyd wrote, quoting me: >> And yes, I consider this a bug in `binutils'; users downloading and >> building from an unmodified release tarball should NOT need to have >> either of these tools installed. I'll file a bug report, when I >> can find the time. > > Actually this has to do with the timestamps of the generated files > compared to the timestamps of the source file that creates the > destination. I did wonder if this might be the problem, but I haven't had time to verify it. > I usually will touch the generated file names in the src distribution > to ensure that I don't regenerate these files. It's still a bug, IMO; a properly constructed tarball should have the timestamps appropriately recorded, in the first place. On extraction, `tar' preserves the original (modification) timestamps for the files, as at the time of packaging, *not* time of extraction, so the end user *shouldn't* have this responsibility. Regards, Keith. |
From: Keith M. <kei...@to...> - 2006-11-07 15:56:31
|
Following up on my own earlier posting: > Earnie Boyd wrote, quoting me: >>> And yes, I consider this a bug in `binutils'; users downloading and >>> building from an unmodified release tarball should NOT need to have >>> either of these tools installed. I'll file a bug report, when I >>> can find the time. >> >> Actually this has to do with the timestamps of the generated files >> compared to the timestamps of the source file that creates the >> destination. > > I did wonder if this might be the problem, but I haven't had time to > verify it. Actually, this *isn't* the problem on this occasion. I've now had a very quick preliminary look into it. When I remove both `flex' and `bison', the build blows up when trying to create `arparse.o'; this should be built from a generated `arparse.c', which IMO *should* be in the release tarball, but it isn't; there is only `arparse.y'. So, the release tarball is incomplete; so much for bulletproof Makefiles, when `automake' is used to generate them -- making the `dist' target should have been sufficient to ensure that these dependencies on `flex' and `bison' were removed, as required by GNU Coding Standards; this is clearly broken, for our `binutils' distribution. Regards, Keith. |