Date: Mon, 17 Apr 2000 13:28:28 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Waldemar Schultz cc: djgpp AT delorie DOT com Subject: Re: alternative malloc In-Reply-To: <38FACD9A.7C2328B7@ma.tum.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 17 Apr 2000, Waldemar Schultz wrote: > > If your program has replacements for malloc, free, and realloc, then > > the linker will use them instead of the versions in the library. > > > > But you *must* implement all the 3 functions, since the library > > version has them all on a single module. > > and what about 'strdup' (? etc.) There should be no problem with `strdup', or any other function that is defined on a seperate source file. Calling `malloc' is not the problem: these calls will simply be passed to the replacement `malloc'. The problem I was referring to is that the GNU linker cannot link parts of object files, it can only link each object file in its entirety. Since malloc.c in the library defines `malloc', `free', and `realloc' functions, they all need to be replaced at once. Otherwise, if the program calls `realloc', the linker will link malloc.c from the library, and will then complain about multiple definitions of `malloc'. Of course, I assume that the replacement `malloc' is functionally equivalent to the library version, albeit with different internal implementation. If the replacement is not an equivalent, then the program will most likely crash right on startup (because the startup code calls `malloc'). As an example, Emacs defines its own replacements for these functions, but leaves the rest of the library, including strdup, alone. And it works.