This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
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
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