bobmon@iuvax.cs.indiana.edu (RAMontante) (09/12/89)
davek@lakesys.UUCP (Dave Kraft) <1077@lakesys.UUCP> : - -Hi there, -After unsharing the Gnuplot sources (and then archiving them with zoo and ************** the source of the problem, in a sense. -downloading them to my PC), I tried to compile it with TC 2.0 (renaming the -necessary makefile, of course). It compiled ok, but, when it tried to link it, -I got "Undefined symbol '_MAIN' in module C0L" and it stopped cold.. What's 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.
mdfreed@ziebmef.mef.org (Mark Freedman) (09/14/89)
(TC 2.0 also made one executable grow by 25% over TC 1.5 ) The default settings for TC 2.0 cause the debugging information to be added to the executable. Either use TDSTRIP to remove it (comes with the TASM / TDEBUG package), or change the appropriate parameters to eliminate the debugging info. The size of .OBJ files has also increased due to the inclusion of dependancy information. I haven't found a way to eliminate this, but it doesn't affect the size of the .EXE. I've found TC 2.0 to produce .EXE files as small or smaller than previous versions once the parameters are properly specified. (it **WAS** a bit of a shock until I removed the debug info.)
baumann@muon.uucp (Michael Baumann) (09/20/89)
>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|
ralf@b.gp.cs.cmu.edu (Ralf Brown) (09/20/89)
In article <497@proton.UUCP> baumann@muon.UUCP (Michael Baumann) writes: }>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 } }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. The parser doesn't care, but the preprocessor chokes on ^J-only files when processing conditionals. Try compiling a file with no #ifdef, #ifndef, or #if. It will compile properly. -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/46 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? |"Humor is laughing at what you haven't got when you ought to What's that?| have it." -- Langston Hughes
bobmon@iuvax.cs.indiana.edu (RAMontante) (09/20/89)
excerpted from 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 [...] ->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. excerpted from baumann@muon.UUCP (Michael Baumann) <497@proton.UUCP> : -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? Since you asked, instead of assuming... yes, I turned everything off to get things as small as possible. Still the executable grows. Also, as others have pointed out, it is actually the preprocessor that wants the carriage returns. Someone else tells me that Borland are addressing the issue, in response to numerous complaints from people trying to port code from one system to another. I don't keep 2 operating systems on my 8088 box, I just split my activity between home and a VAX at school. My fingers are crossed. -- Bob Montante (bobmon@cs.indiana.edu) | "Oh dear, I think you'll find Computer Science Dept, Lindley Hall 101 | reality's on the blink again." Indiana University | -- Marvin Bloomington, IN 47401 | The Paranoid Android