BTW, do you plan to include egcs' g77 as well?
Current, the g77 driver is built. But the f771 isn't. From previous
talk, I've gotten the impression g77 should be a port vs. in the base
system. I'm Ok either way -- I leave the decision to the lists and Core.
--
-- David(obr...@nuxi.com
David O'Brien wrote:
BTW, do you plan to include egcs' g77 as well?
Current, the g77 driver is built. But the f771 isn't. From previous
talk, I've gotten the impression g77 should be a port vs. in the base
system. I'm Ok either way -- I leave the decision to the lists and Core.
At the
A pity. This would mean g77 gets a fair chance to once again become quite
obsolete. Of course, it's not all that important 'far as servers are
concerned, but as I'm in high energy physics - I should say so far all my
colegues I know used FORTRAN rather than C/C++. Well, that still doesn't
make us
BTW, do you plan to include egcs' g77 as well?
Current, the g77 driver is built. But the f771 isn't. From previous
talk, I've gotten the impression g77 should be a port vs. in the base
system. I'm Ok either way -- I leave the decision to the lists and Core.
- --
- -- David
Hello, here's where cpp died. There's a small error in freebsd.h:
INCLUDE_DEFAULTS array defined in a wrong way (patch attached). Now cpp
doesn't die anymore. There's an another problem, though. For somereason
libgcc doesn't want to compile with base c++ (conflict in new, it
seems). It does
On Sat, 13 Mar 1999, Vladimir Kushnir wrote:
BTW, binaries compiled with egcc are still larger than with stock gcc. Is
there a way to shrink them (beyond what's possible with -O optimisation)?
Try -Os, -fno-exceptions* -fno-rtti* or any combo of the above.
* Don't do this with libraries,
Thanks, I'll try, but what I mean is egcs compiled binaries are bigger
even for C, not C++, and as if memory serves -Os is -O2 subset. So
probably I'll just have to accept this increase in binaries size :-(. Ah
well, it ain't all that much, anyway.
Oh, incidentally, I forgot to add that
On Sun, 14 Mar 1999, Vladimir Kushnir wrote:
Thanks, I'll try, but what I mean is egcs compiled binaries are bigger
even for C, not C++, and as if memory serves -Os is -O2 subset. So
probably I'll just have to accept this increase in binaries size :-(. Ah
well, it ain't all that much,
On Sat, Mar 13, 1999 at 11:33:23PM +0200, Vladimir Kushnir wrote:
Hello, here's where cpp died. There's a small error in freebsd.h:
^
freebsd-elf.h
INCLUDE_DEFAULTS array
gnu/lib/libstdc++/Makefile this part of CFLAGS shoild be
-I${EGCSDIR}/gcc/cp/inc rather than -I${EGCSDIR}/gcc/cp/inc/exception
(after all, ${EGCSDIR}/gcc/cp/inc/exception is a file).
Yes. What I was working on is newer than the CVS repository. I'm
chasing several issues moving things
Excellent, I'll have a free weekend then :-) BTW, do you plan to include
egcs' g77 as well?
On Sat, 13 Mar 1999, David O'Brien wrote:
Yes. What I was working on is newer than the CVS repository. I'm
chasing several issues moving things around. I haven't been keeping
the CVSup'able totally
I've been compiling things w/in /usr/src/ , but haven't done a ``make
world'' with EGCS in-place in /usr/src due to the `cpp w/c++'' problem.
Where exactly does it die? We should at least make it easily possible
to get the build environment configured the way it's supposed to
look so that
I've been compiling things w/in /usr/src/ , but haven't done a ``make
world'' with EGCS in-place in /usr/src due to the `cpp w/c++'' problem.
Where exactly does it die?
Lets assume one is not trying to hook EGCS into /usr/src yet.
cd /foo/src/gnu/usr.bin/cc
make obj
make depend
make -k
/foo/src/gnu/lib/libstdc++/../../../contrib/egcs/libio/gen-params
I'd be very curious to see how gen-params is calling c++ and/or cpp in
this case.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
On Fri, Mar 12, 1999 at 02:29:27AM -0800, Jordan K. Hubbard wrote:
/foo/src/gnu/lib/libstdc++/../../../contrib/egcs/libio/gen-params
I'd be very curious to see how gen-params is calling c++ and/or cpp in
this case.
+ c++ -v -O -c dummy.C
Using builtin specs.
gcc version egcs-2.91.63
On Fri, 12 Mar 1999, David O'Brien wrote:
On Fri, Mar 12, 1999 at 02:29:27AM -0800, Jordan K. Hubbard wrote:
/foo/src/gnu/lib/libstdc++/../../../contrib/egcs/libio/gen-params
I'd be very curious to see how gen-params is calling c++ and/or cpp in
this case.
+ c++ -v -O -c dummy.C
Hmm environment variables?
That is my guess.. but I don't know an easy way to printout the entire
environtment a program sees.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the
On Fri, 12 Mar 1999, David O'Brien wrote:
Hmm environment variables?
That is my guess.. but I don't know an easy way to printout the entire
environtment a program sees.
How about hacking cpp so that it does 'system(env /tmp/somefile)' as
the first thing.
--
Doug Rabson
Doug Rabson wrote:
On Fri, 12 Mar 1999, David O'Brien wrote:
Hmm environment variables?
That is my guess.. but I don't know an easy way to printout the entire
environtment a program sees.
How about hacking cpp so that it does 'system(env /tmp/somefile)' as
the first thing.
I
I've put the bmake contrib framework for EGCS at
ftp://ftp.nuxi.com/pub/FreeBSD/egcs
(ftp://ftp.nuxi.com/pub/FreeBSD/egcs/cvs is all you really need)
This is very rough work, but should help us towards our goal.
In there you will find a CVS tree under ``cvs''. This CVS tree
corresponds
How's this going?
Everything now builds, and I can pass the C++ STL tests supplied with
EGCS.
There is at least one case w/in gnu/usr.bin/cc that ``make cleandir
make cleandir make obj make depend make make clean make''
will file to build. But I haven't worried too much about that yet.
David O'Brien wrote:
I've put the bmake contrib framework for EGCS at
ftp://ftp.nuxi.com/pub/FreeBSD/egcs
(ftp://ftp.nuxi.com/pub/FreeBSD/egcs/cvs is all you really need)
This is very rough work, but should help us towards our goal.
In there you will find a CVS tree under ``cvs''. This
It would help a lot if you could make it CVSUPpable :-). Those of us
in the third world would greatly appreciate that!
You talked me into it :-)
distributions are egcs (or broken into bmake-egcs and contrib-egcs)
*default host=relay.nuxi.com
*default base=.
*default release=cvs
*default delete
23 matches
Mail list logo
