[ITP] mingw-w64

JonY jon_y@users.sourceforge.net
Sat Jul 3 17:42:00 GMT 2010


On 7/3/2010 11:27, Charles Wilson wrote:
> 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!
>

There were others like docdir and datadir, but its easy to see from the 
configure command line what needs to be overridden :). Ideally cygport 
should be able to understand when to give up some control.

> 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."
>

OK, I'll make it more verbose.

> 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?
>

OK, I'll put the headers into the compiler require. Yeah, I thought that 
the headers themselves weren't very useful.

>> 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
> }
>

Thanks for the tip.

> 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:).
>

It doesn't? I thought I saw -lz linked in for some executables. OK, will 
remove zlib0, libintl8 and libgcc.

>
>> 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/*
>

Yeah, thats expected. the 32bit import libraries were mostly copied from 
mingw.org when the project started. Emphasis was on getting 64bit 
working with the import libs generated en mass from whatever XP 64bit 
has in system32. The 32bits defs weren't as updated, but we're still 
working on it.

>> 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
>

OK, I'll try to fix this.



More information about the Cygwin-apps mailing list