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 CF> gcc as gcc3. However, this will require manual deinstallation of CF> gcc (2.95.3-whatever) so this is probably a bad thing. Somehow, I CF> just think that if we don't still make the older version of gcc CF> available, there will be many "This used to build on gcc 2.95.3!!!" CF> messages. CF> So, maybe I should rename the old version to gcc2 or release a version CF> of 2.95.3 that names the binaries (i686-pc-cygwin-gcc2) differently. CF> Any 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 CF> mingw and I think I've actually been pretty successful. However, CF> my new scheme relies on changing the machine name from i686-pc-cygwin CF> to i686-pc-mingw. That means that the new layout looks like this: CF> /usr/i686-pc-mingw/: CF> total 0 CF> lrwxrwxrwx 1 cgf None 122 Jun 23 23:41 bin -> ../i686-pc-cygwin/bin CF> lrwxrwxrwx 1 cgf None 125 Jun 23 23:42 include -> /usr/include/mingw CF> lrwxrwxrwx 1 cgf None 113 Jun 23 23:42 lib -> /usr/lib/mingw CF> /usr/lib/gcc-lib: CF> total 0 CF> drwxr-xr-x 4 cgf None 0 Dec 25 2000 i686-pc-cygwin CF> lrwxrwxrwx 1 cgf None 108 Jun 23 23:48 i686-pc-mingw -> i686-pc-cygwin CF> Ideally, the include, lib stuff in /usr/i686-pc-mingw should not be a CF> symbolic link but should, instead, be the actual directories that they CF> reference. However, coordinating this will be tricky. I'm thinking that CF> I should just add a postinstall script that will try to do the right thing CF> if /usr/i686-pc-mingw doesn't have the right stuff. However, I'd like to CF> confirm 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? CF> FWIW, 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, CF> with gcc-3.1, I've configured things using --enable-threads=posix. So, some CF> binaries don't link successfully. That means that the libgcc.a library is CF> inappropriate for mingw. So, the above directory layout can potentially CF> become a little trickier since I'll need to build a libgcc.a (and libstdc++.a, CF> I guess) for mingw. This seems like a lot of duplication of effort, though, CF> so maybe I'll try to figure out some way to download the bits that I need CF> from sourceforge or something. Or,... CF> 4) Since mingw is becoming so logically separated from gcc, it is possible that CF> it could become a separate package. So, if "someone" was willing to supply CF> a gcc-mingw package, it would actually be helpful. I don't think I could CF> stand the pain of making this optional, so the gcc package would rely on CF> the gcc-mingw package rather than the other way around. This would allow CF> updating libgcc.a and libstdc++.a without requiring a new release of gcc. CF> Hmm. I wonder if I should break libstdc++.a out of the gcc package. Urgh. CF> Any 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] but somehow missed the final resolution. Egor. mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19