[814] in Info-AFS_Redistribution
Re: Compiling ATK5.1 from source.
daemon@ATHENA.MIT.EDU (Christer Bernerus)
Mon Jun 1 04:59:31 1992
Date: Mon, 1 Jun 1992 09:42:58 +0200 (MET DST)
From: Christer Bernerus <bernerus@animal.cs.chalmers.se>
To: Info-Andrew <info-andrew@andrew.cmu.edu>, Bob_Dew@alw.nih.gov,
Cc: info-afs@transarc.com
\begindata{text,19723316}
\textdsversion{12}
\template{messages}
OK, third try, let's hope it'll pass this time
Chris
------------------------------------------
My last posting didn't make it to info-afs, and apparently not to
info-andrew either, so here's the posting again. This time presumably
without the "Content-Type: text/plain; charset=US-ASCII" header which
caused at least Transarc's mailer to do strange things.
Repost follows:
I just spent some time digging into the AFS sources.
You probably haven't seen my osi_alloc/free problem if you haven't tried
building ATK with AFS3.2beta.
I have noticed that Transarc seems to have rewritten the rx library so
that they now use the osi_alloc and osi_free routines.
I think the mistake they (sorry Transarc for 3:rd person here) did was
to integrate these routines into xdr.o rather than giving them a
separate module (osi.o), because if it were that way, it would still be
possible to rip out xdr.o from librx.a, compile ATK using the standard
xdr.o (in libc.a), and then putting xdr.o back again.
As things are now, this is impossible without compiling librx.a from
source (if you're lucky enough to have it) after first splitting xdr.c
into xdr.c and osi.c, and only including osi.o into the library used for
ATK builds.
A nicer solution, though, would be to leave out xdr.o (the "core" part,
not osi_ routines) completely from librx.a, and create libxdr.a
containing only xdr.o. That would make life easier for those who want to
build anything with rx on a system that have the xdr routines in libc.a.
However, Transarc isn't the only part to blame here. DEC also seems to
have added new routines into xdr.o, and I also think those who wrote the
linker could have provided an option to disregard multiple definitions,
just picking the first one and issuing a warning. As things are now, the
linker exits with an error code, and the status of what the linker
produced is unknown.
Comments anyone ?
Chris.\
\enddata{text,19723316}