Re: How about gcj? (Re: Not committing WARNS settings...)

2002-02-11 Thread Wilko Bulte

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...)

2002-02-11 Thread David O'Brien

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...)

2002-02-11 Thread David O'Brien

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...)

2002-02-11 Thread Terry Lambert

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...)

2002-02-11 Thread David O'Brien

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...)

2002-02-11 Thread Mikhail Teterin

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...)

2002-02-11 Thread Mikhail Teterin

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...)

2002-02-11 Thread Mikhail Teterin

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...)

2002-02-11 Thread Mikhail Teterin

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...)

2002-02-11 Thread Terry Lambert

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...)

2002-02-07 Thread David O'Brien

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...)

2002-02-07 Thread Wilko Bulte

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...)

2002-02-07 Thread David O'Brien

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...)

2002-02-07 Thread Wilko Bulte

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...)

2002-02-07 Thread David O'Brien

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...)

2002-02-07 Thread Terry Lambert

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...)

2002-02-06 Thread Mikhail Teterin

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...)

2002-02-06 Thread David O'Brien

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...)

2002-02-06 Thread Mikhail Teterin

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...)

2002-02-06 Thread Max Khon

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...)

2002-02-06 Thread Mikhail Teterin

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...)

2002-02-06 Thread David O'Brien

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...)

2002-02-06 Thread Terry Lambert

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...)

2002-02-06 Thread Terry Lambert

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...)

2002-02-06 Thread Terry Lambert

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...)

2002-02-06 Thread David O'Brien

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...)

2002-02-06 Thread Mikhail Teterin

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