Date: Fri, 21 Apr 95 08:51:50 EDT
From: den AT aisinc DOT com (Dave New)
To: bdavidson AT ra DOT isisnet DOT com
Subject: Re: Multiple references in a link step
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu, ckann AT seas DOT gwu DOT edu

Bill writes:
 
> On Thu, 20 Apr 1995, Dave New wrote:
> 
> >  
> > Usually what happens is that if you replace one function contained in standard
> > file with another function in a new file, you must replace all the functions in
> > the standard file, or else ensure that none of the other functions are ever 
> > referenced by anything else in that link.
> 
> This may be a little drastic, and I haven't tried it, but couldn't you do 
> this?
> 1) copy your libc.a file to a "safe" directory for later (when everything 
> falls apart :-). 
> 2) use ar to remove the offending function from libc.a.
> 3) compile and link with the "emasculated" libc.a.
> 
> This would have the added benefit that, if you replaced, say, malloc(), 
> all other library functions that use malloc() would also use your "new, 
> improved" malloc.
> Alternatively, you could copy libc.a to your working directory, remove 
> the offending functions, and modify the linker's search path putting your 
> working directory first.
> 
> Bill Davidson
> bdavidson AT ra DOT isisnet DOT com
> 

Unfortunately, the granularity of the object modules in the library are not
on a per *function* basis, but rather on an object *file* basis.  If the object
file that contained the malloc() function also contains other globally defined
functions or variables, then removing that object module from the library will
also eliminate the other functions/variables.  If the module is left in, then
referencing any of the functions/variables in that module will define *all*
the global functions/variables in that module, whether you wanted them or not.

BTW, the linker doesn't have (and the C language doesn't support) the concept of
"weak" externals, except that function declarations with "extern" on them don't
automatically suck in those functions (according to ANSI C, an implementation
dependancy -- using "extern" on function declarations is a "hint" to the 
linker), unless the program contains an actual reference to them.  Even "weak" 
externals don't really apply here; they are used generally in an environment 
that supports demand loading of modules based on actually calling a function 
someplace in the thread of execution.  If the calling code is never executed, 
the called function is never linked.  These days, shared libraries and DLL's 
have taken the place of such things.

Looking in the malloc.c source in the lib, I see that in addition to malloc(),
free(), realloc(), memalign(), valloc(), calloc(), cfree(), and malloc_stats()
are defined.  I may have missed something, but most of the other functions are
defined 'static' and are not globally visible.

So, *anything* in the C library or in your application that references any of 
the above functions (directly or indirectly -- consider that most C run-times 
have an atexit()-like mechanism for free()ing up memory allocated by the 
application that it didn't explicitly free before exiting) will suck in 
malloc.o from the library.

So, if you want to write a replacement for malloc(), you must also either copy 
all the other functions from the library malloc.c into your new source or else 
write suitable replacements for all of them.  Alternately, you could #ifdef 0 
the malloc() code in the library malloc.c, and then write your own malloc() in 
your own source.  Even if the library malloc.o gets pulled in, you won't get 
multiple definitions.

This is probably not what you want to do, though, since there are a lot of 
static structs and helpers that are shared by the memory allocation package, 
and splitting the module into separate sources like that doesn't look like a 
good way of dealing with this problem.

DaveN