On Tue, 2010-11-23 at 17:28 -0500, Charles Wilson wrote: > ------------------ 1 --------------- > The first set of packages are revisions (actually, just rearranging the > contents) of the venerable add-on packages that provide -mno-cygwin > support for gcc-3.
Why can't we keep things simple and just dump those outright? Aside from nostalgia, what reason do we have to continue supporting gcc3 when AFAIK no other major distro does so? This would mean making these empty _obsolete packages (with cleanup postinstall scripts if necessary), and dropping the gcc-mingw-* deps from gcc-* (3.x). > ------------------ 2 --------------- > The second group of packages are the libraries associated with the new > cross compiler. This includes: This part looks sane, except for the split DLL/-devel packages, but we've already discussed that at length. > ------------------ 3 --------------- > The third group of packages is the actual cross compiler toolchain. This > includes: > > = mingw-binutils-2.20.51-1-src.tar.bz2 > = mingw-binutils-2.20.51-1.tar.bz2 > > = mingw-gcc-4.5.1-1-src.tar.bz2 > = mingw-gcc-core-4.5.1-1.tar.bz2 > = mingw-gcc-fortran-4.5.1-1.tar.bz2 > = mingw-gcc-g++-4.5.1-1.tar.bz2 > = mingw-gcc-objc-4.5.1-1.tar.bz2 Of course, by now binutils 2.21 and gcc-4.5.2 are out... BTW, do these include the shrext=.dll.a patch for config.rpath? This is necessary for dynamic linking against libintl in binutils, gcc, and gdb. > These tools are configure as cross-compilers with sysroot support -- the > gcc configuration CYGCONF_ARGS are: > --disable-multilib > --disable-win32-registry > --enable-languages=c,c++,fortran,objc,obj-c++ > --enable-fully-dynamic-strings > --enable-libgomp > --disable-sjlj-exceptions > --enable-libstdcxx-debug > --enable-version-specific-runtime-libs > --with-dwarf2 > --disable-werror > --enable-lto I presume that these match the "official" native MinGW options, so that binaries are compatible? > Once a native cygwin gcc-4.5.1 (or perhaps 4.5.0) with ada support is > made official, I'll update mingw-gcc to also include ada (you need a > native ada compiler of a similar version in order to build an ada cross > compiler). Ahem, Dave????? http://cygwin.com/ml/cygwin/2011-01/msg00049.html > When MinGW.org offers a 4.5.x compiler with java support, I'll update > this cross compiler to do so as well. FYI, I have found an issue building ecjx (which installs as ecj1) as part of a cross-gcc; ecjx.o is cross-compiled with xgcc instead of native-compiled with $host-gcc, but linked with the latter. Preliminary patch attached. > With these new packages installed, I was able to build setup.exe from > current CVS without issue -- by default, the existing bootstrap.sh > script now uses the cross compiler automatically if > i686-pc-mingw32-g++ > is installed. I took care of mingw-gcc-4.5 issues when I discovered them as part of the cygport cross-compiler support development. > With only the gcc-mingw- "add ons" for gcc-3 installed (plus its > pre-requisites: mingw-binutils, mingw-w32api, mingw-runtime, AND > mingw-gcc-core which provides i686-pc-mingw32-gcc but NOT > i686-pc-mingw32-g++), I was able to build setup.exe using gcc-3 > -mno-cygwin -- but I had to pass > CPPFLAGS=-I/usr/i686-pc-mingw32/sys-root/mingw/include > LDFLAGS=-L/usr/i686-pc-mingw32/sys-root/mingw/lib > as commandline arguments to bootstrap.sh. The attached patch does this > automatically. Yuck. Let's just drop support for gcc -mno-cygwin and be done with it. > Finally: official rollout. > > I don't know how we can ease the pain of the three step (or, at minimum, > two step) install process, given the wacky things the EXISTING > gcc-mingw- packages have already done to the file system tree. One > possibility is to ONLY release the updated gcc-mingw- addons (with > judicious modifications of their requires: lines) and let people install > those. Say, for about a month. > > > Then, after the month has passed, go ahead and move the other packages > over to sourceware. People who "blindly upgrade" after than will bork > their system (it's fixable, but awkward) -- but MOST people will have > already upgraded their gcc-mingw (and probably didn't even notice), so > they'll be fine. I suppose the alternative is to document the upgrade steps in the announcement, and deal with the problems from all those that don't read them. Yaakov
--- origsrc/gcc-4.5.2/libjava/Makefile.am 2010-07-15 07:05:56.000000000 -0500 +++ src/gcc-4.5.2/libjava/Makefile.am 2011-01-11 16:17:07.828828300 -0600 @@ -1124,10 +1124,17 @@ endif else !NATIVE ecjx_LINK = $(GCJ_FOR_ECJX_LINK) $(ecjx_LDFLAGS) +if INSTALL_ECJ_JAR ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) +else +ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) -Djava.class.path=$(ECJ_JAR) +endif ecjx_LDADD = ecjx_DEPENDENCIES = +ecjx.$(OBJEXT): ecjx.cc + $(GCJ_FOR_ECJX) -c -o $@ $< + endif !NATIVE ## This is a dummy definition. --- origsrc/gcc-4.5.2/libjava/Makefile.in 2010-12-16 06:49:03.000000000 -0600 +++ src/gcc-4.5.2/libjava/Makefile.in 2011-01-11 16:18:06.282130200 -0600 @@ -8515,7 +8515,8 @@ ECJX_BASE_FLAGS = -findirect-dispatch \ @native_t...@ecjx_link = $(GCJLINK) $(ecjx_LDFLAGS) @ENABLE_SHARED_FALSE@@native_t...@ecjx_ldflags = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) -fbootclasspath=$(BOOTCLASSPATH) @ENABLE_SHARED_TRUE@@native_t...@ecjx_ldflags = $(ECJX_BASE_FLAGS) -Djava.class.path=$(ECJ_JAR) -...@native_false@ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) +...@install_ecj_jar_false@@native_fa...@ecjx_ldflags = $(ECJX_BASE_FLAGS) -Djava.class.path=$(ECJ_JAR) +...@install_ecj_jar_true@@native_fa...@ecjx_ldflags = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) @native_fa...@ecjx_ldadd = @native_t...@ecjx_ldadd = -L$(here)/.libs $(extra_ldflags) \ @NATIVE_TRUE@ $(am__append_31) @@ -12888,6 +12889,9 @@ write-entries-to-file-check: @MAINTAINER_MODE_TRUE@@NATIVE_TRUE@ >> tmp-0212; \ @MAINTAINER_MODE_TRUE@@NATIVE_TRUE@ mv tmp-0212 $(srcdir)/gnu/gcj/convert/JIS0212.h +...@native_false@ecjx.$(OBJEXT): ecjx.cc +...@native_false@ $(GCJ_FOR_ECJX) -c -o $@ $< + src.zip: -rm -f src.zip here=`pwd`; \
