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: