Easy! The AC_FUNC_MALLOC and AC_FUNC_REALLOC try to execute a program to see whether malloc(0) will return a NULL pointer. If that is not the case, it will use the rpl_malloc. Since cross-compiling, binaries cannot be executed and the test fails even though the malloc and realloc are in MS C runtime. Those malloc and realloc functions are compliant in the sense of AC_FUNC_MALLOC and AC_FUNC_REALLOC test, so patching them out is safe when cross-compiling for win32.
Cheers Fridrich On Tue, 2009-05-26 at 06:56 -0400, bugzilla-H+wXaHxf7aLQT0dZR--- Comment #3 from Thomas Sailer <[email protected]> 2009-05-26 06:56:13 EDT --- > (In reply to comment #2) > > > The AC_FUNC_MALLOC is some kind of fallback for environments which don't > > have a > > malloc() function in their libc. If this is the case (apparently it is for > > MinGW), then a '#define malloc rpl_malloc' is added to config.h. > > I agree we don't want rpl_malloc. > > The question is why does it fail to find the malloc in libmsvcrt.a (or newer > friends). libmsvcrt.a provides _malloc: > > i686-pc-mingw32-nm /usr/i686-pc-mingw32/sys-root/mingw/lib/libmsvcrt.a > dxnmbs00676.o: > 00000000 b .bss > 00000000 d .data > 00000000 i .idata$4 > 00000000 i .idata$5 > 00000000 i .idata$6 > 00000000 i .idata$7 > 00000000 t .text > U __head_libmsvcrt_a > 00000000 I __imp__malloc > 00000000 T _malloc > > But that shouldn't hold up packaging. > > APPROVED by sailer. > _______________________________________________ fedora-mingw mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
