wong@scapa.cs.UAlberta.CA (Brian Wong) (02/22/91)
Hi, I recently download dj1bin (36 parts) from c.b.i.p. I have 2 questions: 1. I use 'gcc c.c' on my 386 with DOS 4.01 and the compiler comes up with the error message: d:\gcc\cpp: d:\/ccAA_AAA.cpp: access denied What can I do to fix this? 2. The readme file mentions some other docs like doc.arc and inc.arc. Will they appear in c.b.i.p soon? Thanks a lot! Brian
iws9012@eva.fmi.uni-passau.de (Thomas Opheys) (02/22/91)
You had problems with the file names. Understand that GNU C++ has come from the
UNIX platform. In the README file you see that you have to tell the C compiler
where to find the libraries, includes etc. Important is that every file name
you use with GNU C has to use the "/" instead of the DOS-like "\". So if you
want to compile c:\c\test.c, use "gcc c:/c/test.c"! The same is with the env-
vironment variables GCCBIN, GCCLIB etc. Look at the README file. The example
correctly uses the "/" character.
Another problem you might have is the "parse error". I found out that the
EOF character that nearly every DOS text file ends with produces this error.
GCC won't compile any such file correctly. I wrote a little Turbo Pascal
program that looks if a text file ends with the EOF character and then over-
writes it with a space.
program StripEOF;
uses crt,dos;
var MyFile : file of byte;
b : byte;
begin
assign(MyFile,paramstr(1));
reset(MyFile);
seek(MyFile,FileSize(MyFile)-1);
read(MyFile,b);
if b=26
then begin
seek(MyFile,FileSize(MyFile)-1);
b:=32;
write(MyFile,b);
end;
close(MyFile);
end.
(Don't remember my program exactly but this should do it. Cou can write a batch
file for editing ".c" files like
@echo off
editor %1.c
stripEOF %1.c
The cp commands in INSTALL.BAT have to be removed by "copy". The author surely
mixed up UNIX and DOS.
I ran into the same problems you did but when these were solved, the compiler
works smooth.
Perhaps you can help me, too: My machine lacks a 387 coprocessor and so the
compiler refuses to compile programs that use real math. I tried a 387 emu-
lation, FRANKE.387, but my computer crashed. Could anyone send me some good
387 emu that works with GNU C++? (thanks).
I downloaded some more for GNU C++ from the site mentioned in the README file.
The site mentioned there just allows you to GET the readme file where you can
read that it changed its name. Don't know it exactly but try it.
But it looks as if the next parts (headers and libraries, ...) are being posted
to c.b.i.p right now...
Thomas Opheys iws9012@eva.fmi.uni-passau.de
-------------------------------------------------------------------------------
I like SLEDGE HAMMER. What's wrong with me?
-------------------------------------------------------------------------------veit@du9ds3.uni-duisburg.de (Holger Veit) (02/22/91)
In <1991Feb21.195421.15820@cs.UAlberta.CA> wong@scapa.cs.UAlberta.CA (Brian Wong) writes: >Hi, I recently download dj1bin (36 parts) from >c.b.i.p. I have 2 questions: >1. I use 'gcc c.c' on my 386 with DOS 4.01 and the compiler > comes up with the error message: > d:\gcc\cpp: d:\/ccAA_AAA.cpp: access denied > What can I do to fix this? Not a solution, but probably an explanation. gcc was compiled as is, i.e. from the GNU UNIX sources, thus also using the UNIX pathname convention. Probably you have not set the necessary environment variables according to that style (dont write D:\ANYWHERE, but instead D:/ANYWHERE), or there is really a problem with DOS 4.01. I still use 3.3, and it works fine (BTW: it is apparently a hidden feature of the MSDOS Kernel (INT21) to accept Unix style path names. It is just the F* COMMAND.COM that prevents e.g. using RENAME as a MOVE, and other nice features). >2. The readme file mentions some other docs like > doc.arc and inc.arc. Will they appear in c.b.i.p soon? I think they are just appearing. >Thanks a lot! >Brian logout Holger Veit veit@du9ds3.uni-duisburg.de -- | | / Holger Veit | INTERNET: veit@du9ds3.uni-duisburg.de |__| / University of Duisburg | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO | | / Fac. of Electr. Eng. | UUCP: ...!uunet!unido!unidui!hl351ge | |/ Dept. f. Dataprocessing |
gtoye@supernet.dallas.haus.com (Gene Toye) (02/23/91)
iws9012@eva.fmi.uni-passau.de (Thomas Opheys) writes: >Perhaps you can help me, too: My machine lacks a 387 coprocessor and so the >compiler refuses to compile programs that use real math. I tried a 387 emu- >lation, FRANKE.387, but my computer crashed. Could anyone send me some good >387 emu that works with GNU C++? (thanks). I would like that too. If anyone knows of one, please post to c.b.i.p or post the name of an FTP site (or both!). Thanks! -- Gene Toye: Harris Adacom Corporation / 16001 Dallas Pkwy. / Dallas, TX 75248 Internet: gtoye@supernet.haus.com or gtoye@supernet.lonestar.org Usenet: uunet!{iex,ntvax}!supernet!gtoye DISCLAIMER: My employer never knows what I am going to say next.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/23/91)
In article <veit.667235355@du9ds3> veit@du9ds3.uni-duisburg.de (Holger Veit) writes: | it is apparently a hidden feature of the MSDOS Kernel (INT21) to accept | Unix style path names. It is just the F* COMMAND.COM that prevents e.g. | using RENAME as a MOVE, and other nice features). Nope, the programmer's ref for v2.0 said either could be used, and that command.com by default would use / as a switch and \ as a path, but would use / for the path delimiter if any other character was chosen. I think that's still documented, and it's certainly still true. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
hp0p+@andrew.cmu.edu (Hokkun Pang) (02/24/91)
it seems to me that gcc doesn't work with extended memory managers like himen.sys or qemm.sys.is there a fix to this?
herrickd@iccgcc.decnet.ab.com (daniel lance herrick) (02/27/91)
In article <1991Feb22.142316.1380@forwiss.uni-passau.de>, iws9012@eva.fmi.uni-passau.de (Thomas Opheys) writes: > > Perhaps you can help me, too: My machine lacks a 387 coprocessor and so the > compiler refuses to compile programs that use real math. Looks like you'll just have to get along with imitation math. dan
traub@rtf.bt.co.uk (Michael Traub) (02/27/91)
In <1991Feb21.195421.15820@cs.UAlberta.CA> wong@scapa.cs.UAlberta.CA (Brian Wong) writes: >Hi, I recently download dj1bin (36 parts) from >c.b.i.p. I have 2 questions: >1. I use 'gcc c.c' on my 386 with DOS 4.01 and the compiler > comes up with the error message: > d:\gcc\cpp: d:\/ccAA_AAA.cpp: access denied > What can I do to fix this? Most likely you have your TMP environment variable set to d:\. This hurts gcc in two ways: 1. It prefers unix style slashes, 2. It seems to add a slash to the front of temporary filenames (not entirely sure about this as I don't have the sources) So to solve this problem: Set TMP=d: should do the trick. Don't try setting GCCTMP as TMP over-rides this (even though the docs indicate otherwise). Setting TMP to d: shouldn't break any of your DOS software either. Michael Traub BT Customer Systems, Brighton Systems Centre. traub@rtf.bt.co.uk
wnp@iiasa.ac.at (Wolf PAUL ) (02/27/91)
In article <3282@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >In article <veit.667235355@du9ds3> veit@du9ds3.uni-duisburg.de (Holger Veit) writes: > >| it is apparently a hidden feature of the MSDOS Kernel (INT21) to accept >| Unix style path names. It is just the F* COMMAND.COM that prevents e.g. >| using RENAME as a MOVE, and other nice features). > > Nope, the programmer's ref for v2.0 said either could be used, and >that command.com by default would use / as a switch and \ as a path, but >would use / for the path delimiter if any other character was chosen. I >think that's still documented, and it's certainly still true. Unfortunately it is no longer true, or if so, the way to tell COMMAND.COM to use a different switch char has been changed. None of the utilities (p.d. and i.e., MKS Toolkit) which used to fix the switch character in DOS under 3.2 work in the newer versions of DOS. They seem to work, in that after you do a "switch -" they will report that the switch character is "-", but when you try a "cd /" you will get a "Invalid Switch" error message. If anyone knows of a fix for this, PLEASE let us know! Wolf Paul -- W.N.Paul, Int. Institute f. Applied Systems Analysis, A-2361 Laxenburg--Austria PHONE: +43-2236-71521-465 INTERNET: wnp%iiasa@relay.eu.net FAX: +43-2236-71313 UUCP: uunet!iiasa!wnp HOME: +43-2236-618514 BITNET: tuvie!iiasa!wnp@awiuni01.BITNET
valley@uchicago (Doug Dougherty) (02/27/91)
wnp@iiasa.ac.at (Wolf PAUL ) writes: >In article <3282@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >>In article <veit.667235355@du9ds3> veit@du9ds3.uni-duisburg.de (Holger Veit) writes: >> >> Nope, the programmer's ref for v2.0 said either could be used, and >>that command.com by default would use / as a switch and \ as a path, but >>would use / for the path delimiter if any other character was chosen. I >>think that's still documented, and it's certainly still true. >Unfortunately it is no longer true, or if so, the way to tell >COMMAND.COM to use a different switch char has been changed. >None of the utilities (p.d. and i.e., MKS Toolkit) which used to fix >the switch character in DOS under 3.2 work in the newer versions of >DOS. They seem to work, in that after you do a "switch -" they will Which version(s) of DOS are you talking about? The only DOS that works with a version # greater than 3.2 is 3.3 (or 3.31) and I'm pretty sure the INT 21, fn 37 method works under 3.3. You aren't, by any chance, actually thinking of using a DOS (?) whose version # starts with a 4, are you?
bobg@masscomp.westford.ccur.com (Bob Getz) (03/01/91)
Hello, netlanders; I recently got the GNU C++ for DOS via ftp from grape..... I tried to compile a very simple test program and got the following: e:\gcc test.cpp ld: malformed input file (not rel or archive) test.cpp e:\> I'm running COMPAQ DOS 3.31 and I have the following in my autoexec.bat: set gccbin=e:/usr/local/bin set gccinc=e:/usr/include set gcclib=e:/usr/lib set gcctmp=e:/usr/tmp path c:\;C:\DOS;C:\BIN;C:\UEMACS;E:\TC\BIN;e:\td;e:\tasm;e:\usr\local\bin Please, help me!!!! It must be something simple. Thanks, in advance Bob Getz bobg@westford.ccur.com (508)392-2431
sweh@tharr.UUCP (Stephen Harris) (03/01/91)
In article <3282@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > Nope, the programmer's ref for v2.0 said either could be used, and >that command.com by default would use / as a switch and \ as a path, but >would use / for the path delimiter if any other character was chosen. I >think that's still documented, and it's certainly still true. I think that the INT21 function which changes the switch character was new to DOS 3.0. Also DOS4 seems to ignore the setting of this switch. ef if you set the switch character to a - then on DOS3.30 dir -w c:/ works, but on DOS4 it still demands dir /w c:\ A real pain when using MKS Tools in the KornShell! -- Stephen Harris Disclaimer: me have an opinion? | Email: ..!ukc!axion!tharr!sweh What an idea! | sweh%tharr.uucp@uk.co.bt.axion Wanted: humour transplant | tharr!sweh@uk.ac.ukc <-- tharr *free* public access to Usenet in the UK 0234 261804 -->
kirchner@informatik.uni-kl.de (Reinhard Kirchner) (03/01/91)
From article <61762@masscomp.westford.ccur.com>, by bobg@masscomp.westford.ccur.com (Bob Getz): > > Hello, netlanders; > > I recently got the GNU C++ for DOS via ftp from grape..... > > I tried to compile a very simple test program and got the following: > > e:\gcc test.cpp > ld: malformed input file (not rel or archive) test.cpp > e:\> > A friend of mine tried the gcc and he told me: Source files MUST NOT HAVE Control-Z at their end. This maz be the reason for the error above. This is a real foolish problem in such a tremendous package. Control-Z is standard from many editors, the authors should have checked this. Reinhard Kirchner Univ. Kaiserslautern, Germany kirchner@uklirb.informatik.uni-kl.de
jimp@cognos.UUCP (Jim Patterson) (03/01/91)
In article <61762@masscomp.westford.ccur.com> bobg@masscomp.westford.ccur.com (Bob Getz) writes: >I recently got the GNU C++ for DOS via ftp from grape..... >I tried to compile a very simple test program and got the following: > ld: malformed input file (not rel or archive) test.cpp >path c:\;C:\DOS;C:\BIN;C:\UEMACS;E:\TC\BIN;e:\td;e:\tasm;e:\usr\local\bin >Please, help me!!!! It must be something simple. Thanks, in advance Try taking \TC\BIN out of your path. It appears that Turbo C and Gnu CC both use the "usual" names for the compiler passes e.g. CPP, so if your path points to Turbo C first it will run some passes out of the wrong directory. I've got a similar setup (Compaq with Turbo C) and I noticed a similar problem. I don't know how I'm going to get TC and GCC to coexist yet. -- Jim Patterson Cognos Incorporated UUCP:uunet!mitel!cunews!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 x6112 3755 Riverside Drive NOT a Jays fan (not even a fan) Ottawa, Ont K1G 3Z4
veit@du9ds3.uni-duisburg.de (Holger Veit) (03/01/91)
In <7594@uklirb.informatik.uni-kl.de> kirchner@informatik.uni-kl.de (Reinhard Kirchner) writes: >From article <61762@masscomp.westford.ccur.com>, by bobg@masscomp.westford.ccur.com (Bob Getz): >> >> Hello, netlanders; >> >> I recently got the GNU C++ for DOS via ftp from grape..... >> >> I tried to compile a very simple test program and got the following: >> >> e:\gcc test.cpp >> ld: malformed input file (not rel or archive) test.cpp >> e:\> >> >A friend of mine tried the gcc and he told me: >Source files MUST NOT HAVE Control-Z at their end. >This maz be the reason for the error above. >This is a real foolish problem in such a tremendous package. Control-Z >is standard from many editors, the authors should have checked this. >Reinhard Kirchner >Univ. Kaiserslautern, Germany >kirchner@uklirb.informatik.uni-kl.de No! This is not the reason. Same thing happens if you try this on a UNIX machine (at least SUN3 & 4). The real reason is: GCC.EXE is the compiler driver and it decides what to do from the source file extension. If the extension is .c, this is a C-source file as usual; a .o or .a are objects and libraries, .i is preprocessor output and .s is assembler input. Unfortunately, .cpp is not as intended a C-Plus-Plus file - - - and so the C-driver passes this immediately to the linker. Try the extension .cc (this is the c++ extension). Holger Veit -- | | / Holger Veit | INTERNET: veit@du9ds3.uni-duisburg.de |__| / University of Duisburg | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO | | / Fac. of Electr. Eng. | UUCP: ...!uunet!unido!unidui!hl351ge | |/ Dept. f. Dataprocessing |
brian@nsc.nsc.com (Brian Marley) (03/02/91)
In article <7594@uklirb.informatik.uni-kl.de> kirchner@informatik.uni-kl.de (Reinhard Kirchner) writes: >From article <61762@masscomp.westford.ccur.com>, by bobg@masscomp.westford.ccur.com (Bob Getz): >> >> Hello, netlanders; >> >> I recently got the GNU C++ for DOS via ftp from grape..... >> >> I tried to compile a very simple test program and got the following: >> >> e:\gcc test.cpp >> ld: malformed input file (not rel or archive) test.cpp >> e:\> >> >A friend of mine tried the gcc and he told me: > >Source files MUST NOT HAVE Control-Z at their end. > >This maz be the reason for the error above. > >This is a real foolish problem in such a tremendous package. Control-Z >is standard from many editors, the authors should have checked this. > >Reinhard Kirchner >Univ. Kaiserslautern, Germany >kirchner@uklirb.informatik.uni-kl.de The problem is more obvious than that! I made this same mistake. Although I can't comment on ^Z characters (my editor doesn't make them), most of your problem is that you created your source file with a ".cpp" suffix. GCC is not Zortech; it requires a suffix of ".cc" for a C++ source file. The error diagnostic was so strange apparently because GCC uses ".cpp" as the suffix for its pre-processor output; it may have been getting terribly confused. Also, naming the program with simply ".c" will cause the compiler to do a standard C (not C++) compilation, causing the preprocesor pass to complain about mismatched single-quotes in include files (it ignores the // comment markers and gets confused about words like "don't" in the comments...). It would have been nice if the dj1bin distribution had come with basic operating instructions. But you get what you pay for, and this is a GREAT package now that I have it running! Many, many thanks to all those who have contributed! -- Brian Marley, brian@nsc.nsc.com (work) bjmcpm!brian@foxpv2.uucp (home)
bobg@masscomp.westford.ccur.com (Bob Getz) (03/02/91)
Hi Netlanders,
Thanks very much for the responses to my original problem that
appears to be related to having a file named "test.cpp". I forgot to
include that I did try different extensions to the source file. I
remember that they didn't work, but didn't write down the error
printout (OOPS).
I just tried it on my machine and this is what I get out of a
compile attempt now:
e:\gcc test.cc
E:\USR\LOCAL\BIN\GCC.EXE: Program cpp got fatal signal 2.
e:\
Once again all I'm doing is trying to compile the following:
main()
{
cout << "Hello\n";
}
Also, my machine is a 386SX with 4MB of memory running COMPAQ
MSDOS 3.31.
Thanks again for the response, and hopefully you have an answer
for this problem.
Bob Getz
bobg@westford.ccur.comsms@sugar.hackercorp.com (Stanley M. Sutton) (03/03/91)
Perhaps the best solution is for someone to post email, mail-server, and ftp sites from which the actual documentation can be located and downloaded. I'm impressed with the package. In about 20 mins, I converted a program which runs on both the IBM Pc and the Atari ST to compile and run under GCC, with the data arrays increased to 4 MB, same as the ST. Finally, a way to use the 8M on my machine at work.
gtoye@supernet.dallas.haus.com (Gene Toye) (03/03/91)
bobg@masscomp.westford.ccur.com (Bob Getz) writes: > e:\gcc test.cc > E:\USR\LOCAL\BIN\GCC.EXE: Program cpp got fatal signal 2. I had this exact problem and found that the install batch file did not create a copy of cpp.exe as needed. cd \usr\local\bin and copy go32.exe to cpp.exe. This will fix the signal 2 problem. -- Gene Toye: Harris Adacom Corporation / 16001 Dallas Pkwy. / Dallas, TX 75248 Internet: gtoye@supernet.haus.com or gtoye@supernet.lonestar.org Usenet: uunet!{iex,ntvax}!supernet!gtoye DISCLAIMER: My employer never knows what I am going to say next.
bobg@masscomp.westford.ccur.com (Bob Getz) (03/04/91)
Hello again netlanders, Thanks, very much, to all who replied to my pleas for help. It's very nice to get very quick, responsive help to a request for help. As I originally thought the problem turned out to be very simple. There were two problems: 1.) My source file must end with a .cc extension. 2.) DJ Delorie's install.bat (that I downloaded from grape...) was missing a line: copy go32.exe cpp.exe Once I fixed these two problems, my test cases compiled and I ran them (go32 a.out) successfully. Thanks again to everyone that responded!!!!! Bob Getz bobg@westford.ccur.com
ewilliam@afit.af.mil (News System Account) (03/06/91)
carl@p4tustin.UUCP (Carl W. Bergerson) writes: >After using errout to catch the volumnous output, it appeared that >gcc could not abide C++ style (//) comment strings. >I confirmed this fishy behavior with the following simple program. > #include <poisson.h> > main() > { > exit( 0 ); > } >This generated about a dozen errors commencing with one that indicated >the compiler could not tolerate the // comments in the header file. My guess is that the above program was in a file with a '.c' extension. gcc (and most good C compilers) treat files according to their extensions -- in the case of GNU gcc, .c means plain C, .cc means C++, etc. In order to get gcc to accept C++ syle comments, you have to tell it that it is a C++ file! Ed Williams ewilliam@blackbird.afit.af.mil
carl@p4tustin.UUCP (Carl W. Bergerson) (03/06/91)
Last night I tried compiling a simple (MSC 5.1) program with gcc.
After using errout to catch the volumnous output, it appeared that
gcc could not abide C++ style (//) comment strings.
I confirmed this fishy behavior with the following simple program.
#include <poisson.h>
main()
{
exit( 0 );
}
This generated about a dozen errors commencing with one that indicated
the compiler could not tolerate the // comments in the header file.
Can anyone shed some light on what is going on here?
I'd be glad to RTFM, except that no FM has been posted. I don't have ftp
nor ghostscript, but I'd appreciate the FM in anyother form.
Thanks
--
Carl Bergerson uunet!p4tustin!carl
Point 4 Data Corporation carl@point4.com
15442 Del Amo Avenue Voice: (714) 259 0777
Tustin, CA 92680-6445 Fax: (714) 259 0921