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]