[comp.sys.next] Overloading functions

dmr@csli.Stanford.EDU (Daniel M. Rosenberg) (06/11/89)

Recently, when trying to compile bash (a shell from the Free Software
folks) on my Cube, I ran into a problem I have run into before.

Bash makes its own versions of malloc(), free(), and realloc(). Ld
does not appreciate them competing with the ones in libc. Is there
any simple way to tell the compiler or loader to just overload
redefined functions?

Thanks for any hints.

-- 
# Daniel M. Rosenberg     //  Stanford CSLI  // Opinions are my own only.
# dmr@csli.stanford.edu  // decwrl!csli!dmr // dmr%csli@stanford.bitnet

ali@polya.Stanford.EDU (Ali T. Ozer) (06/14/89)

In article <9368@csli.Stanford.EDU> Daniel M. Rosenberg writes:
>Bash makes its own versions of malloc(), free(), and realloc(). Ld
>does not appreciate them competing with the ones in libc. Is there
>any simple way to tell the compiler or loader to just overload
>redefined functions?

Using shared libraries, no, you have no way to overload functions.
You can, however, use the non-shared versions of the libraries ---
replace -lsys_s with -lc and any others you might need.

Please note that the memory allocation routines in the NeXT libraries are 
highly optimized and do a good job. Unless there's some other reason to 
override them, it might not be a bad idea to just use the NeXT versions.
(I'm not familiar with the bash code; it might turn out that the 
bash versions of malloc etc do other stuff...)

Ali Ozer, NeXT Developer Support
aozer@NeXT.com

carter@sloth.gatech.edu (Carter Bullard) (06/19/89)

In article <9996@polya.Stanford.EDU> aozer@NeXT.com (Ali Ozer) writes:
>In article <9368@csli.Stanford.EDU> Daniel M. Rosenberg writes:
>>Bash makes its own versions of malloc(), free(), and realloc(). Ld
>>does not appreciate them competing with the ones in libc. Is there
>>any simple way to tell the compiler or loader to just overload
>>redefined functions?
>

>Please note that the memory allocation routines in the NeXT libraries are 
>highly optimized and do a good job. Unless there's some other reason to 
>override them, it might not be a bad idea to just use the NeXT versions.
>(I'm not familiar with the bash code; it might turn out that the 
>bash versions of malloc etc do other stuff...)

Yes, there is, in many cases of porting code to the NeXT, a need to
overload these functions.  I have gotten in the habit of just renaming
the malloc redefinitions to something like Malloc. 

Carter Bullard
School of Information & Computer Science, Georgia Tech, Atlanta GA 30332
uucp:	...!{decvax,hplabs,ihnp4,linus,rutgers}!gatech!carter
Internet:	carter@gatech.edu