I am a little surprised that you got this to work simply by passing
--prefix=/opt/mingw64/... and a few other flags. Last time I looked
closely, cygport assumed /usr in quite a few places. Maybe that's
changed; if so, cool!
On 7/2/2010 1:29 AM, JonY wrote:
> mingw64-tc64-headers:
...
> category: Devel
> requires: mingw64-tc64-gcc4
> sdesc: "Headers for Windows target."
> ldesc: "Mingw-w64 headers for Windows target development."
Rebuilds cleanly from source. Packaging looks ok (assuming current
status of naming discussion represents the ultimate consensus view).
I think you should included your "branding" in the sdesc:
"Mingw-w64 headers for Windows target development."
or something. Also, I think you should specify in the ldesc that this
package is for both -m32 and -m64, AND that it's for the
default-to-64bit toolchain.
"Mingw-w64 headers for Windows target development, for use with
the Mingw-w64 toolchain that defaults to 64bit output. However, this
package supports that toolchain in both 64bit (-m64) and 32bit (-m32)
mode."
Finally, I don't think this package actually *requires* the compiler,
does it? It may not be of any USE without the compiler, but I could
install it just to look at the files, right?
> mingw64-tc64-binutils:
>
> category: Devel
> requires: libgcc1 zlib0 libintl8
> sdesc: "Binutils for Windows target."
> ldesc: "Cross binutils for Win64 and Win32 target.(Mulilib, 64bit default)"
Packaging looks ok (assuming current status of naming discussion
represents the ultimate consensus view).
Rebuilds (almost) fine from source. There is a warning during packaging:
>>> Checking packages for missing or duplicate files
*** Warning: Packages are missing files:
-opt/mingw64/lib/libiberty.a
Now, I know you don't WANT to include libiberty.a in the package, so to
suppress the warning just override src_install():
src_install() {
cd ${B}
cyginstall
rm -f ${D}/opt/mingw64/lib/libiberty.a
}
Again, I'd include the mingw64 branding in sdesc (actually, your
original ldesc is a better sdesc...):
"Mingw-w64 cross binutils for windows target (multilib, 64bit default)"
And with ldesc:
"Mingw-w64 cross binutils for Win64 and Win32 target. This is part
of a multilib toolchain that defaults to 64bit output, but supports both
64bit (-m64) and 32bit (-m32) mode."
Oddly, my build doesn't appear to depend on zlib0; libgcc1 and libintl8
(and cygwin, of course, but that is never included in requires:).
> mingw64-tc64-m32-crt:
> mingw64-tc64-crt:
> mingw64-tc64-m64-crt:
I assume I need the mingw64-tc64-gcc to (re)build these, so I'll have to
verify that later (and comment on the setup.hints)
Packaging looks ok (assuming current status of naming discussion
represents the ultimate consensus view).
One oddity: the -m64 package contains 2112 files, but the -m32 package
contains only 227 files. Is that expected? I would have thought that
the same libraries would be available in both lib/* and lib32/*
> mingw64-tc64-libpthread2
> mingw64-tc64-libpthread2-headers
> mingw64-m64-libpthread2
> mingw64-m32-libpthread2
Again, I assume I need the mingw64-tc64-gcc to (re)build these, so I'll
have to verify that later (and comment on the setup.hints)
The packaging needs a few more tweaks. Usually, we only include the
'dll version' in the package name of the packages that actually contain
the DLLs themselves:
mingw64-m64-libpthread2
mingw64-m32-libpthread2
The "docs" and "headers" are not really versioned -- it's not as if you
could have two distinct versions installed (for the same bitdepth and
toolchain) at the same time. (it's "pthread.h" not "pthread2.h")
So, I'd name these packages like so:
mingw64-m32-libpthread2-20100619-1.tar.bz2
mingw64-m64-libpthread2-20100619-1.tar.bz2
mingw64-tc64-libpthread-20100619-1.tar.bz2
mingw64-tc64-libpthread-20100619-1-src.tar.bz2
mingw64-tc64-libpthread-headers-20100619-1.tar.bz2
--
Chuck
