Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!ucsd!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!quads.uchicago.edu!goer
From: goer@quads.uchicago.edu (Richard L. Goerwitz)
Newsgroups: comp.unix.xenix.sco
Subject: Re: Help - Compiling ecu3
Message-ID: <1991Jan25.221822.4247@midway.uchicago.edu>
Date: 25 Jan 91 22:18:22 GMT
References: <1991Jan14.202320.4315@tabbs.UUCP>
Sender: news@midway.uchicago.edu (News Administrator)
Organization: University of Chicago
Lines: 30

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