Xref: utzoo comp.sources.d:4069 comp.sys.ibm.pc:34954 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!ucrmath!proton!muon!baumann From: baumann@muon.uucp (Michael Baumann) Newsgroups: comp.sources.d,comp.sys.ibm.pc Subject: Re: Problems compiling Gnuplot w/ TC 2.0 Keywords: linking, error, Gnuplot, TC 2.0 Message-ID: <497@proton.UUCP> Date: 19 Sep 89 21:24:44 GMT References: <1077@lakesys.UUCP> <25879@iuvax.cs.indiana.edu> Sender: news@proton.UUCP Reply-To: baumann@muon.UUCP (Michael Baumann) Distribution: usa Organization: Loma Linda U. Rad. Research Lab, Loma Linda Lines: 31 >I've been bitten by this a few times, and it's rally frosting me. >What's happening is that TC2.0 (unlike previous versions) no longer >accepts lines that are delimited by ^J only --- it demands ^M^J. By >archiving on a probably-UNIX machine, then unarchiving to MSDOS, your >source files didn't get the end-of-lines converted. > >I don't know why TC compiles without errors, but if you look at the .OBJ >files I believe yo'll see that they're way too small. Basically there >isn't anything to link, including any _main(). Fix up the ^J's and you >should be okay. > >TC2.0 also made one executable grow by 25% over TC1.5. I think Borland >has convinced me not to "upgrade" to inferior successor packages. Curiouser and curiouser.... A couple of points to make regarding the preceeding statements. 1) How TC2.0 handles ^J or ^J^M verses TC1.5 should be a moot point. No where in the definition of the C language are new-lines (however you want to make 'em) defined as required for ANY statement. They are WHITE SPACE. To be consumed by the Lexical Analyzer. They should Never be seen by the parser. 2) When you made your comparison of TC2.0 vs TC1.5 were ALL options the same? Including supression of debugger support? Michael Baumann Radiation Research Lab |Internet: baumann%proton.UUCP@ucrmath.UCR.EDU Loma Linda Universtiy Medical Center | UUCP: ...ucrmath!proton!baumann Loma Linda, California. (714)824-4077|