Re: How about gcj? (Re: Not committing WARNS settings...)
Mikhail Teterin wrote: > That's the thing. gcc30 port, essentially, installs a copy of the > compiler already available as part of the base. But the base is missing > gcj (the port does too for now), so one would be forced to add the port. Compilers from ports suck. If you set DESTDIR, it screws up your header and include patch for C++, and you get the old headers and libraries, so things like RTTI break. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: >> http://www.gnu.org/manual/bfd-2.9.1/ >> >> for example, seems to imply, that there was, in fact, at some point a >> release 2.9.1 of bfd... It does not quite match the bfd, > No, that document describes the BFD that was included with Binutils > 2.9.1. If you looked at another tree of documents you would also think > that bfd was at version 5.1.1 (ie, the latest GDB). > What part about two of us telling you that there are no released > versions (ie, of bfd or libiberty as a unique, separate package) > aren't you believing? I know the GNU toolchain, its development, > release cycle, and packaging VERY well. I believe, what I see. And that is, FreeBSD includes both -- gdb and gcc, but only one libbfd, thankfully. And I want to be able to use that same libbfd for my own development and for porting of other compilers and tools. This IS the problem I'm trying to solve. > WHY do you want to cause this problem of non-matching bits? So they'll be matched and fixed, leading to a better world 8-) > This is my last email you on this topic, as you've yet to answer the > question of what problem you are trying to solve! See above. >> Plenty of packages come bundled with the third-party software, and a >> good port makes them build with the already installed versions of >> such software (like zlib, OpenSSL) or with the version available from >> another port (like c-client). > Well the GNU bits do not do that. If you report a GDB bug and they > find out you weren't using the BFD or Libiberty included with GDB, the > bug report would probably be dropped on the floor. Evidently, this does not prevent the FreeBSD project from using the same libbfd for its gdb and gcc. Even though, the presense of both /usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a and /usr/obj/usr/src/i386/ccd/src/gnu/usr.bin/binutils/libbfd/libbfd.a is somewhat mistifying to me, but I'm sure they are built from the same source. > No I want to drop Alpha because no one cares about it and not just the > compiler, but much more often kernel, WARNS, and other changes break > the Alpha. Alright, so you do find it nightmarish. But we still support Alpha, for whatever reason. This means, that the simple "it would be a nightmare" is not an argument. "It is not worth the trouble" -- would be, and I'm arguing, that it is not true in this case. >> > HOW will it help to add software? What is so wrong with compiling >> > the bundled libiberty or bfd that comes with each of the "new >> > software" when building them? What is so wrong with having >> > libiberty or bfd statically linked into the "new software"? >> It is _inelegant_ and is inconsistent with our use of shared >> libraries for most of the rest of the system. Look, we wanted ssh and >> we added it. > Go find a REAL problem to solve than something that you don't like the > esthetics of. This is a REAL problem. "Your theorem is ugly, so it must be incorrect." (Some famous mathematician) >> > I frankly just don't see what "problem" it is you are trying to solve. >> >> I want libbfd (and libiberty) to be installed as part of the OS. >> Preferably -- in both, static and dynamic fashions, consistent with >> the rest of the libraries. > > That is NOT a problem. That is just some mis-founded goal with no > basis of purpose. Well, than nothing is a problem. Which problem is FreeBSD's very existence trying to solve, huh? Why don't we all go and "get a life", instead of spending hours in front of the computers? Please... >> Because FreeBSD's base source already includes the libbfd source and >> builds the library during build. It just does not install it, for >> some reason. If all targets are enabled, this cross-toolchain ports >> would not even need their own versions of this libraries, most >> likely... > FEH!! You are going to patch the nightmare (yes I will use that term > to describe this) autoconf and autoMake bits that come with the GNU > tools? Good luck! In general with GNU tools, JUST LEAVE THINGS THE WAY > THE ORIGINAL AUTHOR INTENDED THEM TO BE. Yes, I very well might. Or, may be, I'll introduce Makefiles of my own -- Something already done for the C compiler and all the other GNU tools in the base, BTW. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: > On Wed, Feb 06, 2002 at 03:46:22PM -0500, Mikhail Teterin wrote: >> > dynamically linked libiberty would be a nightmare. >> >> > libbfd and libiberty do not have version numbers, are not >> > maintained (i.e. there is no official releases). every project >> > includes its own libiberty and imho an attempt to find least common >> > denominator will fail >> >> Well, they come to FreeBSD as part of the binutils, right? > > NO! Is that a "NO!" as in "no, it does not come as part of the binutils", or is that a "NO!" as in "I'M NOT GOING TO AGREE WITH ANYTHING YOU SAY?" > Max told you what a nightmare it would be. He is 110% right. Max only objected to using dynamic versions of this two libraries, BTW. > PLEASE take some advice from two people that are experienced in the > issues. I'd like to take any advice, but it has to be founded. Plenty of pieces of the FreeBSD project are "a nightmare" -- including the binutils, and the compilers, and the whole Alpha port, to name a few -- if the postings to this mailing lists (including those from you) are any indication. Yet, we (including you) do them anyway, because they are worth it (for whatever reasons). I'm trying to persuade the audience, that installing the libbfd and libiberty (which we build anyway!) into /usr/lib is also worth the trouble, because it will help add new software through the ports system -- like the gcj-compiler, or different versions of GCC, etc. (With all available targets enabled, preferably.) I mean, I can add arm-aout or arm-elf binutils to the system through the devel ports, or mingw -- all with their own libbfd, but I don't have access to the native version, which is built as part of the base OS, just never installed? Is not this a bit ridiculous? -mi P.S. NetBSD installs shared libbfd: http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/gnu/lib/libbfd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: > Yes it comes as part of binutils. Ok. > No we should not go down this path. You've already been told that > there is no official libiberty or bfd release. Well, the following URL http://www.gnu.org/manual/bfd-2.9.1/ for example, seems to imply, that there was, in fact, at some point a release 2.9.1 of bfd... It does not quite match the bfd, that's part of -current -- because of your work on bringing the binutils-3.x in. So there is _something_... > Every software package that needs either comes with its own copy -- > that always has bug fixes or minor changes from all the other copies > out there. Well, that would be a porter's job to figure out which changes the package relies on, or which it simply did not bother to sync with the bfd, that comes with binutils. Plenty of packages come bundled with the third-party software, and a good port makes them build with the already installed versions of such software (like zlib, OpenSSL) or with the version available from another port (like c-client). >> I'd like to take any advice, but it has to be founded. Plenty of >> pieces of the FreeBSD project are "a nightmare" -- including the >> binutils, > > Why is binutils a nightmare?? I don't find it to be one. You edited out the rest from my list of examples. Ok. You did want to drop Alpha, because supporting the compiler on it seemed too difficult at some point -- how is that for an example? Or do you claim the proposed addition is the most nightmarish of them all? > HOW will it help to add software? What is so wrong with compiling the > bundled libiberty or bfd that comes with each of the "new software" > when building them? What is so wrong with having libiberty or bfd > statically linked into the "new software"? It is _inelegant_ and is inconsistent with our use of shared libraries for most of the rest of the system. Look, we wanted ssh and we added it. It requires OpenSSL and we added it. Do we link OpenSSL staticly into ssh and/or not install -lssl into /usr/lib? > I frankly just don't see what "problem" it is you are trying to solve. I want libbfd (and libiberty) to be installed as part of the OS. Preferably -- in both, static and dynamic fashions, consistent with the rest of the libraries. >> I mean, I can add arm-aout or arm-elf binutils to the system through >> the devel ports, or mingw -- all with their own libbfd, but I don't >> have access to the native version, which is built as part of the base >> OS, just never installed? Is not this a bit ridiculous? > Why is it ridiculous? Because FreeBSD's base source already includes the libbfd source and builds the library during build. It just does not install it, for some reason. If all targets are enabled, this cross-toolchain ports would not even need their own versions of this libraries, most likely... > Personally I don't think a cross-toolchain build should be installing > those bits. And in my opinion, they should not even be building those bits for themselves. I mean, I would've come up with a port of this libraries, but it just seems silly to port something, that's already in the base system. >> P.S. NetBSD installs shared libbfd: >> >http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/gnu/lib/libbfd/ > > Of the two -- bfd and libiberty, bfd is the one we would have the most > success at installing as a shared lib in /usr/lib. Alright! One step at a time... I understand, that this is an additional burden for you as Mr. Binutils, but let's admit, this might be useful and move it from "NO!" to "May be, some day, when someone does the work." Yours, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: > On Wed, Feb 06, 2002 at 01:05:16PM -0500, Mikhail Teterin wrote: >> > Uh, NO! It is not needed by the base system. We really do not want >> > to turn on all the support libs, etc.. that would be needed with >> > this. There is a reason the gcc30 port takes 25 minutes to compile >> > on a fast 1.2 GHz Athlon. >> >> That's the thing. gcc30 port, essentially, installs a copy of the >> compiler already available as part of the base. > > No it doesn't. 3.0.3 is a very different compiler from 2.95.3. I thought we are moving to gcc-3.x quickly :-) But the other ports, such as lang/gcc295 don't complement the base system either -- they install a full new set under LOCALBASE, instead of just the missing pieces (like gcj). >> But the base is missing gcj (the port does too for now), so one would >> be forced to add the port. > > And the base system does not NEED a java compiler. Alright. But a FreeBSD installation -- might. >> Can we have those [libbfd and libiberty] installed, at least, to ease >> the work of the future porter? > > Nope. That's too brief for a mutually respectful conversation :-\ I know it is your "style", but do not accept this answer anyway. All I'm talking about, is that having a functional gcj _available_ on FreeBSD is a good thing. Through the ports collection or as part of the base system. The fact, that nothing in the base requires Java is hardly an argument in itself. Nothing requires Fortran, or the dictionary, or the cal(1) either. But alright, let's say -- ports. gcj and gcjh themselves are installed by the several lang/gcc* ports, but they are not functional (libgcj/libjava are not ported). As a ports committer I might try to fix that, but I think, those ports should complement the base system, and that the base system should provide the bits it already uses itself (like libbfd and libiberty) to the programmers, that use FreeBSD -- install them into /usr/lib and link them _dynamicly_ into the tools. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 07:29:57PM +0100, Wilko Bulte wrote: > - is GCC3 also better on Alpha as far as correctness of the generated > code goes? Or is that what you mean by "bad optimised code" ? We shall see. > - The gcc 2.95 compiler is quite a bit slower (it appears) on Alpha than > on x86. Do you have any idea how gcc3 does in this respect? 3.1 will also be slower on the Alpha. It is really an issue of the code generator. Generating x86 code on an Alpha is faster than generating [native] Alpha code. The Alpha code generator is slow. It may be that all 64 bit or RISC GCC code generation is slow -- we will see soon for the sparc64. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
David O'Brien wrote: > 3.1 will also be slower on the Alpha. It is really an issue of the code > generator. Generating x86 code on an Alpha is faster than generating > [native] Alpha code. The Alpha code generator is slow. It may be that > all 64 bit or RISC GCC code generation is slow -- we will see soon for > the sparc64. I don't think this is definative. I think the problem is that the GCC code for the code generation on these platforms is not beaten on very heavily by people who care about it. We see the same effect in FreeBSD from time to time, when the Alpha build is broken for one reason or another by a supposedly platform independent change which is really an x86-ism. I suspect code generation for these platforms will be slow, but that code generation for the 64 bit Intel and AMD processors will be a lot faster. The Alpha stuff is also hampered by the instruction reordering, which is another pass, but that doesn't fully account for the slowness of the code (IMO). Probably, it could be made much faster by someone who cared about it, and who has a profile in hand. Personally, I was happy with my 1 MHz 6502, so as far as I see it, everything runs blazingly fast, even though modern programmers fail on cycle squezing by multiple orders of magnitude most times. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 12:39:35AM -0500, Mikhail Teterin wrote: > I believe, what I see. And that is, FreeBSD includes both -- gdb and > gcc, but only one libbfd, thankfully. And I want to be able to use that > same libbfd for my own development and for porting of other compilers > and tools. GCC does not use bfd -- it does not need to as GCC spits out ASM code, not machine code. Arguing that Binutils and GDB uses the same bfd is a more valid argument. I would like to point out there have been some minor issues with using the bfd from Binutils 2.11.2 with the old GDB 4.x. GCC and GDB does both use libiberty. You will notice that GCC uses its own copy (the files are piled into the src/contrib/gcc directory with the rest of the GCC code). And GDB uses a different copy. > This IS the problem I'm trying to solve. > > > WHY do you want to cause this problem of non-matching bits? > > So they'll be matched and fixed, leading to a better world 8-) I don't know how many times I've said this and why you aren't listening. THEY CANNOT BE MATCHED. Go ask the FSF developers. They will tell you the same thing -- that is why each package's CVS repo maintains its own copy. The FSF developers will tell you using the copy of libiberty is NOT SUPPORTED by them. > Evidently, this does not prevent the FreeBSD project from using the same > libbfd for its gdb and gcc. Even though, the presense of both Again, see above. This is how little you know of the "problem". GCC DOES NOT USE ANY BFD CODE. > /usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a > and > /usr/obj/usr/src/i386/ccd/src/gnu/usr.bin/binutils/libbfd/libbfd.a > > is somewhat mistifying to me, but I'm sure they are built from the same > source. *SIGH* This also shows how little you know of the "make buildworld" process. Before you start suggesting the things you have, you really need to start treating ``make buildworld'' as something other than a black box. ``make buildworld'' compiles two copies of some things because of bootstrapping [and cross compiling] issues. > > No I want to drop Alpha because no one cares about it and not just the > > compiler, but much more often kernel, WARNS, and other changes break > > the Alpha. > > Alright, so you do find it nightmarish. *sigh* NO! Stop putting words in my mouth. I find it extremely ANNOYING. nightmarish != annoying > > That is NOT a problem. That is just some mis-founded goal with no > > basis of purpose. > > Well, than nothing is a problem. Which problem is FreeBSD's very > existence trying to solve, huh? Sure some things are a problem. GCC 2.95 generates bad optimized code on the Alpha. Upgrading to 3.1 will fix [some of] this. We cannot do a "make buildworld" of -CURRENT code on a 4.1 system because of our addition of __FBSDID(). We cannot support > 4 GB RAM in any machine (Peter Wemm is working on this); and people need to be able to. Those are real problems. > > FEH!! You are going to patch the nightmare (yes I will use that term > > to describe this) autoconf and autoMake bits that come with the GNU > > tools? Good luck! In general with GNU tools, JUST LEAVE THINGS THE WAY > > THE ORIGINAL AUTHOR INTENDED THEM TO BE. > > Yes, I very well might. Or, may be, I'll introduce Makefiles of my own > -- Something already done for the C compiler and all the other GNU tools > in the base, BTW. Submit tested patches and we'll talk farther. But I've seen you have only thought about this off the top of your head with no investigation into the issues. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Wed, Feb 06, 2002 at 01:05:16PM -0500, Mikhail Teterin wrote: > > Uh, NO! It is not needed by the base system. We really do not want to > > turn on all the support libs, etc.. that would be needed with this. > > There is a reason the gcc30 port takes 25 minutes to compile on a fast > > 1.2 GHz Athlon. > > That's the thing. gcc30 port, essentially, installs a copy of the > compiler already available as part of the base. No it doesn't. 3.0.3 is a very different compiler from 2.95.3. > But the base is missing > gcj (the port does too for now), so one would be forced to add the port. And the base system does not NEED a java compiler. > Can we have those installed, at least, to ease the work of the future > porter? Nope. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 10:35:41AM -0800, David O'Brien wrote: > On Thu, Feb 07, 2002 at 07:29:57PM +0100, Wilko Bulte wrote: > > - is GCC3 also better on Alpha as far as correctness of the generated > > code goes? Or is that what you mean by "bad optimised code" ? > > We shall see. OK. 8-) > > - The gcc 2.95 compiler is quite a bit slower (it appears) on Alpha than > > on x86. Do you have any idea how gcc3 does in this respect? > > 3.1 will also be slower on the Alpha. It is really an issue of the code > generator. Generating x86 code on an Alpha is faster than generating > [native] Alpha code. The Alpha code generator is slow. It may be that > all 64 bit or RISC GCC code generation is slow -- we will see soon for > the sparc64. Thanks. So it is the code generator itself, I always thought it would be the optimiser that needs more time to do a decent job on a RISC. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
David O'Brien wrote: > 3.1 will also be slower on the Alpha. It is really an issue of the code > generator. Generating x86 code on an Alpha is faster than generating > [native] Alpha code. The Alpha code generator is slow. It may be that > all 64 bit or RISC GCC code generation is slow -- we will see soon for > the sparc64. I don't think this is definative. I think the problem is that the GCC code for the code generation on these platforms is not beaten on very heavily by people who care about it. We see the same effect in FreeBSD from time to time, when the Alpha build is broken for one reason or another by a supposedly platform independent change which is really an x86-ism. I suspect code generation for these platforms will be slow, but that code generation for the 64 bit Intel and AMD processors will be a lot faster. The Alpha stuff is also hampered by the instruction reordering, which is another pass, but that doesn't fully account for the slowness of the code (IMO). Probably, it could be made much faster by someone who cared about it, and who has a profile in hand. Personally, I was happy with my 1 MHz 6502, so as far as I see it, everything runs blazingly fast, even though modern programmers fail on cycle squezing by multiple orders of magnitude most times. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
David O'Brien writes: Thank you, David, for taking the time to answer the questions. Your answers were clear. I appreciate you taking the time to provide these answers. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 07:39:36PM +0100, Wilko Bulte wrote: > > 3.1 will also be slower on the Alpha. It is really an issue of the code > > generator. Generating x86 code on an Alpha is faster than generating > > [native] Alpha code. The Alpha code generator is slow. It may be that > > all 64 bit or RISC GCC code generation is slow -- we will see soon for > > the sparc64. > > Thanks. So it is the code generator itself, I always thought it would be > the optimiser that needs more time to do a decent job on a RISC. I lumped those two together. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 10:35:41AM -0800, David O'Brien wrote: > On Thu, Feb 07, 2002 at 07:29:57PM +0100, Wilko Bulte wrote: > > - is GCC3 also better on Alpha as far as correctness of the generated > > code goes? Or is that what you mean by "bad optimised code" ? > > We shall see. OK. 8-) > > - The gcc 2.95 compiler is quite a bit slower (it appears) on Alpha than > > on x86. Do you have any idea how gcc3 does in this respect? > > 3.1 will also be slower on the Alpha. It is really an issue of the code > generator. Generating x86 code on an Alpha is faster than generating > [native] Alpha code. The Alpha code generator is slow. It may be that > all 64 bit or RISC GCC code generation is slow -- we will see soon for > the sparc64. Thanks. So it is the code generator itself, I always thought it would be the optimiser that needs more time to do a decent job on a RISC. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 07:29:57PM +0100, Wilko Bulte wrote: > - is GCC3 also better on Alpha as far as correctness of the generated > code goes? Or is that what you mean by "bad optimised code" ? We shall see. > - The gcc 2.95 compiler is quite a bit slower (it appears) on Alpha than > on x86. Do you have any idea how gcc3 does in this respect? 3.1 will also be slower on the Alpha. It is really an issue of the code generator. Generating x86 code on an Alpha is faster than generating [native] Alpha code. The Alpha code generator is slow. It may be that all 64 bit or RISC GCC code generation is slow -- we will see soon for the sparc64. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 10:11:33AM -0800, David O'Brien wrote: > On Thu, Feb 07, 2002 at 12:39:35AM -0500, Mikhail Teterin wrote: > > I believe, what I see. And that is, FreeBSD includes both -- gdb and > > gcc, but only one libbfd, thankfully. And I want to be able to use that > > same libbfd for my own development and for porting of other compilers > > and tools. ... > Sure some things are a problem. GCC 2.95 generates bad optimized code on > the Alpha. Upgrading to 3.1 will fix [some of] this. We cannot do a To satisfy a bit of my curiosity: - is GCC3 also better on Alpha as far as correctness of the generated code goes? Or is that what you mean by "bad optimised code" ? - The gcc 2.95 compiler is quite a bit slower (it appears) on Alpha than on x86. Do you have any idea how gcc3 does in this respect? Thanks! Wilko -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 12:39:35AM -0500, Mikhail Teterin wrote: > I believe, what I see. And that is, FreeBSD includes both -- gdb and > gcc, but only one libbfd, thankfully. And I want to be able to use that > same libbfd for my own development and for porting of other compilers > and tools. GCC does not use bfd -- it does not need to as GCC spits out ASM code, not machine code. Arguing that Binutils and GDB uses the same bfd is a more valid argument. I would like to point out there have been some minor issues with using the bfd from Binutils 2.11.2 with the old GDB 4.x. GCC and GDB does both use libiberty. You will notice that GCC uses its own copy (the files are piled into the src/contrib/gcc directory with the rest of the GCC code). And GDB uses a different copy. > This IS the problem I'm trying to solve. > > > WHY do you want to cause this problem of non-matching bits? > > So they'll be matched and fixed, leading to a better world 8-) I don't know how many times I've said this and why you aren't listening. THEY CANNOT BE MATCHED. Go ask the FSF developers. They will tell you the same thing -- that is why each package's CVS repo maintains its own copy. The FSF developers will tell you using the copy of libiberty is NOT SUPPORTED by them. > Evidently, this does not prevent the FreeBSD project from using the same > libbfd for its gdb and gcc. Even though, the presense of both Again, see above. This is how little you know of the "problem". GCC DOES NOT USE ANY BFD CODE. > /usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a > and > /usr/obj/usr/src/i386/ccd/src/gnu/usr.bin/binutils/libbfd/libbfd.a > > is somewhat mistifying to me, but I'm sure they are built from the same > source. *SIGH* This also shows how little you know of the "make buildworld" process. Before you start suggesting the things you have, you really need to start treating ``make buildworld'' as something other than a black box. ``make buildworld'' compiles two copies of some things because of bootstrapping [and cross compiling] issues. > > No I want to drop Alpha because no one cares about it and not just the > > compiler, but much more often kernel, WARNS, and other changes break > > the Alpha. > > Alright, so you do find it nightmarish. *sigh* NO! Stop putting words in my mouth. I find it extremely ANNOYING. nightmarish != annoying > > That is NOT a problem. That is just some mis-founded goal with no > > basis of purpose. > > Well, than nothing is a problem. Which problem is FreeBSD's very > existence trying to solve, huh? Sure some things are a problem. GCC 2.95 generates bad optimized code on the Alpha. Upgrading to 3.1 will fix [some of] this. We cannot do a "make buildworld" of -CURRENT code on a 4.1 system because of our addition of __FBSDID(). We cannot support > 4 GB RAM in any machine (Peter Wemm is working on this); and people need to be able to. Those are real problems. > > FEH!! You are going to patch the nightmare (yes I will use that term > > to describe this) autoconf and autoMake bits that come with the GNU > > tools? Good luck! In general with GNU tools, JUST LEAVE THINGS THE WAY > > THE ORIGINAL AUTHOR INTENDED THEM TO BE. > > Yes, I very well might. Or, may be, I'll introduce Makefiles of my own > -- Something already done for the C compiler and all the other GNU tools > in the base, BTW. Submit tested patches and we'll talk farther. But I've seen you have only thought about this off the top of your head with no investigation into the issues. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: >> http://www.gnu.org/manual/bfd-2.9.1/ >> >> for example, seems to imply, that there was, in fact, at some point a >> release 2.9.1 of bfd... It does not quite match the bfd, > No, that document describes the BFD that was included with Binutils > 2.9.1. If you looked at another tree of documents you would also think > that bfd was at version 5.1.1 (ie, the latest GDB). > What part about two of us telling you that there are no released > versions (ie, of bfd or libiberty as a unique, separate package) > aren't you believing? I know the GNU toolchain, its development, > release cycle, and packaging VERY well. I believe, what I see. And that is, FreeBSD includes both -- gdb and gcc, but only one libbfd, thankfully. And I want to be able to use that same libbfd for my own development and for porting of other compilers and tools. This IS the problem I'm trying to solve. > WHY do you want to cause this problem of non-matching bits? So they'll be matched and fixed, leading to a better world 8-) > This is my last email you on this topic, as you've yet to answer the > question of what problem you are trying to solve! See above. >> Plenty of packages come bundled with the third-party software, and a >> good port makes them build with the already installed versions of >> such software (like zlib, OpenSSL) or with the version available from >> another port (like c-client). > Well the GNU bits do not do that. If you report a GDB bug and they > find out you weren't using the BFD or Libiberty included with GDB, the > bug report would probably be dropped on the floor. Evidently, this does not prevent the FreeBSD project from using the same libbfd for its gdb and gcc. Even though, the presense of both /usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a and /usr/obj/usr/src/i386/ccd/src/gnu/usr.bin/binutils/libbfd/libbfd.a is somewhat mistifying to me, but I'm sure they are built from the same source. > No I want to drop Alpha because no one cares about it and not just the > compiler, but much more often kernel, WARNS, and other changes break > the Alpha. Alright, so you do find it nightmarish. But we still support Alpha, for whatever reason. This means, that the simple "it would be a nightmare" is not an argument. "It is not worth the trouble" -- would be, and I'm arguing, that it is not true in this case. >> > HOW will it help to add software? What is so wrong with compiling >> > the bundled libiberty or bfd that comes with each of the "new >> > software" when building them? What is so wrong with having >> > libiberty or bfd statically linked into the "new software"? >> It is _inelegant_ and is inconsistent with our use of shared >> libraries for most of the rest of the system. Look, we wanted ssh and >> we added it. > Go find a REAL problem to solve than something that you don't like the > esthetics of. This is a REAL problem. "Your theorem is ugly, so it must be incorrect." (Some famous mathematician) >> > I frankly just don't see what "problem" it is you are trying to solve. >> >> I want libbfd (and libiberty) to be installed as part of the OS. >> Preferably -- in both, static and dynamic fashions, consistent with >> the rest of the libraries. > > That is NOT a problem. That is just some mis-founded goal with no > basis of purpose. Well, than nothing is a problem. Which problem is FreeBSD's very existence trying to solve, huh? Why don't we all go and "get a life", instead of spending hours in front of the computers? Please... >> Because FreeBSD's base source already includes the libbfd source and >> builds the library during build. It just does not install it, for >> some reason. If all targets are enabled, this cross-toolchain ports >> would not even need their own versions of this libraries, most >> likely... > FEH!! You are going to patch the nightmare (yes I will use that term > to describe this) autoconf and autoMake bits that come with the GNU > tools? Good luck! In general with GNU tools, JUST LEAVE THINGS THE WAY > THE ORIGINAL AUTHOR INTENDED THEM TO BE. Yes, I very well might. Or, may be, I'll introduce Makefiles of my own -- Something already done for the C compiler and all the other GNU tools in the base, BTW. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Wed, Feb 06, 2002 at 08:38:02PM -0500, Mikhail Teterin wrote: > On 6 Feb, David O'Brien wrote: > > Yes it comes as part of binutils. > > Ok. > > > No we should not go down this path. You've already been told that > > there is no official libiberty or bfd release. > > Well, the following URL > > http://www.gnu.org/manual/bfd-2.9.1/ > > for example, seems to imply, that there was, in fact, at some point a > release 2.9.1 of bfd... It does not quite match the bfd, No, that document describes the BFD that was included with Binutils 2.9.1. If you looked at another tree of documents you would also think that bfd was at version 5.1.1 (ie, the latest GDB). What part about two of us telling you that there are no released versions (ie, of bfd or libiberty as a unique, separate package) aren't you believing? I know the GNU toolchain, its development, release cycle, and packaging VERY well. > > Every software package that needs either comes with its own copy -- > > that always has bug fixes or minor changes from all the other copies > > out there. > > Well, that would be a porter's job to figure out which changes the > package relies on, or which it simply did not bother to sync with the > bfd, that comes with binutils. WHY do you want to cause this problem of non-matching bits? This is my last email you on this topic, as you've yet to answer the question of what problem you are trying to solve! > Plenty of packages come bundled with the > third-party software, and a good port makes them build with the already > installed versions of such software (like zlib, OpenSSL) or with the > version available from another port (like c-client). Well the GNU bits do not do that. If you report a GDB but and they find out you weren't using the BFD or Libiberty included with GDB, the bug report would probably be dropped on the floor. The testing cycles that Binutils and GDB goes thru, uses the version that was branched with that piece of software. Go run diffs over these packages from Binutlis 2.11.2 and GDB 5.1.1 and see the differences. Now go diff those libiberty's with the one in GCC 2.95.3. > > Why is binutils a nightmare?? I don't find it to be one. > > You edited out the rest from my list of examples. Ok. You did want to > drop Alpha, because supporting the compiler on it seemed too difficult > at some point -- how is that for an example? Or do you claim the > proposed addition is the most nightmarish of them all? No I want to drop Alpha because no one cares about it and not just the compiler, but much more often kernel, WARNS, and other changes break the Alpha. > > HOW will it help to add software? What is so wrong with compiling the > > bundled libiberty or bfd that comes with each of the "new software" > > when building them? What is so wrong with having libiberty or bfd > > statically linked into the "new software"? > > It is _inelegant_ and is inconsistent with our use of shared libraries > for most of the rest of the system. Look, we wanted ssh and we added it. Oh crist! Go find a REAL problem to solve than something that you don't like the esthetics of. > > I frankly just don't see what "problem" it is you are trying to solve. > > I want libbfd (and libiberty) to be installed as part of the OS. > Preferably -- in both, static and dynamic fashions, consistent with the > rest of the libraries. That is NOT a problem. That is just some mis-founded goal with no basis of purpose. > Because FreeBSD's base source already includes the libbfd source and > builds the library during build. It just does not install it, for some > reason. If all targets are enabled, this cross-toolchain ports would not > even need their own versions of this libraries, most likely... FEH!! You are going to patch the nightmare (yes I will use that term to describe this) autoconf and autoMake bits that come with the GNU tools? Good luck! In general with GNU tools, JUST LEAVE THINGS THE WAY THE ORIGINAL AUTHOR INTENDED THEM TO BE. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
David O'Brien wrote: > Why is binutils a nightmare?? Bad engineering? 8-) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
Mikhail Teterin wrote: > > And the base system does not NEED a java compiler. > > Alright. But a FreeBSD installation -- might. This bears on the fundamental problem of using the install tools that come with external source code in order to do installs. Probably, it should be built by a make world, but not installed by a make installworld, so that the install was optional. In the binary installation case, it should probably be a package, instead of part of one big lump, and it should be seperately installable. Per my previous posting: compilers not installed over top of the system compilers screw up in a number of ways due to .mk file bugs. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
David O'Brien wrote: > > But the base is missing > > gcj (the port does too for now), so one would be forced to add the port. > > And the base system does not NEED a java compiler. Or perl. 8-) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
Mikhail Teterin wrote: > That's the thing. gcc30 port, essentially, installs a copy of the > compiler already available as part of the base. But the base is missing > gcj (the port does too for now), so one would be forced to add the port. Compilers from ports suck. If you set DESTDIR, it screws up your header and include patch for C++, and you get the old headers and libraries, so things like RTTI break. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: > Yes it comes as part of binutils. Ok. > No we should not go down this path. You've already been told that > there is no official libiberty or bfd release. Well, the following URL http://www.gnu.org/manual/bfd-2.9.1/ for example, seems to imply, that there was, in fact, at some point a release 2.9.1 of bfd... It does not quite match the bfd, that's part of -current -- because of your work on bringing the binutils-3.x in. So there is _something_... > Every software package that needs either comes with its own copy -- > that always has bug fixes or minor changes from all the other copies > out there. Well, that would be a porter's job to figure out which changes the package relies on, or which it simply did not bother to sync with the bfd, that comes with binutils. Plenty of packages come bundled with the third-party software, and a good port makes them build with the already installed versions of such software (like zlib, OpenSSL) or with the version available from another port (like c-client). >> I'd like to take any advice, but it has to be founded. Plenty of >> pieces of the FreeBSD project are "a nightmare" -- including the >> binutils, > > Why is binutils a nightmare?? I don't find it to be one. You edited out the rest from my list of examples. Ok. You did want to drop Alpha, because supporting the compiler on it seemed too difficult at some point -- how is that for an example? Or do you claim the proposed addition is the most nightmarish of them all? > HOW will it help to add software? What is so wrong with compiling the > bundled libiberty or bfd that comes with each of the "new software" > when building them? What is so wrong with having libiberty or bfd > statically linked into the "new software"? It is _inelegant_ and is inconsistent with our use of shared libraries for most of the rest of the system. Look, we wanted ssh and we added it. It requires OpenSSL and we added it. Do we link OpenSSL staticly into ssh and/or not install -lssl into /usr/lib? > I frankly just don't see what "problem" it is you are trying to solve. I want libbfd (and libiberty) to be installed as part of the OS. Preferably -- in both, static and dynamic fashions, consistent with the rest of the libraries. >> I mean, I can add arm-aout or arm-elf binutils to the system through >> the devel ports, or mingw -- all with their own libbfd, but I don't >> have access to the native version, which is built as part of the base >> OS, just never installed? Is not this a bit ridiculous? > Why is it ridiculous? Because FreeBSD's base source already includes the libbfd source and builds the library during build. It just does not install it, for some reason. If all targets are enabled, this cross-toolchain ports would not even need their own versions of this libraries, most likely... > Personally I don't think a cross-toolchain build should be installing > those bits. And in my opinion, they should not even be building those bits for themselves. I mean, I would've come up with a port of this libraries, but it just seems silly to port something, that's already in the base system. >> P.S. NetBSD installs shared libbfd: >> >http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/gnu/lib/libbfd/ > > Of the two -- bfd and libiberty, bfd is the one we would have the most > success at installing as a shared lib in /usr/lib. Alright! One step at a time... I understand, that this is an additional burden for you as Mr. Binutils, but let's admit, this might be useful and move it from "NO!" to "May be, some day, when someone does the work." Yours, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Wed, Feb 06, 2002 at 07:53:42PM -0500, Mikhail Teterin wrote: > On 6 Feb, David O'Brien wrote: > > On Wed, Feb 06, 2002 at 03:46:22PM -0500, Mikhail Teterin wrote: > >> > dynamically linked libiberty would be a nightmare. > >> > >> > libbfd and libiberty do not have version numbers, are not > >> > maintained (i.e. there is no official releases). every project > >> > includes its own libiberty and imho an attempt to find least common > >> > denominator will fail > >> > >> Well, they come to FreeBSD as part of the binutils, right? > > > > NO! > > Is that a "NO!" as in "no, it does not come as part of the binutils", or Yes it comes as part of binutils. > is that a "NO!" as in "I'M NOT GOING TO AGREE WITH ANYTHING YOU SAY?" No we should not go down this path. You've already been told that there is no official libiberty or bfd release. Every software package that needs either comes with its own copy -- that always has bug fixes or minor changes from all the other copies out there. > I'd like to take any advice, but it has to be founded. Plenty of pieces > of the FreeBSD project are "a nightmare" -- including the binutils, Why is binutils a nightmare?? I don't find it to be one. > I'm trying to persuade the audience, that installing the libbfd and > libiberty (which we build anyway!) into /usr/lib is also worth the > trouble, because it will help add new software through the ports system > -- like the gcj-compiler, or different versions of GCC, etc. (With all > available targets enabled, preferably.) HOW will it help to add software? What is so wrong with compiling the bundled libiberty or bfd that comes with each of the "new software" when building them? What is so wrong with having libiberty or bfd statically linked into the "new software"? I frankly just don't see what "problem" it is you are trying to solve. > I mean, I can add arm-aout or arm-elf binutils to the system through the > devel ports, or mingw -- all with their own libbfd, but I don't have > access to the native version, which is built as part of the base OS, > just never installed? Is not this a bit ridiculous? Why is it ridiculous? Personally I don't think a cross-toolchain build should be installing those bits. But the GNU developers did not ask me for my opinion. > -mi > > P.S. NetBSD installs shared libbfd: > >http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/gnu/lib/libbfd/ Of the two -- bfd and libiberty, bfd is the one we would have the most success at installing as a shared lib in /usr/lib. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: > On Wed, Feb 06, 2002 at 03:46:22PM -0500, Mikhail Teterin wrote: >> > dynamically linked libiberty would be a nightmare. >> >> > libbfd and libiberty do not have version numbers, are not >> > maintained (i.e. there is no official releases). every project >> > includes its own libiberty and imho an attempt to find least common >> > denominator will fail >> >> Well, they come to FreeBSD as part of the binutils, right? > > NO! Is that a "NO!" as in "no, it does not come as part of the binutils", or is that a "NO!" as in "I'M NOT GOING TO AGREE WITH ANYTHING YOU SAY?" > Max told you what a nightmare it would be. He is 110% right. Max only objected to using dynamic versions of this two libraries, BTW. > PLEASE take some advice from two people that are experienced in the > issues. I'd like to take any advice, but it has to be founded. Plenty of pieces of the FreeBSD project are "a nightmare" -- including the binutils, and the compilers, and the whole Alpha port, to name a few -- if the postings to this mailing lists (including those from you) are any indication. Yet, we (including you) do them anyway, because they are worth it (for whatever reasons). I'm trying to persuade the audience, that installing the libbfd and libiberty (which we build anyway!) into /usr/lib is also worth the trouble, because it will help add new software through the ports system -- like the gcj-compiler, or different versions of GCC, etc. (With all available targets enabled, preferably.) I mean, I can add arm-aout or arm-elf binutils to the system through the devel ports, or mingw -- all with their own libbfd, but I don't have access to the native version, which is built as part of the base OS, just never installed? Is not this a bit ridiculous? -mi P.S. NetBSD installs shared libbfd: http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/gnu/lib/libbfd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Wed, Feb 06, 2002 at 03:46:22PM -0500, Mikhail Teterin wrote: > > dynamically linked libiberty would be a nightmare. > > > libbfd anf libiberty do not have version numbers, are not maintained > > (i.e. there is no official releases). every project includes its own > > libiberty and imho an attempt to find least common denominator will > > fail > > Well, they come to FreeBSD as part of the binutils, right? NO! Max told you what a nightmare it would be. He is 110% right. PLEASE take some advice from two people that are experienced in the issues. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 7 Feb, Max Khon wrote: > dynamically linked libiberty would be a nightmare. > libbfd anf libiberty do not have version numbers, are not maintained > (i.e. there is no official releases). every project includes its own > libiberty and imho an attempt to find least common denominator will > fail Well, they come to FreeBSD as part of the binutils, right? That's a good start for a version number/release :-) We don't actually build separate libbfd for linker and assembler, and separate for the compiler, do we? Any additional packages (such as those from ports) should be able to use the same libraries, IMHO, even though they may come with their own versions. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
hi, there! On Wed, Feb 06, 2002 at 02:52:40PM -0500, Mikhail Teterin wrote: > But alright, let's say -- ports. gcj and gcjh themselves are > installed by the several lang/gcc* ports, but they are not functional > (libgcj/libjava are not ported). As a ports committer I might try to fix > that, but I think, those ports should complement the base system, and > that the base system should provide the bits it already uses itself > (like libbfd and libiberty) to the programmers, that use FreeBSD -- > install them into /usr/lib and link them _dynamicly_ into the tools. dynamically linked libiberty would be a nightmare. libbfd anf libiberty do not have version numbers, are not maintained (i.e. there is no official releases). every project includes its own libiberty and imho an attempt to find least common denominator will fail /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: > On Wed, Feb 06, 2002 at 01:05:16PM -0500, Mikhail Teterin wrote: >> > Uh, NO! It is not needed by the base system. We really do not want >> > to turn on all the support libs, etc.. that would be needed with >> > this. There is a reason the gcc30 port takes 25 minutes to compile >> > on a fast 1.2 GHz Athlon. >> >> That's the thing. gcc30 port, essentially, installs a copy of the >> compiler already available as part of the base. > > No it doesn't. 3.0.3 is a very different compiler from 2.95.3. I thought we are moving to gcc-3.x quickly :-) But the other ports, such as lang/gcc295 don't complement the base system either -- they install a full new set under LOCALBASE, instead of just the missing pieces (like gcj). >> But the base is missing gcj (the port does too for now), so one would >> be forced to add the port. > > And the base system does not NEED a java compiler. Alright. But a FreeBSD installation -- might. >> Can we have those [libbfd and libiberty] installed, at least, to ease >> the work of the future porter? > > Nope. That's too brief for a mutually respectful conversation :-\ I know it is your "style", but do not accept this answer anyway. All I'm talking about, is that having a functional gcj _available_ on FreeBSD is a good thing. Through the ports collection or as part of the base system. The fact, that nothing in the base requires Java is hardly an argument in itself. Nothing requires Fortran, or the dictionary, or the cal(1) either. But alright, let's say -- ports. gcj and gcjh themselves are installed by the several lang/gcc* ports, but they are not functional (libgcj/libjava are not ported). As a ports committer I might try to fix that, but I think, those ports should complement the base system, and that the base system should provide the bits it already uses itself (like libbfd and libiberty) to the programmers, that use FreeBSD -- install them into /usr/lib and link them _dynamicly_ into the tools. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Wed, Feb 06, 2002 at 01:05:16PM -0500, Mikhail Teterin wrote: > > Uh, NO! It is not needed by the base system. We really do not want to > > turn on all the support libs, etc.. that would be needed with this. > > There is a reason the gcc30 port takes 25 minutes to compile on a fast > > 1.2 GHz Athlon. > > That's the thing. gcc30 port, essentially, installs a copy of the > compiler already available as part of the base. No it doesn't. 3.0.3 is a very different compiler from 2.95.3. > But the base is missing > gcj (the port does too for now), so one would be forced to add the port. And the base system does not NEED a java compiler. > Can we have those installed, at least, to ease the work of the future > porter? Nope. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: > On Wed, Feb 06, 2002 at 11:19:19AM -0500, Mikhail Teterin wrote: >> BTW, how about, may be, if the stars are right, bringing in the Java >> support too? gcj is now one of the compilers, that come with the GCC >> package... > Uh, NO! It is not needed by the base system. We really do not want to > turn on all the support libs, etc.. that would be needed with this. > There is a reason the gcc30 port takes 25 minutes to compile on a fast > 1.2 GHz Athlon. That's the thing. gcc30 port, essentially, installs a copy of the compiler already available as part of the base. But the base is missing gcj (the port does too for now), so one would be forced to add the port. If it were possible (through a port) to add just gcj (and accompanying libraries) to integrate with the already present gcc and other bits, but it is not :-( Even the things like libiberty and libbfd are not installed... Can we have those installed, at least, to ease the work of the future porter? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On Wed, Feb 06, 2002 at 11:19:19AM -0500, Mikhail Teterin wrote: > BTW, how about, may be, if the stars are right, bringing in the Java > support too? gcj is now one of the compilers, that come with the GCC > package... Uh, NO! It is not needed by the base system. We really do not want to turn on all the support libs, etc.. that would be needed with this. There is a reason the gcc30 port takes 25 minutes to compile on a fast 1.2 GHz Athlon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
