[ITP] mingw-w64 Second try
Fri Sep 10 10:00:00 GMT 2010
On 9/10/2010 07:09, Charles Wilson wrote:
> On 9/9/2010 6:10 AM, JonY wrote:
> OK, we're allllmost there.
> binutils and runtime are GTG.
> gcc, headers, and pthreads are really close.
> Everything rebuilds from source fine, and the uploaded packages actually
> match the rebuilt versions (or vice versa). So that's all good. Plus, I
> was able to build a sample project using these tools
> (mingw64-x86_86-xz-4.999.9beta-1) with no problems.
> However, when I tried to install these packages via setup.exe, I ran
> into problems with the setup.hints. In the first case, "genini" (*) did
> not like some of them -- complained about missing fields -- AND, genini
> couldn't actually parse the package name of mingw64-x86_64-headers.
> (*) genini is a user script that can be used to generate a "setup.ini"
> for a cygwin package repository. On the sourceware server, a different
> tool -- "upset" -- is used.
> Now, maybe -- MAYBE -- upset is smarter than genini, and won't complain.
> However, it's usually better to make sure that genini is happy; then you
> are much more likely to NOT cause the upset script on sourceware to send
> cgf a bunch of nasty warnings via email. That makes cgf angry. You
> wouldn't like cgf when he's angry.
> Here are the "bad" setup.hints:
> Plus there are bigger changes required to the -headers package. We'll
> talk about that last.
> In each of the following cases, the setup.hint was missing an "ldesc:"
> field. This annoys genini, but upset might be ok with it.
> The "top" gcc setup.hint was missing both an "ldesc:" and a "requires:"
> field (requires was empty, of course).
> I've attached the updated setup.hints.
> Here's what I would suggest we do, for gcc: DON'T bother to rebuild it.
> Just save these setup.hints, and make sure to fold them in to your NEXT
> official release's CYGWIN-PATCHES/ directory. When I upload this first
> version of mingw64-gcc, I'll be sure to use these new hints instead of
> the ones you pasted inline. Let's call gcc "GTG with alternate hint files".
> For pthreads, I'd suggest you actually rebuild and re-upload it with the
> attached hint (it doesn't take nearly as long...) but if you want to
> treat it just like gcc, above, that's fine. Let me know -- we'll call
> pthreads "GTG with alternate hint files, or as rebuilt".
> Here's the problem: genini requires that the "version" part of the
> package name begin with a numeral. I think this is true of upset as
> well, but I'm not sure (but again, better safe than sorry. You wouldn't
> like cgf when he's angry). Also, genini and cygport do NOT like having
> a hyphen in the version number (but upset is ok with it).
> So, just liike your earlier gendef and libmangle packages -- where we
> discovered that they had to be named, e.g.
> ...the current name of the headers package is no good:
> must start with numeral
> Now, following the gendef/libmangle pattern, I tried
> where 1.0b came from the configure.ac file, but I discovered that genini
> doesn't like the hyphen between 1.0b and svn3433 -- when you do that,
> genini (and cygport-0.10.0, for that matter) thinks the package name is
> "mingw64-x86_64-headers-1.0b", and the version is "svn3433", and we're
> right back where we started! Now, upset doesn't care about this --
> obviously -- since gendef and libmangle, which use '-' between 1.0 and
> svnXXXX -- have not yet caused cgf to become angry.
> But...let's also try to keep genini happy. And, it may be a regression
> in cygport -- I'm not sure (obv. you were able to build gendef and
> libmangle with an older version of cygport, even with a hyphen in the
> middle of the version string), but we have to keep cygport happy, too.
> So, I rebuilt as:
OK, this is fine.
> And that worked fine (genini was happy, cygport was happy, setup.exe was
> happy -- and presumably upset will be happy == no angry cgf). I've
> uploaded the modified version here:
> so you can download it and pick it apart. The only thing that's
> different is (a) the package name, (b) the name of the "checked out"
> source tarball is mingw64-x86_64-headers-1.0b_svn3433.tar.bz2, but
> 'cygport ... get' does that automatically, and (c) the setup.hint and
> README were both updated to reflect the new name and genini issues.
> So, let me know how you want to handle gcc, pthreads, and headers, and
> we'll go from there.
OK, I'll repackage gcc and pthreads with cygport, setup.hint shouldn't
affect the binaries as it is cygwin metadata.
I'll also rename the headers version to 1.0b_svnXXXX.
Thanks for your help.
More information about the Cygwin-apps