Marc Singer <[EMAIL PROTECTED]> writes:

> On Mon, Feb 21, 2005 at 08:04:00PM -0800, Ben Pfaff wrote:
>> Marc Singer <[EMAIL PROTECTED]> writes:
>> 
>> > In cross compiling the AC_MALLOC_FUNC function will *always* indicate
>> > that malloc should be replaced with rpl_malloc.  
>> 
>> Yes, that's fine.  The replacement malloc() will not do any harm
>> if the target's malloc() is compatible.
>
> Except that there is no replacement malloc.  Unless I'm missing
> something.  Perhaps I am seeing a different problem.  My understanding
> of this macro was that the user application was being asked to provide
> rpl_malloc.  The only reason I know that this is a problem is that no
> rpl_malloc is being provided by glibc.

The documentation for AC_MALLOC_FUNC in the autoconf manual shows
you what replacement you should provide:

     #if HAVE_CONFIG_H
     # include <config.h>
     #endif
     #undef malloc
     
     #include <sys/types.h>
     
     void *malloc ();
     
     /* Allocate an N-byte block of memory from the heap.
        If N is zero, allocate a 1-byte block.  */
     
     void *
     rpl_malloc (size_t n)
     {
       if (n == 0)
         n = 1;
       return malloc (n);
     }

>> The target compiler has nothing to do with malloc()'s
>> implementation.  The test's answer only be known with assurance
>> if we can look at the target's C library, that is, by running a
>> program on the target.  Autoconf assumes there's no easy way to
>> do that, so it uses the conservative answer that malloc(0)
>> doesn't return the expected result.
>
> Understood.  I have no problem with it being conservative.  The thing
> is that I know it is wrong and there is no way for me to tell it so.
> I am using glibc.
>
> Thus, does is autoconf expecting that glibc (in my case) should be
> providing this rpl_malloc function?

No.  It expects that you will provide rpl_malloc(), and the
manual specifies an implementation for rpl_malloc().
-- 
"Debian for hackers, Red Hat for suits, Slackware for loons."
--CmdrTaco <URL:http://slashdot.org/articles/99/03/22/0928207.shtml>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to