Message-Id: <199801060854.KAA06337@ankara.duzen.com.tr> Comments: Authenticated sender is From: "S. M. Halloran" Organization: User RFC 822- and 1123-Compliant To: Robert Hoehne Date: Tue, 6 Jan 1998 10:34:46 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Subject: Re: Bug Report: RHide CC: djgpp AT delorie DOT com In-reply-to: <34B124C3.D9D99A6D@gmx.net> Content-Transfer-Encoding: 8bit Precedence: bulk On 5 Jan 98, Robert Hoehne was found to have commented thusly: > S. M. Halloran wrote : > > [...] > > (2) [B] Likely a 'gcc' error: in linking phase, the message window > > reports for duplicated external references the following (an > > example): > > > > Creating: rasse.exe > > Error: ../obj/chem.o: In function `LinkHNum': > > chem.c(95) Error: multiple definition of `LinkHNum' > > o:checkcyc.c(263) Error: first defined here > > > In my opinion this is not a bug in RHIDE but in the way, how > you created checkcyc.o. Probably you have compiled it > > gcc -g -c o:checkcyc.c > > then you changed the current directory on drive o and then linked > in your program checkcyc.o. But from your commandline in the > checkcyc.o is as sourcename the name o:checkcyc.c stored and now > what do you expect from RHIDE. Should it scan the complete drive > o for finding the file checkcyc.c? > > Solutions for you: > > - Compile the file with a full pathname as source file (makes sense > when using the stabs patched gcc) > - Compile the file only with a filename and then set in the RHIDE > search path for source files the path to the sources. But I did not (pre-)compile the file at all. All files are listed in the project, and all command lines to gcc are setup through RHide. Files are inserted into the project through the Add dialog, and so RHide controls the whole ball of wax. Moreover, there is no drive 'o' on my system, and never has been (drive C is the uncompressed part of the hard drive; drive F is a compressed 'partition' of the hard drive) The output example above is to the message window presented by RHide. Since RHide is just passing on to the Message window what gcc reports, the error must clearly be in gcc...although I don't discount the possibility of a configuration problem. I may try to set up a makefile for this to see if gcc does the same thing. gcc and all of the entire djgpp distribution is placed on drive F, while the project files are all on drive C and objects generated also placed there (the standard object/library files that come with djgpp are, of course, on drive F). Perhaps there is a confusion of drives to gcc. > > > opens an empty window at position 1:1 with no source. The problem is > > the 'o:' part. > > Exact. But this is your fault. Again, I pass no command lines to gcc (RHide does) and get all my messages from gcc (through RHide). I protest my innocence :) > > (3) [B] Editor error: In some cases, the editor loses track of the > > Snippet from the rhide_ch.log > ----------- > 30.09.1997: Released version 1.4 > > 02.10.1997: Fixed a bug in the editor (from SET) which happens in some > special situations (autondent, optimal fill, tabsize 8) > ------------ I paste here a copy of the RHide dialog box regarding this set of options: +-[_]----------- Global Options ----------------+ ¦ ¦ ¦ [X] Autoindent ¦ ¦ [X] Use tabs ¦ ¦ [ ] Persistent blocks ¦ ¦ [X] Inteligent C indent ¦ ¦ [ ] Column cursor ¦ ¦ [ ] Row cursor ¦ ¦ [X] Match pair highlight ¦ ¦ [ ] Don't move the cursor on Paste ¦ ¦ [ ] Transparent Blocks ¦ ¦ [X] Optimal Fill ¦ ¦ ¦ ¦ Tab size ¦ ¦ 4 ¦ ¦ ¦ ¦ To all _ OK _ Cancel _ ¦ ¦ ________ ________ __________ ¦ +-----------------------------------------------+ [...] Mitch Halloran Research (Bio)chemist Duzen Laboratories Group Ankara TURKEY mitch AT duzen DOT com DOT tr other job title: Sequoia's (dob 12-20-95) daddy