Re: bmake/contrib framework for egcs
>> 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 -or- obr...@freebsd.org) I think the building of the fortran compiler should be controlled through some variable in /etc/make.conf - BUILD_G77 or something like that, the same way you can elect to build profiled libs et cetera. It'd be a pain in the rear artificially ripping out source and including it in another tarball. Stephen -- The views expressed above are not those of PGS Tensor. "People often think of research as a form of development -- that it's about doing exactly what you planned, doing it on time, and doing it with resources that you said you'd use. But if you're going to do that, you have to know what you are doing, and if you know what you are doing, it isn't really research." --Dave Liddle, The New Yorker, Feb. 23/Mar.2, 1998, p 84 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
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 a majority here, does it? On Sun, 14 Mar 1999, 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. > > -- > -- David(obr...@nuxi.com -or- obr...@freebsd.org) > > Oh, BTW, just today went through 'make -j16 buildworld' with your bmaked egcs' compiled kernel (j16 is not very impressive, but computer is a poor old P5-100 with only 32 Mb RAM). Kernel looked fairly stable, at least in single user mode. Regards, Vladimir ===|=== Vladimir Kushnir | ku...@mail.kar.net, |Powered by FreeBSD kush...@ap3.bitp.kiev.ua | To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
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 risk of starting another pointless Fortran thread, I have ports of f2c and a new f77 driver for f2c sitting on my machine. If you decide to include g77 (which would be a Good Thing, IMHO), then I'll submit and maintain the f2c port. -- Steve To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
> 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 -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
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 bits upto date in the past few days. > > Tonight or Sunday, I hope to have the same thing I'm working on available > to all. > > -- > -- David(obr...@nuxi.com -or- obr...@freebsd.org) > > ===|=== Vladimir Kushnir | ku...@mail.kar.net, |Powered by FreeBSD kush...@ap3.bitp.kiev.ua | To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
> 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 around. I haven't been keeping the CVSup'able totally bits upto date in the past few days. Tonight or Sunday, I hope to have the same thing I'm working on available to all. -- -- 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 message
Re: bmake/contrib framework for egcs
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 defined in a wrong way (patch attached). Now cpp Crud! I had freebsd.h right, but didn't get the changes to "INCLUDE_DEFAULTS" into freebsd-elf.h. Thanks! -- -- 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 message
Re: bmake/contrib framework for egcs
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, anyway. -Os is a subset of -O2, which enables everything that won't increase the size of a binary. However, I don't know about rtti, but IIRC exception handling code (or perhaps stubs thereof) are included even in C code, just incase. Perhaps jdp can shed some more light on this (he's been a very useful resource to me in the past). > Oh, incidentally, I forgot to add that (when compiling libstdc++ with new > c++ for the first time, it can't find file exception. So perhaps in > 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). - alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
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 (when compiling libstdc++ with new c++ for the first time, it can't find file exception. So perhaps in 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). On Sat, 13 Mar 1999, Alex Zepeda wrote: > 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, just in case you've got any programs that > use exceptions or rtti. Obviously this won't work with programs that use > rtti and/or exceptions. > > - alex > Regards, Vladimir ===|=== Vladimir Kushnir | ku...@mail.kar.net, |Powered by FreeBSD kush...@ap3.bitp.kiev.ua | To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
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, just in case you've got any programs that use exceptions or rtti. Obviously this won't work with programs that use rtti and/or exceptions. - alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
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 compile if COMPILER_PATH is set to uitilize a newly compiled c++ and cc1plus, but it takes addition CFLAGS+=-I${GCCDIR}/cp/inc to gnu/usr.bin/cc/Makefile.inc. Then everything builds indeed. 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)? On Thu, 11 Mar 1999, David O'Brien wrote: > > 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. > > The biggest problem is that ``cpp'' will get a sig11 when executed by > c++. If I use ``c++ -v'' and manually execute what c++ is, I don't get > the sig11. I got tired of trying to track this down, so to get around > this (so I could work on libstdc++), I copy ``cpp'' into /usr/libexec > from a copy of an installed EGCS port. > > The version in my repository is EGCS 1.1.2-pre3. Rumors have it that > 1.1.2 will released on Friday, and by Monday at the latest. Regards, Vladimir ===|=== Vladimir Kushnir | ku...@mail.kar.net, |Powered by FreeBSD kush...@ap3.bitp.kiev.ua | *** freebsd.h.orig Sat Mar 13 23:20:27 1999 --- freebsd.h Wed Mar 10 23:22:32 1999 *** *** 259,267 #ifdef FREEBSD_NATIVE #define INCLUDE_DEFAULTS { \ ! { "/usr/include", 0, 0 }, \ ! { "/usr/include/g++", 1, 1 }, \ ! { 0, 0, 0} \ } #undef MD_EXEC_PREFIX --- 259,267 #ifdef FREEBSD_NATIVE #define INCLUDE_DEFAULTS { \ ! { "/usr/include", 0, 0, 0 }, \ ! { "/usr/include/g++", "G++", 1, 1 }, \ ! { 0, 0, 0, 0} \ } #undef MD_EXEC_PREFIX
Re: bmake/contrib framework for egcs
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 like to move the executable to 'cpp.bin' then create a shell script name 'cpp' that does something like: env > /tmp/cpp-env.$$ exec cpp.bin "$@" You can even have it start 'gdb' from within the script, if you really want to... To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
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 Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
> 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 message
Re: bmake/contrib framework for egcs
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 > Using builtin specs. > gcc version egcs-2.91.63 19990224 (egcs-1.1.2 pre-release-3) > /usr/libexec/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 > -D__cplusplus -D__GNUC_MINOR__=91 -Di386 -Dunix -D__ELF__ -D__FreeBSD__=4 > -D__FreeBSD_cc_version=31 -D__i386__ -D__unix__ -D__ELF__ > -D__FreeBSD__=4 -D__FreeBSD_cc_version=31 -D__i386 -D__unix > -Asystem(unix) -Asystem(FreeBSD) -Acpu(i386) -Amachine(i386) > -D__EXCEPTIONS -D__OPTIMIZE__ -D__ELF__ dummy.C /var/tmp/ccO39xXH.ii > GNU CPP version egcs-2.91.63 19990224 (egcs-1.1.2 pre-release-3) (i386 > FreeBSD/ELF) > c++: Internal compiler error: program cpp got fatal signal 11 > + echo gen-params: could not compile dummy.C with c++ -v > gen-params: could not compile dummy.C with c++ -v > + exit 1 > *** Error code 1 > > > gdb on the resulting core file isn't leading me anywhere. > If I use a little X-cut-n-paste and run the `cpp' command manually, it > works fine and I get the expected output from `cpp'. Hmm environment variables? > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
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 19990224 (egcs-1.1.2 pre-release-3) /usr/libexec/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=91 -Di386 -Dunix -D__ELF__ -D__FreeBSD__=4 -D__FreeBSD_cc_version=31 -D__i386__ -D__unix__ -D__ELF__ -D__FreeBSD__=4 -D__FreeBSD_cc_version=31 -D__i386 -D__unix -Asystem(unix) -Asystem(FreeBSD) -Acpu(i386) -Amachine(i386) -D__EXCEPTIONS -D__OPTIMIZE__ -D__ELF__ dummy.C /var/tmp/ccO39xXH.ii GNU CPP version egcs-2.91.63 19990224 (egcs-1.1.2 pre-release-3) (i386 FreeBSD/ELF) c++: Internal compiler error: program cpp got fatal signal 11 + echo gen-params: could not compile dummy.C with c++ -v gen-params: could not compile dummy.C with c++ -v + exit 1 *** Error code 1 gdb on the resulting core file isn't leading me anywhere. If I use a little X-cut-n-paste and run the `cpp' command manually, it works fine and I get the expected output from `cpp'. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
> /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
Re: bmake/contrib framework for egcs
> > 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 make -k install # the above will fail in libgcc since we are not using the freshly # built c++ because we aren't doing this as a ``build world'' which # would do the appropriate bootstrapping. Same issues as the previous # gcc 2.6.x to 2.7.x upgrade. make cleandir make obj make depend make make install cd /foo/src/gnu/usr.bin/lib/libstdc++ make obj make depend CC="cc" CXX="c++" CONFIG_NM="nm" CPP="cc -E -nostdinc -idirafter /usr/include" sh /foo/src/gnu/lib/libstdc++/../../../contrib/egcs/libio/gen-params LIB_VERSION=3.0.0 >_G_config.h c++: Internal compiler error: program cpp got fatal signal 11 gen-params: could not compile dummy.C with c++ *** Error code 1 It is at this point, that I'm coping ``cpp'' from an installed copy of the Egcs port into /usr/libexec so I can keep working on `build world' issues. -- -- 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 message
Re: bmake/contrib framework for egcs
> 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 others can stumble over the exact same problem and hopefully fix it. I'm going to be away for a few days but will pick this thread up again when I return on wednesday - I'd like to help with this. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
> 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. The biggest problem is that ``cpp'' will get a sig11 when executed by c++. If I use ``c++ -v'' and manually execute what c++ is, I don't get the sig11. I got tired of trying to track this down, so to get around this (so I could work on libstdc++), I copy ``cpp'' into /usr/libexec from a copy of an installed EGCS port. The version in my repository is EGCS 1.1.2-pre3. Rumors have it that 1.1.2 will released on Friday, and by Monday at the latest. > What's the preferred method for tracking your egcs work, given one On a test box, one should CVSup using: *default host=relay.nuxi.com *default base=. *default release=cvs *default delete use-rel-suffix egcs I create a directory separate from our repository to sup into. Then checkout (``cvs -d co src/gnu src/contrib/egcs'') into a directory separate from /usr/src. 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. -- -- 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 message
Re: bmake/contrib framework for egcs
> 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 to /usr/src in that you will find "src/gnu/usr.bin/cc", > "src/gnu/lib/libstdc++", and "src/contrib/egcs". How's this going? I didn't quite get the same results when I tried overlapping cvs checkouts of the base bits and your own repository, but then LinuxWorld came up and I never got back to trying this again. What's the preferred method for tracking your egcs work, given one completely spammable box, a CVS repository (the project's), a network connection and plenty of disk space? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
> 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 use-rel-suffix egcs To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: bmake/contrib framework for egcs
"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 CVS tree > corresponds to /usr/src in that you will find "src/gnu/usr.bin/cc", > "src/gnu/lib/libstdc++", and "src/contrib/egcs". It would help a lot if you could make it CVSUPpable :-). Those of us in the third world would greatly appreciate that! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message