Menu
▾
▴
linuxsh-dev
|
From: Bryan R. <br...@ix...> - 2001-08-23 02:00:37
|
Hello, Don't know if anyone on the list remembers me, but I'm back to SH4 after a six month affair with the PPC405. :-) We are going to be shipping a product including LinuxSH very shortly, and since a lot has probably changed since I was last involved with the project, I would really appreciate answers to the following ever-present questions: 1) What is currently the most stable SH4 kernel version for production use? We have had great luck with the 2.4.2 snapshot I got months ago, but I'd like to get something newer than that without going all the way to bleeding edge. 2) What is currently the most stable toolchain for building the kernel? Still the 2.97 version described by Masahiro Abe's instructions? (I'm a little reluctant to use an experimental compiler for production stuff, especially on the kernel) 3) What is the status of gcc 3.0, as we will shortly need it for building user code? (I've heard the kernel and glibc are still most stable/fast when built with older gcc). I know kaz Kojima has patches here: http://dodo.nurs.or.jp/~kkojima/index.html, but is anyone using them in a real production environment? 4) what is an approximate timeframe for getting binutils and gcc patches for LinuxSH merged with the mainline GNU trees? My work with Linux on the PPC405 has led me to think that this should be a _really_ high priority for all embedded forks of Linux/GNU tools. If my employer allows, I could be able to spend some time assisting in what ever way possible. Thanks! I'm looking forward to working with all of you again. Regards, Bryan -- Bryan Rittmeyer mailto:br...@ix... |
|
From: NIIBE Y. <gn...@m1...> - 2001-08-24 01:33:53
|
Bryan Rittmeyer wrote: > 1) What is currently the most stable SH4 kernel version for production > use? I think that it's the one around 2.4.5 but it's slow. For me, our 2.4.8 is stable but it's not tested much. > 2) What is currently the most stable toolchain for building the kernel? > Still the 2.97 version described by Masahiro Abe's instructions? > > (I'm a little reluctant to use an experimental compiler for production > stuff, especially on the kernel) Yes, it's still 2.97. I'm trying 3.0 now, with help of Kaz and Takeshi. However, glibc does not support 3.0 yet, it's difficult to just move to 3.0. > 3) What is the status of gcc 3.0, as we will shortly need it for > building user code? (I've heard the kernel and glibc are still > most stable/fast when built with older gcc). > > I know kaz Kojima has patches here: > http://dodo.nurs.or.jp/~kkojima/index.html, but > is anyone using them in a real production environment? I'm currently trying to build (part of ) Debian SH-4 with 3.0. I think I will have time for this work at San Francisco this weekend. > 4) what is an approximate timeframe for getting binutils and gcc patches > for LinuxSH merged with the mainline GNU trees? My work with Linux > on the PPC405 has led me to think that this should be a _really_ high > priority for all embedded forks of Linux/GNU tools. If my employer > allows, I could be able to spend some time assisting in what ever way > possible. > > Thanks! I'm looking forward to working with all of you again. Yes, I think so too. I'm not sure for the timeframe, I expects Kaz comments for that. I explain the current status here. This two weeks, I've tried to provide GNU/SH tool-chain for Debian. I've done some work based on binutils-2.11.2 and GCC 3.0.1. I think that binutils is ready for use. I sent diffs to Takeshi for comments. I expect new binutils-sh-linux Debian package comes soon by Takeshi. And I sent the needed diff to Kaz for comments, then, he tried it to current CVS version. Next comes, send them to mainline binutils development. For GCC, I think that it's not ready. Major concern is the definition of multilibbed environment. I built my own Debian gcc-sh-linux 3.0.1 package. I'm now using this for my experiment, and try to build some sort of Debian SH-4 distribution with this 3.0.1. While I'm doing this week, I encountered issues of name of libgcc shared library, still not solved. -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-08-24 13:15:21
|
NIIBE Yutaka wrote: > This two weeks, I've tried to provide GNU/SH tool-chain for Debian. > I've done some work based on binutils-2.11.2 and GCC 3.0.1. I've put my testing version to: ftp://ftp.m17n.org/pub/linux-sh/testing/ Sorry, this time, it's only for Debian. The patch for GCC 3.0.1 includes -mno-fdiv-divsi switch. I'm currently building glibc 2.2.4 with this tool-chain. -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-08-24 23:28:14
|
NIIBE Yutaka wrote: > I've put my testing version to: > ftp://ftp.m17n.org/pub/linux-sh/testing/ > > Sorry, this time, it's only for Debian. The patch for GCC 3.0.1 > includes -mno-fdiv-divsi switch. > > I'm currently building glibc 2.2.4 with this tool-chain. The version I put yesterday was bad. I uploaded good version now. With it, I've tested to compile glibc 2.2.4 for all four configurations (sh3, sh4, sh4eb, sh3eb) and kernel for DC. Here's the patch for new tool chain. Well, I'd like to commit this change, say, a month later, after we test GCC 3.0. * arch/sh/Makefile (CFLAGS): Use -mno-fdiv-divsi. Don't use -m4-nofpu. Index: arch/sh/Makefile =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/Makefile,v retrieving revision 1.20 diff -u -r1.20 Makefile --- arch/sh/Makefile 2001/07/28 04:02:00 1.20 +++ arch/sh/Makefile 2001/08/24 22:22:23 @@ -46,8 +46,8 @@ AFLAGS += -m3 endif ifdef CONFIG_CPU_SH4 -CFLAGS += -m4-nofpu -AFLAGS += -m4-nofpu +CFLAGS += -m4 -mno-fdiv-divsi +AFLAGS += -m4 -mno-fdiv-divsi endif # -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-09-12 09:34:31
|
For those weeks, I've been experimenting (finding) stable tool chain. I've put my bootstrapping of Debian SuperH at: ftp://ftp.m17n.org/pub/linux-sh/testing/debian-010911/ This includes sh3,sh3eb,sh4,sh4eb. Most is specific to Debian. The patch I've used for GCC is at: ftp://ftp.m17n.org/pub/linux-sh/testing/debian-010911/STEP-1.4/sh3/gcc-3.0-3.0.2ds0/debian/patches/superh.dpatch Cross compiler works well. Even with reverted sys_sh.c, libpthread.so doesn't work well, investigating. -- |
|
From: Bao C. H. <ba...@se...> - 2001-10-25 21:30:09
|
Are we reaching the point where I can apt-get the sh4 deb packages directly from Debian mirror sites? Thanks. Bao > -----Original Message----- > From: lin...@li... > [mailto:lin...@li...]On Behalf Of NIIBE > Yutaka > Sent: Wednesday, September 12, 2001 2:35 AM > To: linuxsh-dev > Subject: [linuxsh-dev] stable SH4 environment > > > For those weeks, I've been experimenting (finding) stable tool chain. > > I've put my bootstrapping of Debian SuperH at: > ftp://ftp.m17n.org/pub/linux-sh/testing/debian-010911/ > > This includes sh3,sh3eb,sh4,sh4eb. > > Most is specific to Debian. > > The patch I've used for GCC is at: > ftp://ftp.m17n.org/pub/linux-sh/testing/debian-010911/STEP-1.4 > /sh3/gcc-3.0-3.0.2ds0/debian/patches/superh.dpatch > > Cross compiler works well. > > Even with reverted sys_sh.c, libpthread.so doesn't work well, > investigating. > -- > > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsh-dev > |
|
From: NIIBE Y. <gn...@m1...> - 2001-10-12 13:49:02
|
On 25th Aug, NIIBE Yutaka wrote: > Here's the patch for new tool chain. Well, I'd like to commit this > change, say, a month later, after we test GCC 3.0. > > * arch/sh/Makefile (CFLAGS): Use -mno-fdiv-divsi. Don't use > -m4-nofpu. > > Index: arch/sh/Makefile > =================================================================== > RCS file: /cvsroot/linuxsh/kernel/arch/sh/Makefile,v > retrieving revision 1.20 > diff -u -r1.20 Makefile > --- arch/sh/Makefile 2001/07/28 04:02:00 1.20 > +++ arch/sh/Makefile 2001/08/24 22:22:23 > @@ -46,8 +46,8 @@ > AFLAGS += -m3 > endif > ifdef CONFIG_CPU_SH4 > -CFLAGS += -m4-nofpu > -AFLAGS += -m4-nofpu > +CFLAGS += -m4 -mno-fdiv-divsi > +AFLAGS += -m4 -mno-fdiv-divsi > endif > > # > -- The patch for GCC has been approved with name change to -mno-implicit-fp. I'll upload updated patch against GCC 3.0.1. Then, I'll apply arch/sh/Makefile change. -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-10-13 11:04:34
|
NIIBE Yutaka wrote: > I'll upload updated patch against GCC 3.0.1. Here it is: ftp://ftp.m17n.org/pub/super-h/testing/gcc-sh-linux_3.0.1-10.diff.gz It's kitchen sink (all is included) patch for Debian. I don't have time to explain each pieces. For that, please see gcc-patches mailing list archive. -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-10-16 08:21:23
|
NIIBE Yutaka wrote: > Here it is: > ftp://ftp.m17n.org/pub/super-h/testing/gcc-sh-linux_3.0.1-10.diff.gz I've run through the testsuite and found 10 regressions from 3.0.1-9. Here's new version: ftp://ftp.m17n.org/pub/super-h/testing/gcc-sh-linux_3.0.1-11.diff.gz ... which has no regressions from 3.0.1-9. -- |
|
From: kaz K. <kk...@rr...> - 2001-08-25 01:36:13
|
NIIBE Yutaka <gn...@m1...> wrote: >> 4) what is an approximate timeframe for getting binutils and gcc patches >> for LinuxSH merged with the mainline GNU trees? My work with Linux >> on the PPC405 has led me to think that this should be a _really_ high >> priority for all embedded forks of Linux/GNU tools. If my employer >> allows, I could be able to spend some time assisting in what ever way >> possible. >> >> Thanks! I'm looking forward to working with all of you again. > > Yes, I think so too. I'm not sure for the timeframe, I expects Kaz > comments for that. I explain the current status here. I also have no clear plan. Anyway, almost essential changes are already included in mainline except a few patches. Some unsended patches need more tests, for example, like -mno-fdiv-divsi patch. > This two weeks, I've tried to provide GNU/SH tool-chain for Debian. > I've done some work based on binutils-2.11.2 and GCC 3.0.1. > > I think that binutils is ready for use. I sent diffs to Takeshi for > comments. I expect new binutils-sh-linux Debian package comes soon by > Takeshi. And I sent the needed diff to Kaz for comments, then, he > tried it to current CVS version. Next comes, send them to mainline > binutils development. I'm putting patches for the current CVS as http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/src-cvs-010822.diff http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/src-cvs-010822-2add.tar.gz I'm happy if you have time to test this. > For GCC, I think that it's not ready. Major concern is the definition > of multilibbed environment. I built my own Debian gcc-sh-linux 3.0.1 > package. I'm now using this for my experiment, and try to build some > sort of Debian SH-4 distribution with this 3.0.1. While I'm doing > this week, I encountered issues of name of libgcc shared library, > still not solved. I think so. Shared libgcc of 3.x is a drastic change and is a kind of "no return". kaz |
|
From: Dustin M. <du...@se...> - 2001-08-28 03:27:23
|
There seem to be a couple operations missing in atomic.h. The following is a patch to add the 'atomic_add_and_test' and 'atomic_inc_and_test' to the asm/atomic.h header. Index: atomic.h =================================================================== RCS file: /home/CVS-ext/mgate/software/core/kernel/include/asm-sh/atomic.h,v retrieving revision 1.1.1.2 retrieving revision 1.2 diff -u -r1.1.1.2 -r1.2 --- atomic.h 2001/07/23 17:52:34 1.1.1.2 +++ atomic.h 2001/08/28 03:15:36 1.2 @@ -71,6 +71,8 @@ #define atomic_sub_and_test(i,v) (atomic_sub_return((i), (v)) == 0) #define atomic_dec_and_test(v) (atomic_sub_return(1, (v)) == 0) +#define atomic_add_and_test(i,v) (atomic_add_return((i), (v)) == 0) +#define atomic_inc_and_test(v) (atomic_add_return(1, (v)) == 0) #define atomic_inc(v) atomic_add(1,(v)) #define atomic_dec(v) atomic_sub(1,(v)) |
|
From: NIIBE Y. <gn...@m1...> - 2001-09-16 09:50:47
|
While it takes weeks to test tool-chain, I've confirmed that it is stable enough to boot-strap Debain GNU/Linux for SuperH. I've put the diff under ftp://ftp.m17n.org/pub/linux-sh/testing/ gcc-sh-linux_3.0.1-8.diff.gz binutils-sh-linux_2.11.2-1.diff.gz It's basically for Debian (includes Debian specific files), but non-Debian specific parts are applicable. Please try. I've run the testsuite of GCC native on SH-4. It's not bad. NOTE: For GCC, "make bootstrap" does not go well, it's wierd that GCC compiled for -O0 doesn't work but -O2 works well. (The result of test is based on GCC with -O2 (natively compiled)) === gcc Summary === # of expected passes 15152 # of unexpected failures 29 # of expected failures 75 # of unsupported tests 52 -------------------------- FAIL: gcc.c-torture/compile/20001226-1.c, -O1 FAIL: gcc.c-torture/compile/20001226-1.c, -O2 FAIL: gcc.c-torture/compile/20001226-1.c, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/compile/20001226-1.c, -O3 -g FAIL: gcc.c-torture/compile/20001226-1.c, -Os FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution, -Os FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution, -O3 -g FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution, -Os FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution, -O3 -g FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution, -Os -------------------------- -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-09-19 13:07:47
|
I've put my work at: ftp://ftp.m17n.org/pub/linux-sh/testing/debian-010919/ There's source tar.gz and diff.gz and result .deb(s). The total size is about 620MB. This is a kind of record to build Debian GNU/Linux on SuperH from scratch. I put the work there so that we can share the experience. My goal was build four systems (sh3, sh4, sh3eb, and sh4eb) which are able to boot strap. I mean, the system with enough develeopment environment. BTW, I've joined <deb...@li...> last week. -- |
|
From: Stuart M. <Stu...@st...> - 2001-09-19 15:44:33
|
Niibe-san I've been looking at the compiler you used to build the debian environment, and am rather confused (not that that is hard, I must admit). It appears to build the kernel using gcc 3.0.1, but then later in the build replaces it with gcc 3.0 + a massive patch to build everything else. I thought from the posting a couple of days ago 3.0.1 was now ready for use, or are there still problems? Thanks Stuart On Sep 19, 10:07pm, gn...@m1... wrote: > Subject: [linuxsh-dev] stable SH4 environment > I've put my work at: > ftp://ftp.m17n.org/pub/linux-sh/testing/debian-010919/ > > There's source tar.gz and diff.gz and result .deb(s). The total size > is about 620MB. > > This is a kind of record to build Debian GNU/Linux on SuperH from > scratch. I put the work there so that we can share the experience. > My goal was build four systems (sh3, sh4, sh3eb, and sh4eb) which are > able to boot strap. I mean, the system with enough develeopment > environment. > > BTW, I've joined <deb...@li...> last week. > -- > > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsh-dev > > >-- End of excerpt from gn...@m1... |
|
From: NIIBE Y. <gn...@m1...> - 2001-09-20 00:11:36
|
Stuart Menefy wrote: > I've been looking at the compiler you used to build the debian > environment, and am rather confused (not that that is hard, I must > admit). > > It appears to build the kernel using gcc 3.0.1, but then later in the > build replaces it with gcc 3.0 + a massive patch to build everything else. > > I thought from the posting a couple of days ago 3.0.1 was now ready > for use, or are there still problems? No problem. (It's Debian specific issue.) There's three builds of GCC in the bootstrap. (1) Initial cross GCC with static libgcc. (2) cross GCC with shared libgcc. (3) native GCC. For (1) and (2), I use my own package (gcc-sh-linux). For (3) I took the package from Debian pool and added SuperH specific patch. Yes, (3) includes massive patches which Debian guy has done, but I don't rely on them. The initial compiler #1 is replaced by compiler #2. Note that the source code base is same for #1 and #2. The difference is configure process and required library. To build #2 compiler, we need C library. To build C library, we need a compiler, that's #1 compiler. Then, (only) shared libgcc is replaced by the one of #3. Note that cross compiler is not replaced. This is needed for Debian because of package dependency. Package which depends on shared libgcc should have package dependency to the package "libgcc1", not to the cross compiler package. * * * Here's the steps I've done. Step 0: Build and install dpkg (modified to support all SuperH targets), dpkg-cross (modified to support all SuperH targets). I need the modification because it doesn't support all SuperH targets. Besides, SuperH development environment is somewhat special. GCC for sh-linux is multilibbed environment and supports all of targets, i.e., sh3-linux, sh4-linux, sh3eb-linux, and sh4eb-linux. Step 1.0: Build and install binutils-sh-linux which supports sh-linux (all of SuperH target), optionally build and install gdb-sh-linux. Ideally, we don't need those two. However, we need it for now because We have a local patches not integrated into mainline binutils and gdb We need special setting to support all of sh3-linux, sh4-linux, sh3eb-linux, and sh4eb-linux with sh-linux target. Step 1.1: Build and install initail gcc for sh-linux. As we don't have working glibc at this point, we only could build gcc with static libgcc. Step 1.2: Prepare kernel headers. Step 1.3: Build and install glibc. Step 1.4: Build and install cross compiler, gcc-sh-linux. (We need this special package for now, which shoud be integrated to standard gcc package.) Step 1.5: Build native compiler with cross compiler. We get working (shared) libgcc package in this build. Remove libgcc of 1.4, install libgcc. Step 2.0: Build and install libraries. Step 2.1: Build and install libraries (which depends 2.0). pam, procps, and readline. Step 3.0: Build basic packages. Step 3.1: Build basic packages for Debian. Step 3.2: Build development packages. Step 3.3: Build development packages for Debian. Step 3.4: Build optional packages. gdb, groff and ntp... Step 4.0: With native system, build perl. Step 5.0: With native system, build the package perl, libnet-perl, expect, and dejagnu. (Those packages cannot be build on cross environment easily.) Step 4.0 is a kind of black magic. Well, I've heard that the cross compilation is planned in 5.7 of perl. If we could cross compile perl, we can bootstrap cleanly. -- |
|
From: M. R. B. <mr...@0x...> - 2001-10-12 15:42:56
|
* NIIBE Yutaka <gn...@m1...> on Fri, Oct 12, 2001: > > The patch for GCC has been approved with name change to -mno-implicit-fp. > Is the approved patch going against HEAD or branch? I couldn't tell from the e-mail. If it's HEAD only, I still don't think it's worth it to include it in arch/sh/Makefile, you should use a conditional that checks the gcc version instead. But if it's branch, it shouldn't be a problem, since gcc 3.0.2 is right around the corner. I'm not trying to beat a dead horse here, but my point is that people can still get away with stock 3.0.1 to compile the kernel, and they shouldn't necessarily be forced to upgrade to HEAD (or 3.0.2) if it's a cosmetic change. M. R. |
|
From: NIIBE Y. <gn...@m1...> - 2001-10-13 08:25:55
|
M. R. Brown wrote: > Is the approved patch going against HEAD or branch? I couldn't tell from > the e-mail. The patch is against HEAD, but it can be applied to 3.0 branch too. I don't think it's in 3.0.2, as it is no time to be included. It will be 3.0.3, though. > I'm not trying to beat a dead horse here, but my point is that people can > still get away with stock 3.0.1 to compile the kernel, and they shouldn't > necessarily be forced to upgrade to HEAD (or 3.0.2) if it's a cosmetic > change. Stock GCC does not compile the kernel. Currently arch/sh/Makefile uses -m4-nofpu, and we need some change to define __SH4___ and undefine __sh3__ for that flag, and it's not binary compatible to -m4, as Masahiro Abe pointed out. It takes long time to solve this problem, but I have done the work. I don't know why you object the change. I agree that migrating GNU toolchain is hard thing. But eventually we have to migrate (or proceed) in some time. If you have your specific need (or customer) to stick old GNU Toolchain and old kernel, that's no problem, you yourself could have your own sets of toolchain and some small patch to the kernel. Less is the better, you know, but it's not _zero_ in this real world. Everyone has that, and cooperate to minimize the diffusion. -- |
|
From: Bryan R. <br...@ix...> - 2001-11-13 04:32:46
|
Hello NIIBE-san,
Please merge the following patch with your
gcc-sh-linux_3.0.1-12.diff.gz:
--- gcc-sh-linux-3.0.1/debian/rules-orig Mon Nov 12 20:15:49 2001
+++ gcc-sh-linux-3.0.1/debian/rules Mon Nov 12 20:16:02 2001
@@ -45,7 +45,9 @@
--disable-nls \
--with-gxx-include-dir=\$${prefix}/$(@:build-%=%)/include/g++-v3 \
--with-system-zlib \
- --with-headers=/usr/$(@:build-%=%)/include
+ --with-headers=/usr/$(@:build-%=%)/include \
+ --enable-threads=posix \
+ --enable-long-long
$(MAKE) -C $(@:build-%=%) all-gcc all-target-libstdc++-v3
all-target-libobjc
touch $@
explanation:
--enable-long-long turns on some long long features in libstdc++
--enable-threads=posix enables thread-safe C++ exception handling
both are used in debian's i386 gcc-3.0 package:
Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.2/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,proto,objc --prefix=/usr
--infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as
--with-gnu-ld --with-system-zlib --enable-long-long --enable-nls
--without-included-gettext --disable-checking --enable-threads=posix
--enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc
i386-linux
Thread model: posix
gcc version 3.0.2 20010922 (Debian prerelease)
I think my patch improves C++ support in gcc-sh4, and
makes it behave more like gcc-3.0 on i386...
Regards,
-Bryan
NIIBE Yutaka wrote:
> It's kitchen sink (all is included) patch for Debian. I don't have
> time to explain each pieces. For that, please see gcc-patches mailing
> list archive.
--
Bryan Rittmeyer
mailto:br...@ix...
|
|
From: NIIBE Y. <gn...@m1...> - 2001-11-13 11:27:45
|
Bryan Rittmeyer wrote: > Please merge the following patch with your > gcc-sh-linux_3.0.1-12.diff.gz: Thanks. Will do for 3.0.2. > I think my patch improves C++ support in gcc-sh4, and > makes it behave more like gcc-3.0 on i386... Actually, I don't use the result of libstdc++.so (or a) with this package. I used the one generated when building native compiler. Anyway, that's good to have consistent configuration. -- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X