noel@ubbs-nh.MV.COM (N. Del More) (01/12/91)
Finally got all of the pieces to ecu3, including patch1, but for some reason I am unable to get it to compile. Part of the problem is I am not a programmer and the Makefile (Make.ecu) is a bit beyond my ability to comprehend it. In particular it is not clear what modifications should be made to SYSTEM, COMFLAGS and LDFLAGS. The other part of the problem is a number of warning messages and fatal errors incountered during compilation. I recieve a number of warnings about M_Termcap redirection in those files utilizing /usr/include/curses.h, one error at link stage concerning _calloc being defined twice in /lib/386/Slibc.a(calloc.o) and one fatal error in ecuutil.c about unresollved externals by /bin/ld concerning _memmove. I have attempted to modifiy the makefile in many different ways, but regardless, it always bombs in exacxtly the same manner. Any ideas???? Thanks Noel -- Noel B. Del More | decvax!ubbs-nh!noel 17 Meredith Drive | noel@ubbs-nh.mv.com Nashua, New Hampshire 03063 | It's unix me son! `taint spozed tah make cents -- Noel B. Del More | decvax!ubbs-nh!noel 17 Meredith Drive | noel@ubbs-nh.mv.com Nashua, New Hampshire 03063 | It's unix me son! `taint spozed tah make cents
steve@nshore.uucp (Stephen J. Walick) (01/13/91)
As quoted from <4396@ubbs-nh.MV.COM> by noel@ubbs-nh.MV.COM (N. Del More): +--------------- | ...one error at link stage concerning | _calloc being defined twice in /lib/386/Slibc.a(calloc.o) and one | fatal error in ecuutil.c about unresollved externals by /bin/ld | concerning _memmove. +--------------- After days of trying to "hack" at the source, I've finally given up and this article by N. Del More is about the same problem that I've encountered, viz., "calloc.o". It's been driving me buggy! Does anyone have an insite as to why I too am receiving this "_calloc" error. THANKS to anyone who can help out with this. Regards.... Steve Walick -- Stephen J. Walick, Asst Sysop of the < XBBS > program at NCoast.ORG {uunet|backbone}!ncoast.org!nshore!steve nshore!steve@ncoast.org
bbs00361@uafcseg.uucp (Jose Gomez) (01/14/91)
To compile ecu3, remove all malloc references in the makefile and in ecu.h. Undefine the #define MALLOC_3X to #undef MALLOC_3X in ecu.h and remove the -lmalloc from the $(LDFLAGS) declaration. I have it running and works fine.
aris@tabbs.UUCP (Aris Stathakis) (01/15/91)
In comp.unix.xenix.sco you write: >Finally got all of the pieces to ecu3, including patch1, but for some >reason I am unable to get it to compile. Mhh I had some trouble too, but got around it. >I recieve a number of warnings about M_Termcap redirection in those files >utilizing /usr/include/curses.h, one error at link stage concerning >_calloc being defined twice in /lib/386/Slibc.a(calloc.o) and one >fatal error in ecuutil.c about unresollved externals by /bin/ld >concerning _memmove. To get rid of the _memove problem , just ad a -DDUFF in the CFLAGS line in the Makefile. To get rid of the _calloc being defined twice, i had to do a REAL jippo job. First, I extracted the calloc.o file from /lib/386/Slibc.a (using 'ar'). Then I went in with a binary editor and changed the one _calloc definition to _xalloc (so it wouldn't clash with the other _callot in that file) then replaced this modified calloc.o back into /lib/386/Slibc.a and then compiled. >I have attempted to modifiy the makefile in many different ways, but >regardless, it always bombs in exacxtly the same manner. I'm no programmer either, but i've learned how to fiddle around enough to get stuff to compile :-) I suspect the problem is that the author is using the 2.3.1 development system and i'm only using 2.3.0. Aris -- Aris Stathakis | Bang: ..!uunet!ddsw1!olsa99!tabbs!aris or aris@tabbs.UUCP - UNIX is like sex - if you've tried it, you can't get along without it. - - If you haven't you really have no idea what the fuss is all about! -
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (01/17/91)
In article <1991Jan13.040319.7912@nshore.uucp> steve@nshore.uucp (Stephen J. Walick) writes: >As quoted from <4396@ubbs-nh.MV.COM> by noel@ubbs-nh.MV.COM (N. Del More): > >+--------------- >| ...one error at link stage concerning >| _calloc being defined twice in /lib/386/Slibc.a(calloc.o) and one >| fatal error in ecuutil.c about unresollved externals by /bin/ld >| concerning _memmove. >+--------------- > >After days of trying to "hack" at the source, I've finally given up >and this article by N. Del More is about the same problem that I've >encountered, viz., "calloc.o". It's been driving me buggy! Does >anyone have an insite as to why I too am receiving this "_calloc" >error. THANKS to anyone who can help out with this. Bug reports to the author are soliticted in the README and may prove helpful :-). 1 On some or all XENIX, there is no memmove: Add -DDUFF to the CFLAGS. 2. -lmalloc is broken on some/most XENIX. a. edit ecu.h and comment out the line '#define MALLOC_3X' b. remove -lmalloc from the LDFLAGS assignment in the make file 3. The M_TERMCAP redefinitions are a result of how you installed curses when you installed XENIX. The SCO curses.h file should test for #ifdef M_TERMCAP before defining itself, but it doesn't. The code will compile/work properly despite the warnings. ----------------------------------------------------------------------- Warren Tucker, March Hare gatech!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "Tell the moon; don't tell the March Hare: He is here to look around."
goer@quads.uchicago.edu (Richard L. Goerwitz) (01/26/91)
In <1991Jan14.202320.4315@tabbs.UUCP> aris@tabbs.UUCP (Aris Stathakis) writes: > >>Finally got all of the pieces to ecu3, including patch1, but for some >>reason I am unable to get it to compile. > >Mhh I had some trouble too, but got around it.... > >To get rid of the _calloc being defined twice, i had to do a REAL jippo >job. First, I extracted the calloc.o file from /lib/386/Slibc.a (using >'ar'). Then I went in with a binary editor and changed the one >_calloc definition to _xalloc (so it wouldn't clash with the other _callot >in that file) then replaced this modified calloc.o back into /lib/386/Slibc.a >and then compiled. Ouch. I've just run into a situation where I have a calloc function defined amidst a bunch of regular .o object modules. I direct the linker to search the tcap library (among others) for unresolved references in the normal way (-ltcap). Unfortunately, when /bin/ld starts to link in routines from that library, it ignores the .o object modules, and heads straight for my C library. When it finds calloc.o there, it then complains of a redefinition problem and then aborts. I suspect that there is an easier way to handle this problem, but that I'm just not seeing it. Xenix/386 2.3.2 + 2.3.0 dev sys -Richard
ache@hq.demos.su (Andrew A. Chernov) (01/28/91)
Hi, hackers.
I win it! Some functions from standard C library needs cfree. This
^^^^^
function lives in the same module with calloc. This cause an error
with calloc in -lmalloc. I wrote dumb module named cfree.c:
void cfree(s)
char *s;
{
free(s);
}
and add cfree.o to the module list in Make.ecu.
Everything appears OK!
--
In-Real-Life: Andrew A. Chernov | Domain: ache@hq.demos.su,
Zodiac-Sign: Virgo | ache%hq.demos.su@relay.eu.net
Organization: DEMOS Coop., | Phone: +7 095 2312129
Moscow, Russia | Fax: +7 095 2335016simon@ms.uky.edu (G. Simon Gales) (01/28/91)
In article <1991Jan27.194020.9849@hq.demos.su> ache@hq.demos.su (Andrew A. Chernov) writes: >I win it! Some functions from standard C library needs cfree. This >function lives in the same module with calloc. This cause an error >with calloc in -lmalloc. I wrote dumb module named cfree.c: > >void cfree(s) >char *s; >{ > free(s); >} > >and add cfree.o to the module list in Make.ecu. I did it the hard way, and extracted 'calloc.o' from Llibc.a and hacked calloc into xalloc, then re-built Llibc.a. This seems to get around the problem, although you have to swap the old library back in to compile the zmodem programs. This seems to be a problem with SCO's dev kit, but I cannot find a fix for it from SCO. I have Xenix 286 2.2.3, is the problem there in 2.3.2? Well, now I've got ecu compiled and installed, but when run, I get the 1-line copyright message then a segmentation violation. Sigh... -- Simon Gales@The University of Kentucky simon@ms.uky.edu simon@UKMA.BITNET {rutgers, uunet}!ukma!simon
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (01/29/91)
In article <1991Jan28.121309.4163@ms.uky.edu> simon@ms.uky.edu (G. Simon Gales) writes: >In article <1991Jan27.194020.9849@hq.demos.su> ache@hq.demos.su (Andrew A. Chernov) writes: >>I win it! Some functions from standard C library needs cfree. This >>function lives in the same module with calloc. This cause an error >>with calloc in -lmalloc. I wrote dumb module named cfree.c: >> >>void cfree(s) >>char *s; >>{ >> free(s); >>} >> >>and add cfree.o to the module list in Make.ecu. > >I did it the hard way, and extracted 'calloc.o' from Llibc.a and hacked >calloc into xalloc, then re-built Llibc.a. This seems to get around the >problem, although you have to swap the old library back in to compile the >zmodem programs. > >Well, now I've got ecu compiled and installed, but when run, I get the >1-line copyright message then a segmentation violation. Sigh... Hmmmm. Please don't stop there! I would appreciate any and all feedback on ECU. I have about two man years in it and enjoy it's use every day. I haven't had access to a XENIX system for regular testing for two years now, but I know of three machines it runs on regularly. Perhaps you should recompile using patch 3 and 4 (coming out of c.s.m soon) and try it as released. The one liner non-copyright message is for the benefit of 286 users (initialization takes a few seconds on this machine :-<). A great deal of malloc activity takes place after the quick response message. My advice is to undefine MALLOC_3X in ecu.h and remove -lmalloc from the lib line. This is what patch 3 does... (most of the patches are for non-ANSI console support). Another quick fix, coming soon in a patch near you: in nonansikey.c, near line 66, replace 'token_separator[2]' with 'token_separator[8]' (3 will do, but be safe; patch 4 will fix it in other ways). I hope you enjoy using ecu. I know one enterprising individual who runs ecu out of a cron job to call a list of BBSs at night and up/download his mail. This, of course, is somewhat beyond the features of your normal cu ;-). ----------------------------------------------------------------------- Warren Tucker, March Hare gatech!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. -Edmund Burke