On Mon, 1 Mar 1999, Jordan K. Hubbard wrote:
I can generally build a kernel with EGCS, if I change how the .text and
.data are laid out for initialized data. It seems that the initialization
code makes assumptions about the order or layout of the initialization
data. Once the stuff is
At 01:28 PM 3/1/99 -0800, Jordan K. Hubbard wrote:
I can generally build a kernel with EGCS, if I change how the .text and
.data are laid out for initialized data. It seems that the initialization
code makes assumptions about the order or layout of the initialization
data. Once the stuff is
Doesn't this just rebuild the standard gcc compiler in /usr/obj/usr/tmp/bin a
s
part of the tools build, then use that compiler to build world.
Hmmm. You may have an embarassing point here; I was wondering how/if
the native compiler got used during the build process if you commented
it out of
On Mon, 1 Mar 1999, John Polstra wrote:
Hang on. Others have reported success building kernels with egcs.
Count me among that list - although last time I tried was about 6 months ago.
The only problem I noticed was the format extensions, although admittedly I
didn't run with the kernel for
Count me among that list - although last time I tried was about 6 months ago.
The only problem I noticed was the format extensions, although admittedly I
I'm running a kernel built with my contrib'ifed EGCS. Format extensions
and all. libstdc++ is still a problem though.
--
-- David
Monday, March 01, 1999, 6:20:06 PM, you wrote:
Just make libg++ a port. :-)
Yes, or abandon it entirely. We surely don't need it in our base
system. Even for ports, I'd be surprised to find anything useful that
still relied on libg++. Any software that still uses libg++ is almost
Jonathan Lemon jle...@americantv.com writes:
How about getting profiling working for ELF kernels before
before completely abandoning a.out?
There are patches for that in kern/9413 but I haven't got any feedback
on them at all.
/assar
To Unsubscribe: send mail to majord...@freebsd.org
with
On Mar 03, 1999 at 06:02:37AM +0100, Assar Westerlund wrote:
Jonathan Lemon jle...@americantv.com writes:
How about getting profiling working for ELF kernels before
before completely abandoning a.out?
There are patches for that in kern/9413 but I haven't got any feedback
on them at all.
Just make libg++ a port. :-)
Yes, or abandon it entirely. We surely don't need it in our base
...
Netscape still uses libg++
...
And most will imho agree on the fact, that Netscape is in some ways useful :)
-lg++.4 = /usr/lib/aout/libg++.so.4.0 (0x10c5c000)
At 01:28 PM 3/1/99 -0800, Jordan K. Hubbard wrote:
It really does appear to be a simple matter of first making egcs take over
the system compiler:
# cd /usr/ports/lang/egcs
# make all install PREFIX=/usr
# ln -fs /usr/bin/eg++ /usr/bin/c++
# ln -fs /usr/bin/egcc /usr/bin/cc
# cd /usr/src
Although this approach works, IMHO, the more appropriate approach
would be to use ${CC} rather than cc in ALL the makefiles and then
define CC=/usr/bin/egcc
There will be troubles compling C++ code (groff) if our Makefiles add
-I/usr/include/g++ to CXXFLAGS, which I'll bet it does.
--
--
On 02-Mar-99 Richard Wackerbarth wrote:
remove cc from /usr/src/gnu/usr.bin/Makefile SUBDIR list
remove libstdc++ and libobjc from /usr/src/gnu/lib/Makefile SUBDIR list
Although this approach works, IMHO, the more appropriate approach
would be to use ${CC} rather than cc in ALL the
Peter was working on it, but I strongly suspect he won't have time to
even think about this in the very near future
Personally, I'm slowly working on putting the FreeBSD GCC changes into
EGCS 1.1.1 so it can compile our sources.
I've got the compiler contribed and am working on the contrib of
On Sat, 27 Feb 1999, Jordan K. Hubbard wrote:
I for one would love to see 2.8.1 or newer in the tree for my own,
selfish reasons. Many ports (new architectures) would benefit from
this.
Is that to say that you prefer it over egcs 1.1.1? If so, why?
I have found egcs to be slightly
David O'Brien wrote:
Peter was working on it, but I strongly suspect he won't have time to
even think about this in the very near future
Personally, I'm slowly working on putting the FreeBSD GCC changes into
EGCS 1.1.1 so it can compile our sources.
Hmm... Does it not make more sense to
Hmm... Does it not make more sense to slowly remove the FreeBSD'ism
that require that we futz with the compiler?
I don't think bde, et. al. is going to let -fformat-extensions go away. :-)
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to
David O'Brien wrote:
Hmm... Does it not make more sense to slowly remove the FreeBSD'ism
that require that we futz with the compiler?
I don't think bde, et. al. is going to let -fformat-extensions go away. :-)
Then can't we get that put into mainstream gcc/egcs?
M
--
Mark Murray
Join
On Sat, 27 Feb 1999, Jordan K. Hubbard wrote:
I for one would love to see 2.8.1 or newer in the tree for my own,
selfish reasons. Many ports (new architectures) would benefit from
this.
Is that to say that you prefer it over egcs 1.1.1? If so, why?
I was a little surprised at the egcs
Hmm... Does it not make more sense to slowly remove the FreeBSD'ism
that require that we futz with the compiler?
I don't think bde, et. al. is going to let -fformat-extensions go away. :-)
Then can't we get that put into mainstream gcc/egcs?
Because extensions are extensions of the
According to Chuck Robey:
I know that, back when we ran aout, our gcc was a long way changed from
the stock gnu gcc ... I'm wondering how much our gcc is changed, now,
from the gcc that is the regular GNU distribution?
gcc was not that different, it was mostly the binutils chain (as, ld and
On Sun, Feb 28, 1999 at 09:32:51AM +, Doug Rabson wrote:
On Sat, 27 Feb 1999, Jordan K. Hubbard wrote:
I for one would love to see 2.8.1 or newer in the tree for my own,
selfish reasons. Many ports (new architectures) would benefit from
this.
Is that to say that you prefer it
%On Sat, 27 Feb 1999, Jordan K. Hubbard wrote:
%
% I for one would love to see 2.8.1 or newer in the tree for my own,
% selfish reasons. Many ports (new architectures) would benefit from
% this.
%
% Is that to say that you prefer it over egcs 1.1.1? If so, why?
%
%I have found egcs to be
In message 20655.920182...@zippy.cdrom.com Jordan K. Hubbard writes:
: I for one would love to see 2.8.1 or newer in the tree for my own,
: selfish reasons. Many ports (new architectures) would benefit from
: this.
:
: Is that to say that you prefer it over egcs 1.1.1? If so, why?
No. I'd
Warner Losh wrote:
In message 20655.920182...@zippy.cdrom.com Jordan K. Hubbard writes:
: I for one would love to see 2.8.1 or newer in the tree for my own,
: selfish reasons. Many ports (new architectures) would benefit from
: this.
:
: Is that to say that you prefer it over egcs
In message 199902281707.baa63...@spinner.netplex.com.au Peter Wemm writes:
: better cross-compile support. (Note, the cross compile stuff doesn't work
: too happily with the existing bmake glue and hacks in the code.)
Yes. That's one of the big reasons that I'd like to see a more modern
[fwd to -current]
Hi Chuck,
I must agree with your concerns about the bleeding-edge nature of
EGCS. At Glenayre we've tried several times to move up to EGCS
for our embedded development efforts, only to beat a hasty retreat
back to GCC because of code generation and execution bugs in the
The main holdups have been getting the native egcs build to do something
more sensible with regards to -aout/-elf, and, if things work out, a bit
Work might go a bit faster if the work that has been done already would
be posted somewhere. Having such an important issue being responsible on
a
In message 19990228131503.a1...@relay.nuxi.com David O'Brien writes:
: ALSO, don't forget that just getting a FreeBSD'ized EGCS is just the
: first step. We will have to test ``build world'' many times and I'm sure
: we will have to change base code to compile as we like with EGCS. The
: more
In article 199902282119.oaa81...@harmony.village.org,
Warner Losh i...@harmony.village.org wrote:
BTW, do we need to update binutils? Or are they new enough? I know
that my needs for binutils are covered by the missing bits in the
current version we have in the tree.
I'm pretty sure our
On Sun, 28 Feb 1999, David O'Brien wrote:
In addition, at schools it is getting harder and harder to convince people
to try FreeBSD when we have a broken C++ compiler in the base system. In
case some aren't aware, C++ is now part of the standard CS curriculum
these days.
I work as System
It should be too easy to replace the compiler after the system is
installed...and shouldn't be seen as a major hindrance...
But as Micro$hit knows, being able to check off feature boxes is
important. Here, the CS dept encourages people that own a PC to install
a Unix at home (we are still 100%
On Sun, 28 Feb 1999, David O'Brien wrote:
It should be too easy to replace the compiler after the system is
installed...and shouldn't be seen as a major hindrance...
But as Micro$hit knows, being able to check off feature boxes is
important. Here, the CS dept encourages people that own a
The main holdups have been getting the native egcs build to do something
more sensible with regards to -aout/-elf, and, if things work out, a bit
better cross-compile support. (Note, the cross compile stuff doesn't work
too happily with the existing bmake glue and hacks in the code.) I think
Work might go a bit faster if the work that has been done already would
be posted somewhere. Having such an important issue being responsible on
a single over-worked person is not productive. ***Like Jordan said, we
get NO new install and package utils until EGCS is in the tree.***
Would
Please keep in mind that if, in our haste, we import a compiler that
puts instability into FreeBSD, then we've drunk poison. The feature
A legit concern, but also realize that all of us are talking about
4.0 here - the new compiler would be an issue we'd have up to a full
year on before the
A legit concern, but also realize that all of us are talking about
4.0 here - the new compiler would be an issue we'd have up to a full
year on before the product it's in goes mainstream. If that's not enough
time to work out the compiler issues after switching, I can't imagine
when we WILL
On Sun, 28 Feb 1999, Jordan K. Hubbard wrote:
Please keep in mind that if, in our haste, we import a compiler that
puts instability into FreeBSD, then we've drunk poison. The feature
A legit concern, but also realize that all of us are talking about
4.0 here - the new compiler would be
On Sun, Feb 28, 1999 at 05:59:08PM -0500, Kenneth Wayne Culver wrote:
This is interesting, what makes egcs better than gcc? just a dumb
question. I agree with Jordan though: no pain no gain. :-)
IMHO, maintence. EGCS is actively being developed. Gcc 2.8.x might be,
but it is hard to see.
Chuck Robey chu...@mat.net wrote:
Please keep in mind that if, in our haste, we import a compiler that
puts instability into FreeBSD, then we've drunk poison.
I agree that -STABLE _must_ remain stable.
That said, I believe that we _do_ need to move forward. I'd like to
see either EGCS or
On Sun, 28 Feb 1999, Chuck Robey wrote:
On Sun, 28 Feb 1999, David O'Brien wrote:
It should be too easy to replace the compiler after the system is
installed...and shouldn't be seen as a major hindrance...
But as Micro$hit knows, being able to check off feature boxes is
important.
I keep on hearing about how we're losing because we don't have the 3
month old latest feature
With EGCS the issue isn't having the latest 3 mo. feature, but we have a
totally BROKEN C++ compiler.
The STL with it is broken, and it is so far from the ISO C++ standard,
it really can't be called
On Sun, 28 Feb 1999, Jordan K. Hubbard wrote:
Please keep in mind that if, in our haste, we import a compiler that
puts instability into FreeBSD, then we've drunk poison. The feature
A legit concern, but also realize that all of us are talking about
4.0 here - the new compiler would be
On Sun, 28 Feb 1999, Kenneth Wayne Culver wrote:
A legit concern, but also realize that all of us are talking about
4.0 here - the new compiler would be an issue we'd have up to a full
year on before the product it's in goes mainstream. If that's not enough
time to work out the compiler
It should be too easy to replace the compiler after the system is
installed...and shouldn't be seen as a major hindrance...
But as Micro$hit knows, being able to check off feature boxes is
important. Here, the CS dept encourages people that own a PC to install
a Unix at home (we are
On Sun, 28 Feb 1999, The Hermit Hacker wrote:
On Sun, 28 Feb 1999, Chuck Robey wrote:
On Sun, 28 Feb 1999, David O'Brien wrote:
It should be too easy to replace the compiler after the system is
installed...and shouldn't be seen as a major hindrance...
But as Micro$hit
Peter Jeremy wrote:
I'd like to see it merged back into the 3.x tree earlier than this.
The general complaining about compiler related issues (C++ and
FORTRAN-77 being the two most recent issues) will continue until the
compiler makes it into a release. I think we should be able to easily
How about this, which noone has suggested:
Why don't we, for now, import EGCS and libstdc++, getting those working?
Of course, here's the trick; let's keep /usr/bin/gcc and /usr/bin/cc as 2.7.2.x
like they are now. But for /usr/bin/c++ and /usr/bin/g++, let's have EGCS
overwrite the
Sounds like an absolute nightmare. Needless to say, I loath this idea. :)
How about this, which noone has suggested:
Why don't we, for now, import EGCS and libstdc++, getting those working
?
Of course, here's the trick; let's keep /usr/bin/gcc and /usr/bin/cc as 2.7.2
.x
like they are
Brian Feldman gr...@unixhelp.org wrote:
[use cc1-2.7.2.1 and ECGS cc1plus]
we get to keep
(for now) the stable, reliable, C compiler we've been depending on for years.
With all the well-known idiosyncrasies that we've been working around
for years.
Of
course, in the long run, once stability
On Sun, 28 Feb 1999, Chuck Robey wrote:
Your argument about CS students needing the better compiler was true,
but totally ignored the fact that getting the CS students their compiler
IS NOT the top priority, especially since ports can do it (did for me).
U, you mis-quoted. I agree with
On Sun, 28 Feb 1999, Brian Feldman wrote:
How about this, which noone has suggested:
Why don't we, for now, import EGCS and libstdc++, getting those working?
Of course, here's the trick; let's keep /usr/bin/gcc and /usr/bin/cc as
2.7.2.x
like they are now. But for /usr/bin/c++ and
On Mon, 1 Mar 1999, Peter Jeremy wrote:
Brian Feldman gr...@unixhelp.org wrote:
[use cc1-2.7.2.1 and ECGS cc1plus]
we get to keep
(for now) the stable, reliable, C compiler we've been depending on for years.
With all the well-known idiosyncrasies that we've been working around
for
On Mon, 1 Mar 1999, Peter Jeremy wrote:
There's a catch-22 here: We can't prove the stability of EGCS until we
start using it. Even if we don't make EGCS the base compiler, we need
a standard documented mechanism for doing `make world' with EGCS as well
as agreement that bug reports using
Tugrul tug...@ianai.blacksun.org wrote:
Right now I'm manually building the source
tree with egcs to see how I fair.
I tried this with 2.x and gcc-2.8.1, but was never successful - I
never managed to stop it building the base compiler and not complain
that it hadn't built the base compiler. I
In Reply to Your Message of Sun, 28 Feb 1999 20: 38:49 -0400
Date: Sun, 28 Feb 1999 22:08:14 -0500
From: Jerry Alexandratos alexa...@mail.eecis.udel.edu
Message-ID: 199902282208.aa04...@mail.eecis.udel.edu
The Hermit Hacker scra...@hub.org says:
: On Sun, 28 Feb 1999, Chuck Robey wrote:
:
:
On Sun, 28 Feb 1999, Tugrul wrote:
[20:10]galat...@callisto:/usr/src/sys/compile/CALLISTO# make CC=egcc -k
[...errors...]
[20:10]galat...@callisto:/usr/src/sys/compile/CALLISTO#
Never mind, those errors are not faults in EGCS it seems. PGCC
introduces those problems. I built my
On Sun, 28 Feb 1999 alexa...@mail.eecis.udel.edu wrote:
In Reply to Your Message of Sun, 28 Feb 1999 20: 38:49 -0400
Date: Sun, 28 Feb 1999 22:08:14 -0500
From: Jerry Alexandratos alexa...@mail.eecis.udel.edu
Message-ID: 199902282208.aa04...@mail.eecis.udel.edu
The Hermit Hacker
On Sun, 28 Feb 1999, The Hermit Hacker wrote:
The Hermit Hacker scra...@hub.org says:
: On Sun, 28 Feb 1999, Chuck Robey wrote:
:
: Your argument about CS students needing the better compiler was true,
: but totally ignored the fact that getting the CS students their compiler
:
It is time to dump libg++. Once EGCS is in the tree, I'll make a port of
the libg++ meant for post g++ 2.8 compilers.
What's the exact division between libg++ and libstdc++? I'm sure
I'm not the only person confused by this one. :)
libg++ was a set of standard classes for strings,
Thus libg++ classes are a purely FSF class library that shouldn't be used
for any new code development. The current libg++ only contains what was
left after the ISO stdlibc++ stuff was gutted.
Thanks for the explanation - that makes things much clearer. So, I
guess we shoot for libstdc++ as
guess we shoot for libstdc++ as the minimum requirements and perhaps
provide libg++ as well (not necessarily initially) just for the
Just make libg++ a port. :-)
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe
Jordan K. Hubbard wrote:
I've just built the world and kernel from egcs-2.91.62 and it
seems to work pretty well. I haven't really stress the system
all that much yet, but it hasn't misbehaved in any way yet.
- Jrodan
Since 4.0 was only recently branched, now seems like a good time
to
I'm wondering about the size of a project, to upgrade the compiler (this
wants a relative answer, how much larger or smaller a job is it now,
that it would have been a year ago under aout)? Is anyone doing this?
Peter was working on it, but I strongly suspect he won't have time to
even
I know that, back when we ran aout, our gcc was a long way changed from
the stock gnu gcc ... I'm wondering how much our gcc is changed, now,
from the gcc that is the regular GNU distribution?
$ cvs diff -r FSF /usr/src/contrib/gcc | wc
17467551 57123
[error
In message 19877.920165...@zippy.cdrom.com Jordan K. Hubbard writes:
: I'm not sure I'd call it a decision, but there are strong leanings
: towards egcs. It simply seems to be moving more aggressively (and
: more well-fundedly) in the right directions whereas gcc 2.8.1 has been
: very slow to
I for one would love to see 2.8.1 or newer in the tree for my own,
selfish reasons. Many ports (new architectures) would benefit from
this.
Is that to say that you prefer it over egcs 1.1.1? If so, why?
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe
In article [EMAIL PROTECTED]
"Rodney W. Grimes" [EMAIL PROTECTED] said:
Something weird is going on... I can confirm Manfred's claim, I also just
build XFree86 just before the compiler change. I'm certainly not going to
cvs update right now... :-)
After some investigation, I found that
On Sat, 20 Nov 1999, SANETO Takanori wrote:
After some investigation, I found that following reasons (both cpp
related) caused the failure of build/installing XFree86:
1. /usr/libexec/cpp now has no predefined symbols like __FreeBSD__,
which makes imake unable to detect OS type
David O'Brien wrote:
I've got GCC 2.95.2 working as the base compiler. It is still a little
rough, but I wanted to put it in more hands for testing.
If it doesn't interfere with my current work, then I'll get to it ASAP.
I already have some fixes for the current binutils and egcs WRT to
601 - 669 of 669 matches
Mail list logo
