This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] mingw-w64

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

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 and install them during src_install() into


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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]