Re: mingw and other gotchas in gcc 3.1
Hi! Monday, 24 June, 2002 Conrad Scott [EMAIL PROTECTED] wrote: CS egor duda [EMAIL PROTECTED] wrote: Btw, libstdc++ in gcc 3.* is configured so that classes in std:: namespace are not visible unless one specify std:: via 'using' or explicitly. I feel this can be the problem that will make most noise. Cygwin setup is just one example of program affected. I have a patch that should work with both 2.95.3 and 3.*, and can post it if you're interested. CS As I understood this (that's a disclaimer), if you include the CS legacy headers, i.e. xxx.h, you get the names in the global CS namespace and it's only if you include the new headers, i.e. xxx, CS that you need the std:: qualifier or a using declaration. Of course, CS people may now be using the new headers without then using the std:: CS qualifier, since gcc 2.95.3 allows this. But they're wrong already :-) CS (not that that ever stopped someone complaining). CS Or have they abandoned the legacy headers altogether? No. But iosfwd and string and bunch of others are present in both old and new g++ headers. So, program like setup.exe which contain #include iosfwd and then 'ostream ostr;' would compile no more until someone changes 'ostream ostr;' to 'std::ostream ostr;' Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
Re: mingw and other gotchas in gcc 3.1
Christopher Faylor wrote: I'm finishing up on the release of gcc 3.1 and I have a few gotchas that I'd like to discuss: 1) I was going to take Red Hat's cue and release the new version of gcc as gcc3. However, this will require manual deinstallation of gcc (2.95.3-whatever) so this is probably a bad thing. Somehow, I just think that if we don't still make the older version of gcc available, there will be many This used to build on gcc 2.95.3!!! messages. So, maybe I should rename the old version to gcc2 or release a version of 2.95.3 that names the binaries (i686-pc-cygwin-gcc2) differently. Any thoughts? I think the gcc2 idea should be acceptable. 2) I'm trying to remove most of the spec file magic that dealt with mingw and I think I've actually been pretty successful. However, my new scheme relies on changing the machine name from i686-pc-cygwin to i686-pc-mingw. That means that the new layout looks like this: /usr/i686-pc-mingw/: total 0 lrwxrwxrwx1 cgf None 122 Jun 23 23:41 bin - ../i686-pc-cygwin/bin lrwxrwxrwx1 cgf None 125 Jun 23 23:42 include - /usr/include/mingw lrwxrwxrwx1 cgf None 113 Jun 23 23:42 lib - /usr/lib/mingw /usr/lib/gcc-lib: total 0 drwxr-xr-x4 cgf None0 Dec 25 2000 i686-pc-cygwin lrwxrwxrwx1 cgf None 108 Jun 23 23:48 i686-pc-mingw - i686-pc-cygwin Ideally, the include, lib stuff in /usr/i686-pc-mingw should not be a symbolic link but should, instead, be the actual directories that they reference. However, coordinating this will be tricky. I'm thinking that I should just add a postinstall script that will try to do the right thing if /usr/i686-pc-mingw doesn't have the right stuff. However, I'd like to confirm with Earnie/Danny that this new layout makes sense. FWIW, I think this is the way I should have laid stuff out originally. It should be i686-pc-mingw32. You also may wish the target to be stated only as mingw32 instead of i686-pc-mingw32 in order to be consistent with the MinGW version and to ward off confusion in the list. Otherwise it's fine with me. 3) The above layout has a problem. It works ok generating mingw binaries but, with gcc-3.1, I've configured things using --enable-threads=posix. So, some binaries don't link successfully. That means that the libgcc.a library is inappropriate for mingw. So, the above directory layout can potentially become a little trickier since I'll need to build a libgcc.a (and libstdc++.a, I guess) for mingw. This seems like a lot of duplication of effort, though, so maybe I'll try to figure out some way to download the bits that I need from sourceforge or something. Or,... The sourceforge ftp directory is ftp1.sourceforge.net/pub/sourceforge/mingw/ if you wish to take that direction. Or, Danny... 4) Since mingw is becoming so logically separated from gcc, it is possible that it could become a separate package. So, if someone was willing to supply a gcc-mingw package, it would actually be helpful. I don't think I could stand the pain of making this optional, so the gcc package would rely on the gcc-mingw package rather than the other way around. This would allow updating libgcc.a and libstdc++.a without requiring a new release of gcc. Hmm. I wonder if I should break libstdc++.a out of the gcc package. Urgh. Any suckers (cough) want to contribute a separate package? Or would a --host=cygwin --build=cygwin --target=mingw be better for the gcc-mingw cygwin package? Earnie.
Re: mingw and other gotchas in gcc 3.1
On Mon, Jun 24, 2002 at 10:44:08AM -0400, Earnie Boyd wrote: FWIW, I think this is the way I should have laid stuff out originally. It should be i686-pc-mingw32. I thought I asked about the mingw32 - mingw transition a while ago and you were fine with it. I've never actually understood the obsession with including the word size in the product name. It's like adding new to your package name. As soon as you do that, you guarantee that a package named new will be older than some other package at some point. I understand the genesis of packages like w32api and mingw32 but I think the 32 is really dating both packages. However, I can see that configure scripts seem to be assuming the 32 so, while it makes no difference to this application, I suppose I should be consistent with what configure creates. You also may wish the target to be stated only as mingw32 instead of i686-pc-mingw32 in order to be consistent with the MinGW version and to ward off confusion in the list. There is already a i686-pc-cygwin directory. i686-pc-mingw* is nicely compatible with that. 4) Since mingw is becoming so logically separated from gcc, it is possible that it could become a separate package. So, if someone was willing to supply a gcc-mingw package, it would actually be helpful. I don't think I could stand the pain of making this optional, so the gcc package would rely on the gcc-mingw package rather than the other way around. This would allow updating libgcc.a and libstdc++.a without requiring a new release of gcc. Hmm. I wonder if I should break libstdc++.a out of the gcc package. Urgh. Any suckers (cough) want to contribute a separate package? Or would a --host=cygwin --build=cygwin --target=mingw be better for the gcc-mingw cygwin package? I can't think of a reason why the natively built mingw stuff shouldn't work fine. cgf
Re: mingw and other gotchas in gcc 3.1
Hi! Monday, 24 June, 2002 Christopher Faylor [EMAIL PROTECTED] wrote: CF I'm finishing up on the release of gcc 3.1 and I have a few gotchas that CF I'd like to discuss: CF 1) I was going to take Red Hat's cue and release the new version of CFgcc as gcc3. However, this will require manual deinstallation of CFgcc (2.95.3-whatever) so this is probably a bad thing. Somehow, I CFjust think that if we don't still make the older version of gcc CFavailable, there will be many This used to build on gcc 2.95.3!!! CFmessages. CFSo, maybe I should rename the old version to gcc2 or release a version CFof 2.95.3 that names the binaries (i686-pc-cygwin-gcc2) differently. CFAny thoughts? This should be ok. There're also libstdc++ header files but, fortunately, dirs are named differently (g++-3 for 2.95.3 and g++-v3 for 3.*). Can we make sure that this will remain so? Btw, libstdc++ in gcc 3.* is configured so that classes in std:: namespace are not visible unless one specify std:: via 'using' or explicitly. I feel this can be the problem that will make most noise. Cygwin setup is just one example of program affected. I have a patch that should work with both 2.95.3 and 3.*, and can post it if you're interested. One more problem is min() and max() macros in windef.h. They conflict with min and max functions from std_limits.h. I've patched std_limits.h to #undef min and #undef max, but applications which do the following: #include windows.h // even if it's included non-directly #include limits ... x = max (a, b); would break. I haven't found better solution for this, other than mention it in release notes, though. CF 2) I'm trying to remove most of the spec file magic that dealt with CFmingw and I think I've actually been pretty successful. However, CFmy new scheme relies on changing the machine name from i686-pc-cygwin CFto i686-pc-mingw. That means that the new layout looks like this: CF /usr/i686-pc-mingw/: CF total 0 CF lrwxrwxrwx1 cgf None 122 Jun 23 23:41 bin - ../i686-pc-cygwin/bin CF lrwxrwxrwx1 cgf None 125 Jun 23 23:42 include - /usr/include/mingw CF lrwxrwxrwx1 cgf None 113 Jun 23 23:42 lib - /usr/lib/mingw CF /usr/lib/gcc-lib: CF total 0 CF drwxr-xr-x4 cgf None0 Dec 25 2000 i686-pc-cygwin CF lrwxrwxrwx1 cgf None 108 Jun 23 23:48 i686-pc-mingw - i686-pc-cygwin CFIdeally, the include, lib stuff in /usr/i686-pc-mingw should not be a CFsymbolic link but should, instead, be the actual directories that they CFreference. However, coordinating this will be tricky. I'm thinking that CFI should just add a postinstall script that will try to do the right thing CFif /usr/i686-pc-mingw doesn't have the right stuff. However, I'd like to CFconfirm with Earnie/Danny that this new layout makes sense. Do you think bin/ should contain cygwin-mingw cross-tools instead of being link to i686-pc-cygwin? CFFWIW, I think this is the way I should have laid stuff out originally. CF 3) The above layout has a problem. It works ok generating mingw binaries but, CFwith gcc-3.1, I've configured things using --enable-threads=posix. So, some CFbinaries don't link successfully. That means that the libgcc.a library is CFinappropriate for mingw. So, the above directory layout can potentially CFbecome a little trickier since I'll need to build a libgcc.a (and libstdc++.a, CFI guess) for mingw. This seems like a lot of duplication of effort, though, CFso maybe I'll try to figure out some way to download the bits that I need CFfrom sourceforge or something. Or,... CF 4) Since mingw is becoming so logically separated from gcc, it is possible that CFit could become a separate package. So, if someone was willing to supply CFa gcc-mingw package, it would actually be helpful. I don't think I could CFstand the pain of making this optional, so the gcc package would rely on CFthe gcc-mingw package rather than the other way around. This would allow CFupdating libgcc.a and libstdc++.a without requiring a new release of gcc. CFHmm. I wonder if I should break libstdc++.a out of the gcc package. Urgh. CFAny suckers (cough) want to contribute a separate package? libstdc++ seems to be a problem, no matter what was passed to --enable-threads. I agree that libstdc++ (and libgcc in case of --enable-threads=posix) stuff for mingw should be packaged separately. I build them by hand and tested cygwin setup with them, but i still have no automatic script to produce such package. CF I've been toiling away at this for some time, so I'd appreciate any CF useful suggestions. My next hurdle is updating the gcc cygwin 3.1 CF branch with the latest changes in the gcc 3.1 branch. Have you created cygwin branch in gcc repository? I've seen your question about it in [EMAIL PROTECTED]
Re: mingw and other gotchas in gcc 3.1
Christopher Faylor wrote: So, maybe I should rename the old version to gcc2 or release a version of 2.95.3 that names the binaries (i686-pc-cygwin-gcc2) differently. Any thoughts? I like this. 'gcc' ought to the the ongoing, 'current' package. If folks want the old version, the option of installing 'gcc2' alongside, and calling 'i686-pc-cygwin-gcc2' sounds like a good plan. 2) I'm trying to remove most of the spec file magic that dealt with mingw and I think I've actually been pretty successful. However, my new scheme relies on changing the machine name from i686-pc-cygwin to i686-pc-mingw. Hmmm...I think the official triplet (in the latest config.sub/config.guess files) is i686-pc-mingw32 NOT -mingw. 4) Since mingw is becoming so logically separated from gcc, it is possible that it could become a separate package. So, if someone was willing to supply a gcc-mingw package, it would actually be helpful. I don't think I could stand the pain of making this optional, so the gcc package would rely on the gcc-mingw package rather than the other way around. This would allow updating libgcc.a and libstdc++.a without requiring a new release of gcc. Hmm. I wonder if I should break libstdc++.a out of the gcc package. Urgh. Any suckers (cough) want to contribute a separate package? Are you considering 'gcc-mingw' to be just those mingw bits necessary for cygwin's gcc to compile mingw programs (err, I thought that was what mingw-runtime and w32api were for), or is 'gcc-mingw' to be a cygwin-hosted, mingw-target cross compiler, with separate binaries from cygwin's real gcc? I like the latter -- but (1) I'm worried about cygwin's ability to self-host if so... and (2) a real cross compiler would need its own version of binutils, unless you do clever symlinking things... Anyway, I've got cygwin-host, mingw-target setup-compatible gcc (2.95.3) and binutils packages up at http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ These install into /opt/mingw and do some fancy footwork with mount points in the postinstall script, but that could all be adjusted to match your preferred directory scheme, Chris. The point: (a) I'm not brave enough to try to recreate these from the gcc-3.1 release (b) but much of the packaging work is already done, if (c) someone else wants to take the packaging scripts + gcc-3.1 and run with it. IFF Chris is talking about a cross compiler. I'm not sure he is, yet. --Chuck
Re: mingw and other gotchas in gcc 3.1
egor duda [EMAIL PROTECTED] wrote: Btw, libstdc++ in gcc 3.* is configured so that classes in std:: namespace are not visible unless one specify std:: via 'using' or explicitly. I feel this can be the problem that will make most noise. Cygwin setup is just one example of program affected. I have a patch that should work with both 2.95.3 and 3.*, and can post it if you're interested. As I understood this (that's a disclaimer), if you include the legacy headers, i.e. xxx.h, you get the names in the global namespace and it's only if you include the new headers, i.e. xxx, that you need the std:: qualifier or a using declaration. Of course, people may now be using the new headers without then using the std:: qualifier, since gcc 2.95.3 allows this. But they're wrong already :-) (not that that ever stopped someone complaining). Or have they abandoned the legacy headers altogether? // Conrad
