oddjob@oz.plymouth.edu (Andrew C. Stoffel) (01/13/91)
In article <41444@nigel.ee.udel.edu> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >I got some messages indicating that I should state: >The problems you encounter when compiling c68 with ACK are most >probably due to bugs in the old ld/cv programs. >They fail on big programs although you cannot be sure they fail. Any way to tell ? I got c68 to compile (eventually) and would like to know if it is any good (at least to recompile itself) >There is a new linker which combines ld/cv functionality (Author: >F. Croes) which should be used instead of cv/ld where is it and what is it called ??? >The cc.c posted along with c68 II.5 supports the new linker. Where can I find that ???!!! cc.c wasn't in the recently posted version of c68 (that also includes the 386 version) >C.v.W. an additional question: how big should the library created with the floating point stuff (for the version of c68 mentioned above) be ?? Thanx -Andy- -- |"The Snark WAS a Boojum, you see!"|Good : acs@unhd.unh.edu | |"Reality !?! Isn't that something |Better : ANDYS@psc.plymouth.edu | | you sprinkle on ice ??" |Best : oddjob@oz.plymouth.edu |
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (01/14/91)
You can use c68 as your standard C compiler. I never use ACK, everything (OS, library, commands,....) is compiled with c68. You will get much shorter compilation times and quicker code. The c68-compiled library (with the floating point functions) is as long as the ACK-compiled library, I remember it is slightly shorter. The floating point stuff is only some bytes. A cc.c that supports c68 was posted with c68, Version II, patchlevel 5. It is trivial, you can do it by hand. The commands to generate for compiling, say, source.c, are: /usr/lib/cpp source.c > /tmp/TEMP_FILE_NAME.i /usr/lib/c68 /tmp/TEMP_FILE_NAME.i /tmp/TEMP_FILE_NAME.s rm /tmp/TEMP_FILE_NAME.i /usr/bin/as - /tmp/TEMP_FILE_NAME.s -o source.o You need not change code in cc.c, just change some table entries. C.v.W.
pnakada@oracle.com (Paul Nakada) (01/14/91)
Something to be wary of.. When using /usr/lib/cpp, I got an error of the type Cannot find include file "foo.h" where foo.h was obviously in my include path.. on a whim, I chmem'd +100000 /usr/lib/cpp and everything was hunky dory. An odd error message for lack of memory. This never came up before because the ACK compiler doesn't use cpp. Thanks for your work Christoph! -Paul Nakada -- Paul Nakada | Oracle Corporation | pnakada@oracle.com
marc@uni-paderborn.de (Marc Gumbold) (01/16/91)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >[...] >A cc.c that supports c68 was posted with c68, Version II, patchlevel 5. >It is trivial, you can do it by hand. >The commands to generate for compiling, say, source.c, are: >/usr/lib/cpp source.c > /tmp/TEMP_FILE_NAME.i >/usr/lib/c68 /tmp/TEMP_FILE_NAME.i /tmp/TEMP_FILE_NAME.s >rm /tmp/TEMP_FILE_NAME.i >/usr/bin/as - /tmp/TEMP_FILE_NAME.s -o source.o I did just that with my ACK-compiled c68. But whenever I feed cpp output to c68 it will produce almost empty (besides text ..., data ...) .s-Files. Is that the kind of misbehaviour of ACK-compiled c68 you referred to in your earlier posting? If I compile a "hello world" free of cpp commands with c68, it works fine; I get a correct .s-File which I can get to run (with "old" linker and cv). BTW: Where can I find the new ld/cv you mentioned? >You need not change code in cc.c, just change some table entries. Having no source of cc (as is the default with normal Minices) that is going to be difficult... :-) So: Suitable cc and/or new ld/cv ftp'able from somewhere? >C.v.W. -- Marc Gumbold EMail: marc@uni-paderborn.de Phone(home): +49 5234 5319 grad CS stud Snail(home): Nordstr. 29, 4934 Horn-Bad Meinberg, Germany ------ "Forty-two," said Deep Thought, with infinite majesty and calm. -------
be@arium.stgt.sub.org (Bernd Ebach) (01/23/91)
For all haveing problems compiling c68 und ACK:
Try -DICODE
this should make c68 produceing no more empty *.s files
So CCFLAGS extends to a total of:
-O -DM68000 -DNOFLOAT -DICODE
TschauTschau
Bernd
--
---------------------------------------------------------------
be@arium.stgt.sub.org | be@aragon.gtc.de | ud01@kauni2.bitnet
(if all else fails try: ud01@ibm3090.rz.uni-karlsruhe.dbp.de)
---------------------------------------------------------------holger@pac.uucp (Holger Lesch) (01/23/91)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >I got some messages indicating that I should state: >The problems you encounter when compiling c68 with ACK are most >probably due to bugs in the old ld/cv programs. >They fail on big programs although you cannot be sure they fail. >(for a long time, I was using them, too). >There is a new linker which combines ld/cv functionality (Author: >F. Croes) which should be used instead of cv/ld >The cc.c posted along with c68 II.5 supports the new linker. >C.v.W. Very nice ! I`ve got several problems running a ACK-compiled c68 (signal 11, no output ...), so where can I get this new linker ? Could anybody post it to me ? in anticipation Holger -- e-mail: mcvax!unido!tub!pac!holger snail mail: holger@pac.uucp Holger Lesch holger%pac%tub.BITNET@MITVMA.MIT.EDU PAC Technology GmbH fax: +49 30 341 07 99 Fritschestrasse 27-28
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (01/25/91)
The new ld was posted to this newsgroup last year, Try some of the archives. C.v.W. P.S. your error message is not typical. Most users complain c68 dies silently
bert@arrakis.nl.mugnet.org (Bert Laverman) (01/25/91)
In article <1991Jan23.134705.8544@pac.uucp>, holger@pac.uucp (Holger Lesch) wrote: > HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >>... >>There is a new linker which combines ld/cv functionality (Author: >>F. Croes) which should be used instead of cv/ld >>... > Very nice ! > > I`ve got several problems running a ACK-compiled c68 (signal 11, no output > ...), so where can I get this new linker ? Could anybody post it to me ? I found a copy of it at plains, but it is _very_ Minix-ST 1.1. If someone has a 1.5.10 compilable version, then by all means: POST IT. Greetings, Bert
bert@arrakis.nl.mugnet.org (Bert Laverman) (01/27/91)
In article <42688@nigel.ee.udel.edu>, HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) wrote: > The new ld was posted to this newsgroup last year, > Try some of the archives. If someone finds an archive that has a Minix ST 1.5.10 compilable version, _please_ mail me. All I find are 1.1 versions, and that won't compile... > C.v.W. > P.S. your error message is not typical. Most users complain c68 dies silently My c68 (version 3) compiled with version 2 (patchlevel something) dies on unknown identifiers. I was just getting used to it when I read the above. Bert ===================================================================== Bert Laverman email: bert@arrakis.nl.mugnet.org Molukkenstraat 148 work: laverman@cs.rug.nl 9715 NZ Groningen The Netherlands tel.: +31 50 - 733587 "The ability to produce garbage is a sign of power." -J.B. Goodenough (at RMISE workshop on Software Reuse) =====================================================================