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]