Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
On 1/26/2010 23:31, JonY wrote: On 1/26/2010 23:07, Dave Korn wrote: On 25/01/2010 04:16, JonY wrote: This could be changed in the upstream GCC with libw32stdc++-6 as 32bit mingw-w64 toolchain, libw64stdc++-6 as 64bit mingw-w64, and the normal libstdc++-6 for the mingw.org toolchain. Now all 3 can live side by side. That seems like a logical and consistent extension of the existing cyg*-vs-lib* DLL namespacing convention. cheers, DaveK Hi, there is also a related bug with libgcc which does not use libtool. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947. Basically, the same issue with mingw based toolchains using libgcc_s_EH-1.dll, clobbering each other on multilib mingw-w64 GCC installs. Hi, packaging put on hold for awhile. I need to file some FSF copyright papers before I can fix the DLL clash issue on GCC. Sorry for the inconvenience.
Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
On 25/01/2010 01:34, Yaakov (Cygwin/X) wrote: On 24/01/2010 19:03, JonY wrote: and libiberty.a. Wouldn't this belong in /usr/$triplet/lib/? Libiberty needn't be installed or shipped at all really. It's pretty damn useless without any header file. Dunno why make install even bothers with it. cheers, DaveK
Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
On 25/01/2010 04:16, JonY wrote: This could be changed in the upstream GCC with libw32stdc++-6 as 32bit mingw-w64 toolchain, libw64stdc++-6 as 64bit mingw-w64, and the normal libstdc++-6 for the mingw.org toolchain. Now all 3 can live side by side. That seems like a logical and consistent extension of the existing cyg*-vs-lib* DLL namespacing convention. cheers, DaveK
Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
On 1/26/2010 23:07, Dave Korn wrote: On 25/01/2010 04:16, JonY wrote: This could be changed in the upstream GCC with libw32stdc++-6 as 32bit mingw-w64 toolchain, libw64stdc++-6 as 64bit mingw-w64, and the normal libstdc++-6 for the mingw.org toolchain. Now all 3 can live side by side. That seems like a logical and consistent extension of the existing cyg*-vs-lib* DLL namespacing convention. cheers, DaveK Hi, there is also a related bug with libgcc which does not use libtool. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947. Basically, the same issue with mingw based toolchains using libgcc_s_EH-1.dll, clobbering each other on multilib mingw-w64 GCC installs.
Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
Hi, While packaging new binutils for cross mingw and mingw-w64, I've noticed there were some duplicate files, but I'm not sure how to handle them with cygport, advice welcome. The duplicate files are mostly under usr/share/locale/ and libiberty.a. We could fix this by making all cross toolchains use seperate --prefix and --with-sysroot, but I don't know if its appropriate. There are also some issues for DLL'ized GCC target libs, such as libstdc++-6.dll. I've decided they should be disabled for mingw and mingw-w64 based 4.x toolchains for the moment, as they all wanted to be installed as libstdc++-6.dll into bindir, causing potential confusion for users. It can be re-enabled after its fixed in upstream GCC and libtool.
Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
On 24/01/2010 19:03, JonY wrote: While packaging new binutils for cross mingw and mingw-w64, I've noticed there were some duplicate files, but I'm not sure how to handle them with cygport, advice welcome. It's hard to give advice without seeing what you have already. How about showing us your .cygport files? The duplicate files are mostly under usr/share/locale/ Unless you can $triplet-namespace the textdomain, you might just need to not package those. and libiberty.a. Wouldn't this belong in /usr/$triplet/lib/? We could fix this by making all cross toolchains use seperate --prefix and --with-sysroot, but I don't know if its appropriate. That shouldn't be necessary. There are also some issues for DLL'ized GCC target libs, such as libstdc++-6.dll. I've decided they should be disabled for mingw and mingw-w64 based 4.x toolchains for the moment, as they all wanted to be installed as libstdc++-6.dll into bindir, causing potential confusion for users. It can be re-enabled after its fixed in upstream GCC and libtool. Whatever you do, the cross-compilers need to match what the target's native compiler would do. So if mingw's own toolchains are shipping and using shared GCC libraries, AFAICS you should do the same by enabling shared libraries and shipping the *import* libs but NOT the DLLs (which you only need to *execute* programs, which you're not doing because this is a *cross*-compile situation). Yaakov
Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
Yaakov (Cygwin/X) wrote: On 24/01/2010 19:03, JonY wrote: There are also some issues for DLL'ized GCC target libs, such as libstdc++-6.dll. I've decided they should be disabled for mingw and mingw-w64 based 4.x toolchains for the moment, as they all wanted to be installed as libstdc++-6.dll into bindir, causing potential confusion for users. It can be re-enabled after its fixed in upstream GCC and libtool. Whatever you do, the cross-compilers need to match what the target's native compiler would do. So if mingw's own toolchains are shipping and using shared GCC libraries, AFAICS you should do the same by enabling shared libraries and shipping the *import* libs but NOT the DLLs (which you only need to *execute* programs, which you're not doing because this is a *cross*-compile situation). There's no conflict between the cygwin libraries and the mingw ones; the gcc devs took care that the cygwin DLLs used the 'cyg*dll' pattern. Now, the conflict between the 32bit and 64bit DLLs? IMO, that would have been a show-stopper before rolling out the 64bit compiler in the first place: First, Do No Harm. Surely is was self-evidently obvious that people would want to run/install both 64bit and 32bit apps on the same system? But no care was taken to prevent this conflict. Sigh. However, given that a /real/ solution to this problem is not likely to come soon, I'd probably just install the runtime DLLs into the /usr/$triple/bin area -- since the $triples are different -- and let the end-user copy whichever one she wants into /usr/bin manually. -- Chuck
Re: Some troubles with packaging toolchains (was Re: Need input on packaging mingw-w64 for Cygwin)
On 1/25/2010 09:34, Yaakov (Cygwin/X) wrote:
On 24/01/2010 19:03, JonY wrote:
While packaging new binutils for cross mingw and mingw-w64, I've
noticed there were some duplicate files, but I'm not sure how to handle
them with cygport, advice welcome.
It's hard to give advice without seeing what you have already. How about
showing us your .cygport files?
Oh right. Draft 32bit and 64bit targeting binutils cygport attached.
The duplicate files are mostly under usr/share/locale/
Unless you can $triplet-namespace the textdomain, you might just need to
not package those.
and libiberty.a.
Wouldn't this belong in /usr/$triplet/lib/?
no, it is built by cygwin gcc for use with cross binutils, so its
considered native.
We could fix this by making all cross toolchains use seperate --prefix
and --with-sysroot, but I don't know if its appropriate.
That shouldn't be necessary.
There are also some issues for DLL'ized GCC target libs, such as
libstdc++-6.dll. I've decided they should be disabled for mingw and
mingw-w64 based 4.x toolchains for the moment, as they all wanted to be
installed as libstdc++-6.dll into bindir, causing potential confusion
for users. It can be re-enabled after its fixed in upstream GCC and
libtool.
Whatever you do, the cross-compilers need to match what the target's
native compiler would do. So if mingw's own toolchains are shipping and
using shared GCC libraries, AFAICS you should do the same by enabling
shared libraries and shipping the *import* libs but NOT the DLLs (which
you only need to *execute* programs, which you're not doing because this
is a *cross*-compile situation).
The import libs do not conflict, just the runtime dlls. When executing
the applications, we may have up to 3 libstdc++-6.dll, incompatible to
each other.
This could be changed in the upstream GCC with libw32stdc++-6 as 32bit
mingw-w64 toolchain, libw64stdc++-6 as 64bit mingw-w64, and the normal
libstdc++-6 for the mingw.org toolchain. Now all 3 can live side by
side.
DESCRIPTION=Binutils for Win x86 targets.
HOMEPAGE=http://www.gnu.org/software/binutils/;
SRC_URI=http://ftp.gnu.org/gnu/binutils/binutils-${PV}.tar.bz2;
PKG_NAMES=${PN} ${PN}-doc
PKG_CONTENTS[0]=usr/bin/ usr/i686-w64-mingw32/ usr/share/locale/
PKG_CONTENTS[1]=usr/share/doc/ usr/share/info/ usr/share/man/
SRC_DIR=binutils-${PV}
PKG_HINTS=setup doc
src_compile(){
cd ${B}
cygconf --build=i686-pc-cygwin --host=i686-pc-cygwin
--target=i686-w64-mingw32
cygmake
}
DESCRIPTION=Binutils for Win x64 targets.
HOMEPAGE=http://www.gnu.org/software/binutils/;
SRC_URI=http://ftp.gnu.org/gnu/binutils/binutils-${PV}.tar.bz2;
PKG_NAMES=${PN} ${PN}-doc
PKG_CONTENTS[0]=usr/bin/ usr/x86_64-w64-mingw32/ usr/share/locale/
PKG_CONTENTS[1]=usr/share/doc/ usr/share/info/ usr/share/man/
SRC_DIR=binutils-${PV}
PKG_HINTS=setup doc
src_compile(){
cd ${B}
cygconf --build=i686-pc-cygwin --host=i686-pc-cygwin
--target=x86_64-w64-mingw32
cygmake
}
Re: Need input on packaging mingw-w64 for Cygwin
mingw-w64 http://mingw-w64.sourceforge.net/ is a fork of mingw to support both win32 and win64. It'll obviously be setup as a cross compiler on Cygwin. I would like to get some inputs from Cygwin maintainers before I start packaging; mainly because mingw-w64 is a fairly large toolchain package and I'm still inexperienced at using cygport. Comments? It will be nice to have it! One question though, is there a point to having gdb? The stdin/stdout handling is messed up a little due to it being an interactive DOS app running within Cygwin. It works, but the command line interface can get a little messy after a while. Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org
Re: Need input on packaging mingw-w64 for Cygwin
On 1/23/2010 21:51, Chris Sutcliffe wrote: mingw-w64http://mingw-w64.sourceforge.net/ is a fork of mingw to support both win32 and win64. It'll obviously be setup as a cross compiler on Cygwin. I would like to get some inputs from Cygwin maintainers before I start packaging; mainly because mingw-w64 is a fairly large toolchain package and I'm still inexperienced at using cygport. Comments? It will be nice to have it! One question though, is there a point to having gdb? The stdin/stdout handling is messed up a little due to it being an interactive DOS app running within Cygwin. It works, but the command line interface can get a little messy after a while. Cheers! Chris Hi, You could build a cross gdb, and use gdb server on the inferior. Yeah, its a bit of a long shot, but I think it should work.
Re: Need input on packaging mingw-w64 for Cygwin
On Sat, Jan 23, 2010 at 09:47:17PM +0800, JonY wrote: On 1/23/2010 21:51, Chris Sutcliffe wrote: mingw-w64http://mingw-w64.sourceforge.net/ is a fork of mingw to support both win32 and win64. It'll obviously be setup as a cross compiler on Cygwin. I would like to get some inputs from Cygwin maintainers before I start packaging; mainly because mingw-w64 is a fairly large toolchain package and I'm still inexperienced at using cygport. Comments? It will be nice to have it! One question though, is there a point to having gdb? The stdin/stdout handling is messed up a little due to it being an interactive DOS app running within Cygwin. It works, but the command line interface can get a little messy after a while. Cheers! Chris Hi, You could build a cross gdb, and use gdb server on the inferior. Yeah, its a bit of a long shot, but I think it should work. Does this mean that these are all non-cygwin mingw apps? In that case no way that this should go into the distribution. I'm already on the fence anyway since the inclusion of these packages would be confusing on at least two levels. 1) They duplicate other packages in the distribution and 2) they YA confuse the distinction between mingw and cygwin. cgf
Re: Need input on packaging mingw-w64 for Cygwin
On 23/01/2010 19:02, Christopher Faylor wrote: On 1/23/2010 21:51, Chris Sutcliffe wrote: mingw-w64http://mingw-w64.sourceforge.net/ is a fork of mingw to support both win32 and win64. It'll obviously be setup as a cross compiler on Cygwin. Does this mean that these are all non-cygwin mingw apps? Nope, they are cygwin-based cross development tools. cheers, DaveK
Re: Need input on packaging mingw-w64 for Cygwin
Dave Korn wrote: On 23/01/2010 19:02, Christopher Faylor wrote: On 1/23/2010 21:51, Chris Sutcliffe wrote: mingw-w64http://mingw-w64.sourceforge.net/ is a fork of mingw to support both win32 and win64. It'll obviously be setup as a cross compiler on Cygwin. Does this mean that these are all non-cygwin mingw apps? Nope, they are cygwin-based cross development tools. Except, apparently, the proposed build of gdb -- unless Chris S. was confused: One question though, is there a point to having gdb? The stdin/stdout handling is messed up a little due to it being an interactive DOS app running within Cygwin. It works, but the command line interface can get a little messy after a while. My concern is this: we (cygwin) definitely need a gcc-4-based mingw cross compiler. On which source tree shall it be based, and who will be our maintainer? The proposal on the table is to use the mingw-64 source tree (that is, the gcc/binutils source code as patched by the mingw-w64 project, coupled with THIER patched version of the w32api and mingwrt runtime libs), configured in such a way as to support 32bit $host (*). I was under the impression, until now, that we would be using the mingw.org version of all of that. (*) Never mind the 64bit cross-compiler that the OP also proposed; that's a completely separate issue IMO. Now, from a practical standpoint this doesn't matter to me, so long as it works -- and the object code is interoperable. That is, can I compile a static library using C++ or C from the mingw-w64 project's 32bit compiler, and still use it with the mingw.org compiler? And vice versa? From a policy standpoint...the mingw community is split, and while there has been talk recently concerning reunification, that's all it has been: talk. The issues appear to be both personal and technical, from my interested but only marginally involved viewpoint: Personal: the mingw-w64 guys are critical of the (perceived) lack of user support form the mingw.org community; while the mingw.org guys are pissed that the w64 fellas have been pushing changes into upstream projects like gcc and binutils that sometimes conflict with the original mingw. Technical/Legal: The mingw.org guys are ADAMANT that nothing goes in to the runtime libraries and w32api stuff that is not 100% documented to come from open sources: reference to MSDN webpages, published books, etc. They fear -- and not without reason, IMO -- that the w64 folks are less scrupulous about what they put into their version of the w32api headers and .def files. This technical issue makes any reunification, without a painstaking documentation effort to scrutinize every difference between the w64 files and the mingw.org versions. Do we want to choose sides in this? It looks like we have no choice but to choose, as we need SOMETHING to compile native w32 code, such as setup.exe -- and gcc3 is getting long in the tooth. (Alternatively, we could let a thousand flowers bloom and have all three: mingw64-gcc-32bit, mingw64-gcc-64bit, and mingw-gcc-32bit cross compile toolchains in the distro...and cgf was worried about confusion?) Or we could allow the mingw64 64bit toolchain (as the mingw.org guys have no ability to support that anyway), but the mingw.org 32bit one. my 2c. -- Chuck
Re: Need input on packaging mingw-w64 for Cygwin
On 1/24/2010 04:51, Charles Wilson wrote: Dave Korn wrote: On 23/01/2010 19:02, Christopher Faylor wrote: On 1/23/2010 21:51, Chris Sutcliffe wrote: mingw-w64http://mingw-w64.sourceforge.net/ is a fork of mingw to support both win32 and win64. It'll obviously be setup as a cross compiler on Cygwin. Does this mean that these are all non-cygwin mingw apps? Nope, they are cygwin-based cross development tools. Except, apparently, the proposed build of gdb -- unless Chris S. was confused: One question though, is there a point to having gdb? The stdin/stdout handling is messed up a little due to it being an interactive DOS app running within Cygwin. It works, but the command line interface can get a little messy after a while. OK, cross gdb can be left out for now. The gdb server won't be a cygwin application, but gdb itself is. 32bit debugging is very much already covered by Cygwin gcc. My concern is this: we (cygwin) definitely need a gcc-4-based mingw cross compiler. On which source tree shall it be based, and who will be our maintainer? I can do a cross gcc-4 for plain mingw too, I just need some help for the cygport part. The proposal on the table is to use the mingw-64 source tree (that is, the gcc/binutils source code as patched by the mingw-w64 project, coupled with THIER patched version of the w32api and mingwrt runtime libs), configured in such a way as to support 32bit $host (*). I was under the impression, until now, that we would be using the mingw.org version of all of that. Binutils and GCC for mingw-w64 are vanilla FSF releases, no patches are applied. Well, no plans to replace mingw.org gcc, as it is what most users are used to. Personal: the mingw-w64 guys are critical of the (perceived) lack of user support form the mingw.org community; while the mingw.org guys are pissed that the w64 fellas have been pushing changes into upstream projects like gcc and binutils that sometimes conflict with the original mingw. I find that unfortunate, but I don't think the conflicts were intentional. It looks like we have no choice but to choose, as we need SOMETHING to compile native w32 code, such as setup.exe -- and gcc3 is getting long in the tooth. (Alternatively, we could let a thousand flowers bloom and have all three: mingw64-gcc-32bit, mingw64-gcc-64bit, and mingw-gcc-32bit cross compile toolchains in the distro...and cgf was worried about confusion?) Preferably, I would like to see all 3 of them available for Cygwin. They shouldn't conflict either, they have different target triplets.
Re: Need input on packaging mingw-w64 for Cygwin
On Sat, Jan 23, 2010 at 03:51:12PM -0500, Charles Wilson wrote: Dave Korn wrote: On 23/01/2010 19:02, Christopher Faylor wrote: On 1/23/2010 21:51, Chris Sutcliffe wrote: mingw-w64http://mingw-w64.sourceforge.net/ is a fork of mingw to support both win32 and win64. It'll obviously be setup as a cross compiler on Cygwin. Does this mean that these are all non-cygwin mingw apps? Nope, they are cygwin-based cross development tools. Except, apparently, the proposed build of gdb -- unless Chris S. was confused: Which was, oddly enough, the reason I asked the question. So, follow-on question: Can we have one toolchain which targets both 32-bit and 64-bit? It is certainly possible to do that on linux with a -m32 and -m64 option. Is it possible to do this with mingw? cgf
Re: Need input on packaging mingw-w64 for Cygwin
On Sun, Jan 24, 2010 at 2:03 AM, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: So, follow-on question: Can we have one toolchain which targets both 32-bit and 64-bit? It is certainly possible to do that on linux with a -m32 and -m64 option. Is it possible to do this with mingw? It's possible to do that with ours (ours being mingw-w64.sf.net), as we succeeded in getting multilib support to work. We can go in both directions -- primary target being win32, and alternate being win64, or vice versa. Ideally, you'd be able to use our toolchain to build everything on cygwin.
Re: Need input on packaging mingw-w64 for Cygwin
On 1/24/2010 15:03, Christopher Faylor wrote: On Sat, Jan 23, 2010 at 03:51:12PM -0500, Charles Wilson wrote: Dave Korn wrote: On 23/01/2010 19:02, Christopher Faylor wrote: On 1/23/2010 21:51, Chris Sutcliffe wrote: mingw-w64http://mingw-w64.sourceforge.net/ is a fork of mingw to support both win32 and win64. It'll obviously be setup as a cross compiler on Cygwin. Does this mean that these are all non-cygwin mingw apps? Nope, they are cygwin-based cross development tools. Except, apparently, the proposed build of gdb -- unless Chris S. was confused: Which was, oddly enough, the reason I asked the question. So, follow-on question: Can we have one toolchain which targets both 32-bit and 64-bit? It is certainly possible to do that on linux with a -m32 and -m64 option. Is it possible to do this with mingw? Hi, yes, its possible to have multilib capability for the mingw-w64 toolchain, but only with gcc trunk 4.5.0. There are also more issues with multilib capable toolchains, gcc target libs clashing. For example, make install currently tries to install both 32bit and 64bit libstdc++-6.dll into the bindir. Its a known issue, but it has yet to be fixed.
