[ITP] mingw-w64

[Charles Wilson]

On 6/30/2010 1:51 PM, JonY wrote:
> On 7/1/2010 00:36, Charles Wilson wrote:
>> I don't know much about sf's buildbot; I assume that if you can get a
>> cygport to DTRT on your home PC without human intervention except for
>> kicking off the build, then you can convince the buildbot to do it for
>> you?
>>
>
> Right now, human intervention still needed. cygport messes up the target
> dll locations by moving them around and trying to fix libtool files. Its
> also using cygwin strip(1) to strip 64bit dlls, it fails but doesn't
> lead to the cygport halting.

I think you can set a variable in your cygport to suppress both of these 
actions -- and then use the "correct" tool manually in src_install(). 
I'll check later.

>> So, we need a naming scheme that accounts for:
>> 1) origin
>> 2) default bit depth of the tool chain
>> 3) bit depth of the target
...
>> In fact, for complete clarity, I think I'd use:
>> -tc64- or -tc32- == toolchain default bitdepth 64 or 32
>> -m64- or -m32- == bit depth 64 or 32(use "m" as a mnemonic
>> for which "-mNN" option it corresponds to)
...
>> If something is common to BOTH, then just drop that element. E.g. both
>> the -m32 and -m64 mingw headers are provided by the same package, so
>> that package would have only "mingw64-tc64-". OTOH, if you split the
>> mingw import libs for the defaults-to-64bit toolchain between the
>> "normal" ones (for that toolchain, e.g. 64bit) and the lib32/ ones, then
>> you'd have "mingw64-tc64-m64" and "mingw64-tc64-m32"
>>
>
> Yes, this is a nice plan, clear and concise naming.
>

Glad you approve. :-)

>>> The pthreads naming is a bit confusing (to myself as well). I should
>>> change it to something easier. Ideas welcome.
>>
>> Well, if the ideas above make sense, then it should be pretty
>> straightforward to extend them to libpthread2.
>>
>
>  From the packaging point of view, having them buried in toolchain is a
> lot easier than trying to move them around at postinstall.

Hmm...maybe.  There are two meanings of the term "postinstall".  There's 
"after setup.exe unpacks the tarball on the end-users computer, it runs 
a postinstall script". And there's "in cygport, within src_install() you 
can do additional manipulations of the ${D} tree after calling 
cyginstall()/'make install'".

Sure, postinstall scripts in the first sense are a little icky. But I've 
never had much trouble manipulating things in src_install().

> OK, I will use --prefix=/opt/mingw64 and
> --with-sysroot=/opt/mingw64/{x86_64,i686}-w64-mingw32 to avoid stuff
> clashing with /usr/share.
>
> Target DLLs will go in /opt/mingw64/bin{32,64}. Users will have a
> consistent place to look for them.

I really think this makes sense -- but before haring off on my wild 
ideas, wait for some other folks to chime in here. Sounds like 
NightStrike isn't too happy with my suggestions.

> To consolidate the DLLs, only one copy for 32bit and 64bit will be
> packaged from one of the compilers and placed in
> /opt/mingw64/bin{32,64}. For example, packaging 32bit libgcc DLL from
> the 64bit toolchain, but leaving out the one from the 32bit toolchain
> since they're similar.
>
> This leads to the next question, how do I add the /opt/mingw64/bin to
> the user's $PATH after installation?

THAT's easy.  Just put a couple of files in CYGWIN-PATCHES called
    mingw64-tc64.csh
    mingw64-tc64.sh
and install them during src_install() into

    ${D}/etc/profile.d/

They should just add /opt/mingw64/bin/ to the $PATH (front, probably).

Remember, on cygwin we're not too fussed about requiring somebody to 
either use a shell (so that .dotfiles can set $PATH and stuff) or to be 
knowledgable enough to manually set PATH themselves, if they want to 
call cygwin apps from "windows" directly.  Unlike mingw.org and mingw64.


> I am currently using this approach, this leads to long and complicated
> --exclude lines. Does the list file allow \n delimited list of files to
> include in the tarball release?

Yes. cygport basically passes that file to tar via -T.  Take a close 
look at my gettext cygport: I added functions so that I could use 
regexes in the .list file.

> That was my first attempt, but I concluded its better to have them
> shared according to your replies. There will still be 2 sources (each
> for 32bit default and 64bit default), but the runtime target dlls won't
> get duplicated.

OK.

> I tried fixing up libtool upstream to use "w64" and "w32" prefix instead
> of "lib" prefix like the cygwin "cyg" prefix, but maintainers weren't
> too welcoming of the idea.

Yeah, I can see that.  I think ideally you'd want to leave -m32 alone, 
but perhaps modify libtool to use a special prefix only for 64bit dlls. 
Or maybe we could extend libtool to allow adding a "_64" *suffix* prior 
to the DLLNUM: libpng_64-12.dll. That'd be a bigger patch, tho.

>> As a final shortcut, you tweak both cygports to create
>> non-tc*-differentiated tarballs for the target runtime dlls to begin
>> with, so in the end, both cygports create
>>

Good: pick one of each pair of these identically named tarballs.

>> mingw64-m64-libgcc1-VER-REL.tar.bz2 <<< gen by -tc64- cygport
>> mingw64-m32-libgcc1-VER-REL.tar.bz2 <<< gen by -tc64- cygport
>> mingw64-m64-libgcc1-VER-REL.tar.bz2 <<< gen by -tc32- cygport
>> mingw64-m32-libgcc1-VER-REL.tar.bz2 <<< gen by -tc32- cygport
>>
>> rather than

Bad: differently named tarballs, but each -mNN- pair contains a DLL that 
is (hopefully) identical, and installed into the same 
/opt/mingw64/bin{32|64}/ directory:

>> mingw64-tc64-m64-libgcc1-VER-REL.tar.bz2 <<< gen by -tc64- cygport
>> mingw64-tc64-m32-libgcc1-VER-REL.tar.bz2 <<< gen by -tc64- cygport
>> mingw64-tc32-m64-libgcc1-VER-REL.tar.bz2 <<< gen by -tc32- cygport
>> mingw64-tc32-m32-libgcc1-VER-REL.tar.bz2 <<< gen by -tc32- cygport
>>
>> and you simply upload only one of each pair.
>>
>
> Setup won't fudge over similarly named packages? I thought of doing just:
> mingw64-m64-libgcc1-VER-REL.tar.bz2 <<< gen by -tc64- cygport
> mingw64-m32-libgcc1-VER-REL.tar.bz2 <<< gen by -tc64- cygport

Those two names are different "enough" that setup will distinguish 
between the two.

> and having them totally independent of the actual toolchain that
> generated them, from setup.exe's package dependency point of view.

Err...I think that's what I said.

You end up with two different packages (one built during the -tc64- 
build, and the other during the -tc32- build) with identical names [say: 
mingw64-m64-libgcc1-VER-REL.tar.bz2".  Only include one of those two in 
your upload set.

Ditto for the two identical tarballs named 
"mingw64-m32-libgcc1-VER-REL.tar.bz2" Only upload one of them.

--
Chuck