From: Cesar S. <ces...@gm...> - 2010-01-06 21:25:34
|
I released a new toolchain for MSYS based on GCC 3.4.4. It is formed by the combination of the following packages: gcc-3.4.4-1-msys-1.0.12-bin.tar.lzma binutils-2.19.51-1-msys-1.0.12-bin.tar.lzma msysCORE-1.0.12-1-msys-1.0.12-dev.tar.lzma w32api-3.14-mingw32-dev.tar.gz.tar.lzma These form a self-contained toolchain, so there is no need to install msysDVLPR-1.0.0-alpha-1.tar.gz first. As a test-drive, I updated the MSYS xz package. I used the same source and patch from the latest MinGW xz package, plus the MSYS-specific patch of the previous MSYS version. But, with the new toolchain, all the changes relating to C89 compatibility were no longer needed and thus removed from the patch. There were no regressions in the test suite (all passed) and, in fact, I used the updated lzma tool to compress all the new packages. At this time, one still need msysDVLPR to build the MSYS DLL. Even so, a gcc-2.95 toolchain can still be updated with the new binutils and msysCORE-dev packages. In related news, I split the msysCORE package into -bin, -dev and -dbg. The -bin package contains the MSYS DLL plus the basic files of an MSYS installation and the MSYS documentation. The -dev package contains the header files and import library for the MSYS DLL, and is part of the new toolchain. The -dbg package has a renamed debug version of the MSYS DLL, the strace utility, and the symbolic information file for decoding stack dumps. Since I had made some fixes for the MSYS DLL already, I choose to release the reorganized package as 1.0.12, instead of simply incrementing the build number. Enjoy, Cesar |
From: Chris S. <ir0...@gm...> - 2010-01-06 22:39:21
|
Hi Cesar, > It is formed by the combination of the following packages: > > gcc-3.4.4-1-msys-1.0.12-bin.tar.lzma > binutils-2.19.51-1-msys-1.0.12-bin.tar.lzma > msysCORE-1.0.12-1-msys-1.0.12-dev.tar.lzma > w32api-3.14-mingw32-dev.tar.gz.tar.lzma I'm curious, why was a new w32api necessary? Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Cesar S. <ces...@gm...> - 2010-01-07 00:38:30
|
Hi Chris, >> It is formed by the combination of the following packages: >> >> gcc-3.4.4-1-msys-1.0.12-bin.tar.lzma >> binutils-2.19.51-1-msys-1.0.12-bin.tar.lzma >> msysCORE-1.0.12-1-msys-1.0.12-dev.tar.lzma >> w32api-3.14-mingw32-dev.tar.gz.tar.lzma > > I'm curious, why was a new w32api necessary? I didn't upload a new w32api, I just re-used the existing MinGW one. I see now that the text above reads as the very list of files that I uploaded, but it's not. Let me rephrase: I created a new toolchain for MSYS based on GCC 3.4.4. To install it, unpack the following new packages under the MSYS root: MSYS gcc gcc-3.4.4-1-msys-1.0.12-bin.tar.lzma MSYS binutils binutils-2.19.51-1-msys-1.0.12-bin.tar.lzma MSYS Base System msysCORE-1.0.12-1-msys-1.0.12-dev.tar.lzma In addition, unpack the following MinGW package, but again under the MSYS root, so that MSYS gcc can find it: MinGW API for MS-Windows w32api-3.14-mingw32-dev.tar.gz (or newer) Sorry for the confusion, and hope this clears it up. Cesar |
From: Charles W. <cwi...@us...> - 2010-01-07 00:36:55
|
Cesar Strauss wrote: > I released a new toolchain for MSYS based on GCC 3.4.4. Great! Thank you very much for pursuing this. I hope we can soon have a DLL versions of libiconv and libintl, and then coreutils (and everything else) will have a much smaller on-disk footprint! This won't help the download size much, as I've mentioned before, because the repeated inclusion of static libintl code in every .exe actually compresses quite well; hence eliminating it won't shrink the .tar.lzma by very much. But we won't need /bin/true.exe to be 1MB anymore... > It is formed by the combination of the following packages: > > gcc-3.4.4-1-msys-1.0.12-bin.tar.lzma Q: what source code did you 'start' with? Stock gcc-3.4.4 from fsf, or the cygwin-special source code? (I really hope it was the latter). > binutils-2.19.51-1-msys-1.0.12-bin.tar.lzma > msysCORE-1.0.12-1-msys-1.0.12-dev.tar.lzma > w32api-3.14-mingw32-dev.tar.gz.tar.lzma ^^^^^^^^^^^^^^^ ? I guess you're trying to indicate that the existing w32api-3.14 package for mingw should be unpacked under the C:\msys\1.0 directory, so that the msys-gcc compiler can find it? In that case, I really think you should just re-package it as w32api-3.14-msys-1.0.12-dev.tar.lzma, even if the contents are the same [*]. Our installation "procedure" is already convoluted enough; about the only rule we have is that -msys- packages get unpacked under C:\msys\1.0 and -mingw32- packages get unpacked under C:\MinGW. I really don't want to see a list of exceptions -- "except w32api which gets unpacked twice, once in each location". OTOH, if you're saying that the new msys-gcc compiler will actually look in /mingw/include for headers by default...oh please no. That's just ASKING for trouble. [*] Actually, I don't think the contents SHOULD be the same. I think that msys should instead follow the cygwin lead, and put the w32api headers into [/usr]/include/w32api and the libs in [/usr]/lib/w32api. The specs file already includes those paths by default [**], and the separation helps msys remain more similar to cygwin (which I believe is a good thing). [**] on cygwin, and I assume you didn't change this for msys > These form a self-contained toolchain, so there is no need to install > msysDVLPR-1.0.0-alpha-1.tar.gz first. > > As a test-drive, I updated the MSYS xz package. I used the same source > and patch from the latest MinGW xz package, plus the MSYS-specific patch > of the previous MSYS version. But, with the new toolchain, all the > changes relating to C89 compatibility were no longer needed and thus > removed from the patch. There were no regressions in the test suite (all > passed) and, in fact, I used the updated lzma tool to compress all the > new packages. That's very good news. However...I wish you had /not/ uploaded the new xz package. I'm concerned about ABI breakage between (msys)gcc-2.95.3 and (msys)gcc-3.4.4. Does msys-bsdtar still work on your system, as it is dynamically linked to msys-lzma-1.dll by way of msys-archive-2.dll? I *know* there were ABI breakages in C++ between 2.95.3 and 3.x (one at 3.0, and at 3.1, then another at 3.2, and then another at 3.4). I'm not sure whether there was an ABI breakage in C during that time frame [*]. [*] I don't think there were any "all-platform" ABI breaks in C during this time frame, but there were a number of platform-specific ones (sparc, mips). For instance, 3.4.0 broke -mms-bitfields on i386-cygming but it was fixed in 3.4.1. Also, AFAIK the cygwin gcc-3.4.x source code was *heavily* modified from the stock version, and if you used that -- and I suspect you did; the stock gcc-3.4.x code was almost non-functional on cygwin -- then THOSE changes have a potential of breaking the ABI with respect to 2.95.3. (Esp: the exceptions-across-dll-boundaries cygming-specific patch, which made its debut sometime in the gcc-3.2.x timeframe, actually changed the *C* ABI IIRC, by expanding a structure defined in libgcc.a) In short, my plan once "someone" released an updated msys-gcc compiler, was to rebuild using that compiler *ALL* of the (non-core) msys packages which provide libraries. I would do this in a specific order to avoid dependency on DLLs compiled using gcc-2.95.3, and then upload them ALL simultaneously. Now, that's a lot of work, so I don't want to do it twice. Hence, my concern that this new gcc won't build a working msys: > At this time, one still need msysDVLPR to build the MSYS DLL. Even so, a > gcc-2.95 toolchain can still be updated with the new binutils and > msysCORE-dev packages. Hmm. I wonder why that is -- and if it's worth pursuing. We can either a) do a bunch of archeology from the cygwin kernel source code circa 2002 to determine what THEY needed to change in order to build with gcc-3.x, and re-implement them, or b) determine whether the problem is actually in the compiler, and fix it there, or c) begin work on msys-2.0 by starting over with cygwin-1.7.x as a baseline. This is a lot of work. A LOT of work. ? If you're pretty confident that the problem is NOT (b), then I'll get started on my massive rebuild project... > In related news, I split the msysCORE package into -bin, -dev and -dbg. Glad to see this. Did you do this manually, or did you update your msysdvlpr script to do it automatically? > Since I had made some fixes for the MSYS DLL already, I choose to > release the reorganized package as 1.0.12, instead of simply > incrementing the build number. Seems reasonable. -- Chuck |
From: Cesar S. <ces...@gm...> - 2010-01-07 17:18:53
|
Charles Wilson wrote: > Cesar Strauss wrote: > Q: what source code did you 'start' with? Stock gcc-3.4.4 from fsf, or > the cygwin-special source code? (I really hope it was the latter). I used the cygwin sources for both gcc and binutils. >> w32api-3.14-mingw32-dev.tar.gz.tar.lzma > ^^^^^^^^^^^^^^^ > ? Copy & paste error. Should be just w32api-3.14-mingw32-dev.tar.gz > > I guess you're trying to indicate that the existing w32api-3.14 package > for mingw should be unpacked under the C:\msys\1.0 directory, so that > the msys-gcc compiler can find it? Exactly. > However...I wish you had /not/ uploaded the new xz package. I'm > concerned about ABI breakage between (msys)gcc-2.95.3 and > (msys)gcc-3.4.4. Sorry, I didn't think of that. When I was packaging the new toolchain, I ran into an issue with the existing MSYS xz package: it always hanged forever at a certain point of the archive creation. When I compiled it with gcc 3.4.4, it didn't hang. Since this was blocking me from releasing the toolchain, I didn't think twice. > Does msys-bsdtar still work on your system, as it is > dynamically linked to msys-lzma-1.dll by way of msys-archive-2.dll? Fortunately, it still works. I tested archive creation, listing and extracting, all with the --lzma setting. I also tested extracting the result with MSYS tar. >> At this time, one still need msysDVLPR to build the MSYS DLL. Even so, a >> gcc-2.95 toolchain can still be updated with the new binutils and >> msysCORE-dev packages. > > Hmm. I wonder why that is -- and if it's worth pursuing. We can either > > a) do a bunch of archeology from the cygwin kernel source code circa > 2002 to determine what THEY needed to change in order to build with > gcc-3.x, and re-implement them, or I'll do a bit of debugging and archeology. > b) determine whether the problem is actually in the compiler, and fix it > there, or I am pleasantly surprised how well it is behaving up to now. >> In related news, I split the msysCORE package into -bin, -dev and -dbg. > > Glad to see this. Did you do this manually, or did you update your > msysdvlpr script to do it automatically? > It is automated. I did update my msysdvlpr script, as well as the format of the package-specific recipes. Your own build scripts, which I examined, were clearly a source of inspiration. Cesar |
From: Cesar S. <ces...@gm...> - 2010-01-11 14:04:31
|
Cesar Strauss wrote: > Charles Wilson wrote: >> Cesar Strauss wrote: >>> At this time, one still need msysDVLPR to build the MSYS DLL. Even >>> so, a gcc-2.95 toolchain can still be updated with the new binutils >>> and msysCORE-dev packages. >> >> Hmm. I wonder why that is -- and if it's worth pursuing. We can either >> >> a) do a bunch of archeology from the cygwin kernel source code circa >> 2002 to determine what THEY needed to change in order to build with >> gcc-3.x, and re-implement them, or > > I'll do a bit of debugging and archeology. The issue seems to be related to the use of "new" inside the kernel. Even a harmless simple line like "int * x = new int;" will stop it on its tracks (no additional output, no stack dump, nothing). By commenting a few lines which used "new", I managed to get strace output, and even a bash prompt, but it doesn't get very far until it gets to a code path that uses "new". Cesar |
From: Earnie B. <ea...@us...> - 2010-01-07 15:03:34
|
Quoting Charles Wilson <cwi...@us...>: > Cesar Strauss wrote: >> I released a new toolchain for MSYS based on GCC 3.4.4. > > Great! Thank you very much for pursuing this. I hope we can soon have a > DLL versions of libiconv and libintl, and then coreutils (and everything > else) will have a much smaller on-disk footprint! > I'll 2nd the "Great!", this has been needed for years. > This won't help the download size much, as I've mentioned before, > because the repeated inclusion of static libintl code in every .exe > actually compresses quite well; hence eliminating it won't shrink the > .tar.lzma by very much. But we won't need /bin/true.exe to be 1MB > anymore... > >> It is formed by the combination of the following packages: >> >> gcc-3.4.4-1-msys-1.0.12-bin.tar.lzma > > Q: what source code did you 'start' with? Stock gcc-3.4.4 from fsf, or > the cygwin-special source code? (I really hope it was the latter). > I'm interested in hearing in this, but I suspect it would be the cygwin-special source code. >> binutils-2.19.51-1-msys-1.0.12-bin.tar.lzma >> msysCORE-1.0.12-1-msys-1.0.12-dev.tar.lzma >> w32api-3.14-mingw32-dev.tar.gz.tar.lzma > ^^^^^^^^^^^^^^^ > ? > > I guess you're trying to indicate that the existing w32api-3.14 package > for mingw should be unpacked under the C:\msys\1.0 directory, so that > the msys-gcc compiler can find it? > > In that case, I really think you should just re-package it as > w32api-3.14-msys-1.0.12-dev.tar.lzma, even if the contents are the same > [*]. Our installation "procedure" is already convoluted enough; about > the only rule we have is that -msys- packages get unpacked under > C:\msys\1.0 and -mingw32- packages get unpacked under C:\MinGW. I > really don't want to see a list of exceptions -- "except w32api which > gets unpacked twice, once in each location". > I don't think we want to confuse the general public with w32api-3.14-msys packages. As you say it is convoluted enough already and adding duplicate packages would be even more confusing. > OTOH, if you're saying that the new msys-gcc compiler will actually look > in /mingw/include for headers by default...oh please no. That's just > ASKING for trouble. > Cesar has already answered this and said that the compiler looks in the msys/include directory. > [*] Actually, I don't think the contents SHOULD be the same. I think > that msys should instead follow the cygwin lead, and put the w32api > headers into [/usr]/include/w32api and the libs in [/usr]/lib/w32api. > The specs file already includes those paths by default [**], and the > separation helps msys remain more similar to cygwin (which I believe is > a good thing). > And I don't believe that it is a good thing but would live with it if the packaging changed. I would just ``mv w32api/* . && rmdir w32api'' in the include and lib directories. > [**] on cygwin, and I assume you didn't change this for msys > Easy enough to check it but I may have changed it for the 2.95 version. Too long ago to remember. >> These form a self-contained toolchain, so there is no need to install >> msysDVLPR-1.0.0-alpha-1.tar.gz first. >> >> As a test-drive, I updated the MSYS xz package. I used the same source >> and patch from the latest MinGW xz package, plus the MSYS-specific patch >> of the previous MSYS version. But, with the new toolchain, all the >> changes relating to C89 compatibility were no longer needed and thus >> removed from the patch. There were no regressions in the test suite (all >> passed) and, in fact, I used the updated lzma tool to compress all the >> new packages. > > That's very good news. > I agree. --8<-- > In short, my plan once "someone" released an updated msys-gcc compiler, > was to rebuild using that compiler *ALL* of the (non-core) msys packages > which provide libraries. I would do this in a specific order to avoid > dependency on DLLs compiled using gcc-2.95.3, and then upload them ALL > simultaneously. > > Now, that's a lot of work, so I don't want to do it twice. Hence, my > concern that this new gcc won't build a working msys: > >> At this time, one still need msysDVLPR to build the MSYS DLL. Even so, a >> gcc-2.95 toolchain can still be updated with the new binutils and >> msysCORE-dev packages. > > Hmm. I wonder why that is -- and if it's worth pursuing. We can either > > a) do a bunch of archeology from the cygwin kernel source code circa > 2002 to determine what THEY needed to change in order to build with > gcc-3.x, and re-implement them, or > > b) determine whether the problem is actually in the compiler, and fix it > there, or > > c) begin work on msys-2.0 by starting over with cygwin-1.7.x as a > baseline. This is a lot of work. A LOT of work. > I really think that option c would now be doable though. Especially since the mount table work has moved from registry entries to /etc/fstab. There would need to be a script to redo the existing /etc/fstab file to the new format though. And we could possibly do a more managed effort at supporting the Cygwin changes within the MSYS fork but that in itself would be quite a bit of work. -- Earnie |
From: Charles W. <cwi...@us...> - 2010-01-07 15:36:16
|
Earnie Boyd wrote: > Quoting Charles Wilson: >> Cesar Strauss wrote: >>> I released a new toolchain for MSYS based on GCC 3.4.4. >> Q: what source code did you 'start' with? Stock gcc-3.4.4 from fsf, or >> the cygwin-special source code? (I really hope it was the latter). > I'm interested in hearing in this, but I suspect it would be the > cygwin-special source code. Yes, Cesar actually stated this explicitly in the release notes. >> In that case, I really think you should just re-package it as >> w32api-3.14-msys-1.0.12-dev.tar.lzma, even if the contents are the same >> [*]. Our installation "procedure" is already convoluted enough; about >> the only rule we have is that -msys- packages get unpacked under >> C:\msys\1.0 and -mingw32- packages get unpacked under C:\MinGW. I >> really don't want to see a list of exceptions -- "except w32api which >> gets unpacked twice, once in each location". > I don't think we want to confuse the general public with > w32api-3.14-msys packages. As you say it is convoluted enough already > and adding duplicate packages would be even more confusing. Well, we already have packages like xz-*-mingw32-* and xz-*-msys-*. Adding one more such "duplicate" is, IMO, a LOT less confusing that making a bunch of special-purpose installation rules. And how the heck is mingw-get supposed to figure THIS one out? Are we going to teach it about all these special rules, as they (inevitably) proliferate? > Cesar has already answered this and said that the compiler looks in > the msys/include directory. > >> [*] Actually, I don't think the contents SHOULD be the same [snip] > > And I don't believe that it is a good thing but would live with it if > the packaging changed. I would just ``mv w32api/* . && rmdir w32api'' > in the include and lib directories. Sure, your choice. However, once we have an actual installer that can be used to manage the installation, moving files around manually is just one more manual step you have to remember to do every time package X is updated. If it ain't broke, don't fix it. Now, I realize that argument can easily be turned around back at me. My only argument in favor of "my" proposal is "like cygwin" == "good", and that it does no harm provided the specs are as I remember them. > Easy enough to check it but I may have changed it for the 2.95 > version. Too long ago to remember. Well, FWICT, Cesar didn't use any of "your" 2.95 changes. He simply started with the cygwin source code, and applied the cygwin->MSYS naming patch. (Technically, this means that msys-gcc-3.4 supports -mno-[cygwin|msys], for an interesting twist; I recommend officially disavowing that mode, since msys-gcc has no way of automatically knowing where the mingw-native headers and libs are. Neither did cygwin-gcc, which is why we finally got tired of it, and removed it in gcc-4). >> c) begin work on msys-2.0 by starting over with cygwin-1.7.x as a >> baseline. This is a lot of work. A LOT of work. >> > > I really think that option c would now be doable though. Especially > since the mount table work has moved from registry entries to > /etc/fstab. There would need to be a script to redo the existing > /etc/fstab file to the new format though. Well, maybe. Unfortunately -- from our perspective -- cygwin has over the years since 1.3.x, made a lot of effort in improving file perms behavior and user security; I think it would be difficult to remove all of that in favor of msys's traditional wide-open behavior. Unless you're proposing a more cygwin-like approach, there, as well -- in which case mingw-get would need a lot of help, similar to some of the code that's gone into cygwin-setup. **IF** Cesar's new msys-gcc is sufficient for all non-kernel compiling, I think an incremental approach would be better: Let's first get the current (1.0.12) msys environment up to scratch -- the new compiler should allow us to dispense with a lot of cruft, as Cesar has already demonstrated wrt xz, and as I'm sure will be the case with gettext/libintl. Then, make a decision going forward about the next version of msys. FWIW, it's common knowledge that if you're using gcc as the base compiler, then you need at least gcc-3.2 to compile gcc-4.x. AND, the current cygwin kernels have only been compiled with gcc4 for > 6 mos; I'm not even sure they can be compiled with 3.x anymore (although they MAY be). So, if we want to rebase onto 1.7, then we MAY need to get msys-gcc-4. In which case msys-gcc-3.4 is a necessary first step anyway! > And we could possibly do a > more managed effort at supporting the Cygwin changes within the MSYS > fork but that in itself would be quite a bit of work. Just bringing in the cygwin source on a vendor branch (or updating it to latest, if such a branch already exists) would help there. -- Chuck |
From: Keith M. <kei...@us...> - 2010-01-08 17:45:28
|
On Thursday 07 January 2010 15:36:05 Charles Wilson wrote: > > I don't think we want to confuse the general public with > > w32api-3.14-msys packages. As you say it is convoluted enough > > already and adding duplicate packages would be even more > > confusing. > > Well, we already have packages like xz-*-mingw32-* and > xz-*-msys-*. Adding one more such "duplicate" is, IMO, a LOT less > confusing that making a bunch of special-purpose installation > rules. I agree. Providing separate packages for the mingw32 and msys subsystems, even if some are effective duplicates, makes perfect sense to me too -- much more so than saying "for an MSYS (development) installation, you also need to use this mingw32 package, but you must install a separate copy of it, into your MSYS sysroot rather than your mingw32 sysroot". > And how the heck is mingw-get supposed to figure THIS one > out? Are we going to teach it about all these special rules, as > they (inevitably) proliferate? No, please, *don't* ask mingw-get to do this; specifying a dependency such as: <requires ge="w32api-3.14-mingw32-dev.tar" /> and letting mingw-get resolve that as it needs w32api-3.14 or later, (version >= 3.14), which it will install into the sysroot for the mingw32 subsystem is easily handled -- this much, I have working already -- but to make it choose a different sysroot, (and maybe even a different sysroot-relative installation path), based on the requirer, isn't something I want to contemplate; let's KISS. > [case for include/w32api and lib/w32api subdirectories] > > Now, I realize that argument can easily be turned around back at > me. My only argument in favor of "my" proposal is "like cygwin" > == "good", and that it does no harm provided the specs are as I > remember them. Well, if the two subsystems have entirely separate distribution tarballs, it's fairly immaterial what you choose. If you do want to make that argument, then it's only a small step to suggest that the stock MinGW build of GCC should be taught to do likewise. Then maybe the MSYS development compiler wouldn't need a distinct w32api installation -- the mingw32 installation could be mapped through the fstab, to let both mingw32 and MSYS compilers share a common installation. However, that again would be adding an unnecessary layer of installation complexity, which we probably don't want. > Technically, this means that msys-gcc-3.4 supports > -mno-[cygwin|msys], for an interesting twist; I recommend > officially disavowing that mode, I fully agree. I always thought Cygwin's `-mno-cygwin' was a particularly nasty kludge, to get functionality which is basically a cross-compiler; GCC already has well established standards for implementing those, so why not adopt them? In any case, the purpose of this MSYS compiler is to facilitate MSYS development -- it should never be considered, in any way, as an alternative to a properly installed native MinGW tool chain, for other Win32 development. > Unfortunately -- from our perspective -- cygwin has over > the years since 1.3.x, made a lot of effort in improving file > perms behavior and user security; I think it would be difficult to > remove all of that in favor of msys's traditional wide-open > behavior. Unless you're proposing a more cygwin-like approach, > there, as well -- in which case mingw-get would need a lot of > help, similar to some of the code that's gone into cygwin-setup. I *really* don't want to burden mingw-get with that, if it can be avoided. -- Regards, Keith. |
From: Cesar S. <ces...@gm...> - 2010-01-10 17:59:29
|
Keith Marshall wrote: > On Thursday 07 January 2010 15:36:05 Charles Wilson wrote: >>> I don't think we want to confuse the general public with >>> w32api-3.14-msys packages. As you say it is convoluted enough >>> already and adding duplicate packages would be even more >>> confusing. >> Well, we already have packages like xz-*-mingw32-* and >> xz-*-msys-*. Adding one more such "duplicate" is, IMO, a LOT less >> confusing that making a bunch of special-purpose installation >> rules. > > I agree. Providing separate packages for the mingw32 and msys > subsystems, even if some are effective duplicates, makes perfect > sense to me too -- much more so than saying "for an MSYS > (development) installation, you also need to use this mingw32 > package, but you must install a separate copy of it, into your MSYS > sysroot rather than your mingw32 sysroot". OK, then. I will provide a w32api-3.14-msys-1.0.12-dev package. Can I just copy it over from MinGW and change the name, or must I rebuild it from source with the MSYS toolchain? Note that I plan to keep the MSYS version always updated to the latest MinGW w32api release. Cesar |
From: Charles W. <cwi...@us...> - 2010-01-10 22:44:10
Attachments:
msys-build-w32api.bz2
|
Cesar Strauss wrote: > OK, then. I will provide a w32api-3.14-msys-1.0.12-dev package. > > Can I just copy it over from MinGW and change the name, or must I > rebuild it from source with the MSYS toolchain? > > Note that I plan to keep the MSYS version always updated to the latest > MinGW w32api release. I think every unique package group (${PKG}-*-${SUBSYS}) should have its own -src. But...you can easily piggy-back. Here's an msys-build-w32api for that: ./msys-build-w32api w32api-3.14-mingw32-src.tar.gz Note that it uses the mingw -src package. As written, it installs into /include and /lib, but that can be changed by adding --includedir=/usr/include/w32api \ --libdir=/usr/lib/w32api to the $confargs, if that's what is decided in the other subthread. Anyway, this script will create w32api-3.14-1-msys-1.0.12-dev.tar.lzma w32api-3.14-1-msys-1.0.12-src.tar.lzma where the latter contains w32api-3.14-mingw32-src.tar.gz msys-build-w32api -- Chuck |
From: Charles W. <cwi...@us...> - 2010-01-08 02:04:54
|
Cesar Strauss wrote: > I released a new toolchain for MSYS based on GCC 3.4.4. > > It is formed by the combination of the following packages: > > gcc-3.4.4-1-msys-1.0.12-bin.tar.lzma > binutils-2.19.51-1-msys-1.0.12-bin.tar.lzma > msysCORE-1.0.12-1-msys-1.0.12-dev.tar.lzma > w32api-3.14-mingw32-dev.tar.gz.tar.lzma Minor nits with these new packages: =================================== 1) gcc --version gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) This should probably say something about MSYS, instead of/in addition to cygming. =================================== 2) gcc -dumpspecs | grep cyg %{mwindows:--subsystem windows} %{mconsole:--subsystem console} %{shared: %{mdll: %eshared and mdll are not compatible}} %{shared: --shared} %{mdll:--dll} %{static:-Bstatic} %{!static:-Bdynamic} %{shared|mdll: -e %{mno-msys:_DllMainCRTStartup@12} %{!mno-msys:__msys_dll_entry@12}} %{!mno-msys:--dll-search-prefix=cyg} The --dll-search-prefix should be 'msys-' not 'cyg' =================================== 3) bsdtar tvf gcc-3.4.4-1-msys-1.0.12-doc.tar.lzma | grep man | sed -e 's/cstrauss Administradores//' drwxr-xr-x 0 0 Jan 16:06 share/man/ drwxr-xr-x 0 0 Jan 16:06 share/man/man1/ -rw-r--r-- 0 37730 Jan 16:06 share/man/man1/cpp.1 -rw-r--r-- 0 10 Jan 16:06 share/man/man1/g++.1 -rw-r--r-- 0 10 Jan 16:06 share/man/man1/gcc.1 -rw-r--r-- 0 23640 Jan 16:06 share/man/man1/gcov.1 drwxr-xr-x 0 0 Jan 16:06 share/man/man7/ -rw-r--r-- 0 6396 Jan 16:06 share/man/man7/fsf-funding.7 -rw-r--r-- 0 25885 Jan 16:06 share/man/man7/gfdl.7 -rw-r--r-- 0 24687 Jan 16:06 share/man/man7/gpl.7 Err, what happened to gcc.1 and g++.1? =================================== 4) bsdtar tvf gcc-3.4.4-1-msys-1.0.12-doc.tar.lzma | grep info | sed -e 's/cstrauss Administradores//' drwxr-xr-x 0 0 Jan 16:06 share/info/ -rw-r--r-- 0 217111 Jan 16:06 share/info/cpp.info -rw-r--r-- 0 49806 Jan 16:06 share/info/cppinternals.info -rw-r--r-- 0 163977 Jan 16:06 share/info/gccinstall.info Where did gcc.info (and to a lesser degree, gccint.info) go? =================================== 5) bsdtar tvf binutils-2.19.51-1-msys-1.0.12-doc.tar.lzma | grep man | sed -e 's/cstrauss Administradores//' drwxr-xr-x 0 0 Jan 18:27 share/man/ drwxr-xr-x 0 0 Jan 18:27 share/man/man1/ -rw-r--r-- 0 0 Jan 18:27 share/man/man1/addr2line.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/ar.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/as.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/c++filt.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/dlltool.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/gprof.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/ld.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/nlmconv.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/nm.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/objcopy.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/objdump.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/ranlib.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/readelf.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/size.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/strings.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/strip.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/windmc.1 -rw-r--r-- 0 0 Jan 18:27 share/man/man1/windres.1 All the man pages are empty? Oops... =================================== 6) not a bug, just a comment: bsdtar tf binutils-2.19.51-1-msys-1.0.12-bin.tar.lzma | grep '\.[l]*a$' lib/libbfd.a lib/libbfd.la lib/libiberty.a lib/libopcodes.a lib/libopcodes.la So, for MSYS, at least, binutils owns these libraries? I think that's the right choice, here, but it should be noted among the msys devs. For MinGW, that's a whole 'nother question... Also, I've checked and the specs file DOES add /usr/include/w32api to the default include path, and the linker script(s) DO add /usr/lib/w32api to the default library search path. So, repacking w32api as cygwin does 'em WILL work -- if we choose to do so. I've got some other comments about msysCORE-*-bin, but I'll put those in a separate message. -- Chuck |
From: Charles W. <cwi...@us...> - 2010-01-08 02:38:16
|
Charles Wilson wrote: > =================================== > 2) gcc -dumpspecs | grep cyg > %{mwindows:--subsystem windows} %{mconsole:--subsystem console} > %{shared: %{mdll: %eshared and mdll are not compatible}} > %{shared: --shared} %{mdll:--dll} %{static:-Bstatic} > %{!static:-Bdynamic} %{shared|mdll: -e > %{mno-msys:_DllMainCRTStartup@12} %{!mno-msys:__msys_dll_entry@12}} > %{!mno-msys:--dll-search-prefix=cyg} > > The --dll-search-prefix should be 'msys-' not 'cyg' Oh, and another: $ gcc -dumpspecs | grep CYG %(cpp_cpu) %{posix:-D_POSIX_SOURCE} %{mno-win32:%{mno-msys: %emno-msys and mno-win32 are not compatible}} %{mno-msys:-D__MSVCRT__ -D__MINGW32__ %{!ansi:%{mthreads:-D_MT}}} %{!mno-msys:-D__CYGWIN32__ -D__MSYS__ %{!ansi:-Dunix} -D__unix__ -D__unix } %{mwin32|mno-msys:-DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ %{!ansi:-DWINNT}} %{!nostdinc:%{!mno-win32|mno-msys:-idirafter ../include/w32api%s -idirafter ../../include/w32api%s}} Can we add -D__CYGWIN__ in addition to -D__CYGWIN32__? I think what happened here is before the cygwin->msys translation, it had -D__CYGWIN32__ -D__CYGWIN__ and the translation gave us -D__CYGWIN32__ -D__MSYS__ but IMO we want -D__CYGWIN32__ -D__CYGWIN__ -D__MSYS__ -- Chuck |
From: Charles W. <cwi...@us...> - 2010-01-10 13:13:45
|
I found another packaging issue with the new MSYS compiler...well, actually with the msysCORE-dev package. The files are packaged like: i686-pc-msys/ i686-pc-msys/include/ i686-pc-msys/include/a.out.h i686-pc-msys/include/ar.h i686-pc-msys/include/arpa/ ... i686-pc-msys/include/utmp.h i686-pc-msys/include/wchar.h i686-pc-msys/include/_ansi.h i686-pc-msys/include/_syslist.h i686-pc-msys/lib/ i686-pc-msys/lib/automode.o i686-pc-msys/lib/binmode.o i686-pc-msys/lib/crt0.o i686-pc-msys/lib/gcrt0.o i686-pc-msys/lib/libc.a i686-pc-msys/lib/libg.a i686-pc-msys/lib/libgmon.a i686-pc-msys/lib/libm.a i686-pc-msys/lib/libmsys-1.0.dll.a i686-pc-msys/lib/textmode.o While the compiler will look for library files in i686-pc-msys/lib/: $ gcc -print-file-name=binmode.o /bin/../lib/gcc/i686-pc-msys/3.4.4/../../../../i686-pc-msys/lib/binmode.o It will not look for its include files in i686-pc-msys/include: $ echo '#include <assert.h>' | gcc -E - # 1 "<stdin>" # 1 "<built-in>" # 1 "<command line>" # 1 "<stdin>" <stdin>:1:20: assert.h: No such file or directory I think that, in both cases (lib and inc) these files should be moved to [/usr]/lib/* and [/usr]/include/*, respectively. HOWEVER, the argument against that is 1) IF the end-user installs both mingw and msys into the same root 2) AND they install the msysCORE-*-dev.tar.lzma files (where the msysCORE-*-dev package has been restructured as I suggest), THEN the MinGW compiler will see msys headers in its main include dir, and the MSYS compiler will see MinGW headers. This is bad. BUT --- it's *already* the case that all of the other *-msys-*-dev packages install headers into /include. So, really, we already have the following RULE: *IF* you want to install any -msys-dev- packages, *THEN* you must install msys and mingw into separate roots. Because all of the other -msys-dev packages already do this, there's no additional cost in doing it for the msysCORE-dev package. Plus, we already recommend the separate-roots structure -- and always have -- so IMO this restriction is no big deal. -- Chuck |
From: Cesar S. <ces...@gm...> - 2010-01-10 15:29:53
Attachments:
gcc.txt
|
Charles Wilson wrote: > It will not look for its include files in i686-pc-msys/include: > $ echo '#include <assert.h>' | gcc -E - > # 1 "<stdin>" > # 1 "<built-in>" > # 1 "<command line>" > # 1 "<stdin>" > <stdin>:1:20: assert.h: No such file or directory Strange, it works for me. Could you send me the output of echo '#include <assert.h>' | gcc -E -v - > ~/gcc.txt 2>&1 (note the -v option) Mine is attached. Note, in particular: > #include <...> search starts here: > /usr/lib/gcc/i686-pc-msys/3.4.4/include > /usr/lib/gcc/i686-pc-msys/3.4.4/../../../../i686-pc-msys/include ^^^^^^^^^^^^^^^^^^^^ > /usr/include > End of search list. Could you try extracting these (and only these) in a new root, and trying again (be sure to run the newly extracted msys.bat): bash-3.1.17-2-msys-1.0.11-bin.tar.lzma binutils-2.19.51-1-msys-1.0.12-bin.tar.lzma gcc-3.4.4-1-msys-1.0.12-bin.tar.lzma msysCORE-1.0.12-1-msys-1.0.12-bin.tar.lzma msysCORE-1.0.12-1-msys-1.0.12-dev.tar.lzma w32api-3.14-mingw32-dev.tar.gz Cesar |
From: Charles W. <cwi...@us...> - 2010-01-10 23:05:40
|
Cesar Strauss wrote: > Charles Wilson wrote: >> It will not look for its include files in i686-pc-msys/include: >> $ echo '#include <assert.h>' | gcc -E - >> # 1 "<stdin>" >> # 1 "<built-in>" >> # 1 "<command line>" >> # 1 "<stdin>" >> <stdin>:1:20: assert.h: No such file or directory > > Strange, it works for me. Could you send me the output of > > echo '#include <assert.h>' | gcc -E -v - > ~/gcc.txt 2>&1 > > (note the -v option) Hmmph. False alarm. It works now. # 1 "<stdin>" # 1 "<built-in>" # 1 "<command line>" # 1 "<stdin>" # 1 "/bin/../lib/gcc/i686-pc-msys/3.4.4/../../../../i686-pc-msys/include/assert.h" 1 3 ... I've been playing around with swapping gcc-3.4.4 and gcc-2.95.3 in and out (I need to rebuild msys itself using 2.95, and then test the pseudo-reloc support [*] using 3.4. Yeah, it probably would have been smarter to use two separate installations.). Maybe I just got confused as to the state of my installation. Sorry for the noise. It's no longer a question of 'it doesn't work this way, so we should do it that way' -- it's now simply a question of policy: which directories SHOULD msysCORE-*-dev install into? Or the other *-msys-*-dev packages? 1) Would it make sense for all of the other *-msys-*-dev packages to use --libdir=/usr/i686-pc-msys/lib \ --includedir=/usr/i686-pc-msys/include ? That would keep those files 'out of the way' of a co-mingled mingw installation. However, I'm afraid it might give users a false sense of security: there WILL be other conflicts: e.g. auto*-*-msys (with its hacked config.guess) auto*-*-mingw (with "normal" config.guess) etc. 2) Status quo: all the other -msys-*-dev packages install their lib/inc files into /usr/include & /usr/lib. msysCORE-*-dev installs into /usr/i686-pc-msys/[include|lib]. Why mess with something that works, and there is SOME argument to treating msysCORE 'specially'. OTOH, it just seems odd that they are different. 3) Move msysCORE-dev files into /usr/[include|lib]. [*] Side note: I'm working on adding pseudo-reloc runtime support, but it requires quite a bit of additional msys.dll changes. It'll probably be yet another version bump to 1.0.13. I'll start feeding those patches to the list for discussion before checking them in to CVS (or letting Cesar do that). -- Chuck |
From: Cesar S. <ces...@gm...> - 2010-01-10 17:09:37
|
Charles Wilson wrote: > Cesar Strauss wrote: > Minor nits with these new packages: Thank you for your review. I addressed them (see below) and uploaded "release-2" packages. For now, they live at "MSYS Proposed". If no more issues are found, I will eventually move them to their proper location. Otherwise, fixed packages will continue to go to "MSYS Proposed". This is to avoid cluttering the release area with too much short-lived releases. > 1) gcc --version > gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > > This should probably say something about MSYS, instead of/in addition to > cygming. How about simply: $ gcc --version gcc (GCC) 3.4.4 (msys special) > 2) gcc -dumpspecs | grep cyg > The --dll-search-prefix should be 'msys-' not 'cyg' Done. > 3) bsdtar tvf gcc-3.4.4-1-msys-1.0.12-doc.tar.lzma | grep man | sed -e > 's/cstrauss Administradores//' > Err, what happened to gcc.1 and g++.1? Fixed. > 4) bsdtar tvf gcc-3.4.4-1-msys-1.0.12-doc.tar.lzma | grep info | sed -e > 's/cstrauss Administradores//' > Where did gcc.info (and to a lesser degree, gccint.info) go? Fixed. > 5) bsdtar tvf binutils-2.19.51-1-msys-1.0.12-doc.tar.lzma | grep man | > sed -e 's/cstrauss Administradores//' > All the man pages are empty? Oops... Fixed. > 6) not a bug, just a comment: > bsdtar tf binutils-2.19.51-1-msys-1.0.12-bin.tar.lzma | grep '\.[l]*a$' > lib/libbfd.a > lib/libbfd.la > lib/libiberty.a > lib/libopcodes.a > lib/libopcodes.la > > So, for MSYS, at least, binutils owns these libraries? I think that's > the right choice, here, but it should be noted among the msys devs. For > MinGW, that's a whole 'nother question... Noted in the binutils release notes. > Oh, and another: > > $ gcc -dumpspecs | grep CYG > Can we add -D__CYGWIN__ in addition to -D__CYGWIN32__? Sure. Cesar |
From: Charles W. <cwi...@us...> - 2010-01-10 23:30:58
|
Cesar Strauss wrote: > Thank you for your review. > > I addressed them (see below) and uploaded "release-2" packages. Thanks, Cesar! > For now, they live at "MSYS Proposed". If no more issues are found, I > will eventually move them to their proper location. Otherwise, fixed > packages will continue to go to "MSYS Proposed". This is to avoid > cluttering the release area with too much short-lived releases. That sounds reasonable. I took the liberty of moving your -1 releases to that directory, as well. binutils looks good, as do the gcc -doc and -lic packages. But the gcc-bin package hasn't shown up yet... === Oh, here's something to keep in mind for the next release, IF you find it necessary to do one for OTHER reasons (that is, I don't think this issue is important enough, all by itself, to justify another respin)... Keith and I hashed out a directory structure for documentation (--docdir) that looks like this: [/usr]/share/doc/<PACKAGE>/<VER>/ not [/usr]/share/doc/<PACKAGE>-<VER>/ Hence, my /usr/share/doc/ directory looks like this: MSYS cvs gmp lndir popt autoconf cygutils grep m4 regex autogen diffutils groff make rxvt automake file guile man sed bash findutils gzip minires tar binutils-2.19.51 flex inetutils mktemp termcap bison gawk less openssh texinfo bzip2 gcc-3.4.4 libarchive openssl vim coreutils gdbm libiconv patch xz crypt gettext libtool perl zlib Notice the two that are different? -- Chuck |
From: Cesar S. <ces...@gm...> - 2010-01-11 17:56:10
|
Cesar Strauss wrote: > Cesar Strauss wrote: >> Charles Wilson wrote: >>> Cesar Strauss wrote: >>>> At this time, one still need msysDVLPR to build the MSYS DLL. Even >>>> so, a gcc-2.95 toolchain can still be updated with the new >>>> binutils and msysCORE-dev packages. >>> >>> Hmm. I wonder why that is -- and if it's worth pursuing. We can either >>> >>> a) do a bunch of archeology from the cygwin kernel source code circa >>> 2002 to determine what THEY needed to change in order to build with >>> gcc-3.x, and re-implement them, or >> >> I'll do a bit of debugging and archeology. > > The issue seems to be related to the use of "new" inside the kernel. Success! 2002-12-04 Thomas Pfaff <tpfaff -at- gmx.net> * cxx.cc: New file. Implement new, new[], delete and delete[] operators and __cxa_pure_virtual if compiled by gcc >=3. * Makefile.in (DLL_OFILES): Add cxx.o. Remove libstdc++.a from cygwin1.dll link step. With this missing piece, I was able to produce a working MSYS DLL compiled with the latest MSYS GCC 3.4.4 toolchain. Goodbye, msysDVLPR-1.0.0-alpha-1.tar.gz. You served us well. Cheers, Cesar |
From: Charles W. <cwi...@us...> - 2010-01-11 23:45:36
|
Cesar Strauss wrote: >> The issue seems to be related to the use of "new" inside the kernel. > > Success! > > 2002-12-04 Thomas Pfaff <tpfaff -at- gmx.net> > > * cxx.cc: New file. Implement new, new[], delete and delete[] > operators and __cxa_pure_virtual if compiled by gcc >=3. > * Makefile.in (DLL_OFILES): Add cxx.o. > Remove libstdc++.a from cygwin1.dll link step. > > With this missing piece, I was able to produce a working MSYS DLL > compiled with the latest MSYS GCC 3.4.4 toolchain. > > Goodbye, msysDVLPR-1.0.0-alpha-1.tar.gz. You served us well. Hooray!! Thanks for tracking this down, Cesar; this is wonderful news! I'm gonna go off and do my happy dance, now. -- Chuck |