Re: Adding malloc configure test?

[Eric Blake]

On 04/06/2011 04:21 PM, Gilles Ganault wrote:
> Hello
> 
> I'm no configure/make expert, and need to cross-compile SSHGuard to run
> on a uClinux-based appliance.
> 
> After successfully (?) running "configure", make stops after a few seconds:
> ==========
> ...
> /usr/src/baps/opt/uClinux/bfin-linux-uclibc/bin/bfin-linux-uclibc-gcc
> -I. -O2 -Wall -std=c99  -D_XOPEN_SOURCE  -O2 -Wall -pedantic
> -I/usr/src/baps/uClinux-dist/linux-2.6.x/include
> -I/usr/src/baps/uClinux-dist/staging/usr/include   -o sshguard
> sshguard.o seekers.o sshguard_whitelist.o sshguard_log.o
> sshguard_procauth.o sshguard_blacklist.o sshguard_options.o
> sshguard_logsuck.o simclist.o hash_32a.o parser/libparser.a
> fwalls/libfwall.a -lpthread
> 
> sshguard_options.o: In function `.L17':
> sshguard_options.c:(.text+0x1d0): undefined reference to `_rpl_malloc'

This is a bug in the sshguard project, and you should report it to them.
 They are disregarding the configure test results, and failing to
provide a replacement malloc.c that provides rpl_malloc as required by
the documentation for AC_FUNC_MALLOC.

However, it could be argued that this is also a bug in the configure
test for AC_FUNC_MALLOC in autoconf itself - it currently guesses
pessimistically while cross-compiling, and could in fact be taught to
probe various known systems where malloc(0) allocates rather than its
current behavior of always guessing no.  However, since there are still
systems where the pessimistic guess is still correct (such as AIX),
fixing the autoconf test to be less pessimistic will only mask the
sshguard bug, not eliminate it.  Having wider exposure for the fallback
code is in one regards a feature rather than a bug.  So I'm not sure
whether it is worth the efforts to try and patch AC_FUNC_MALLOC to be
less pessimistic when cross-compiling.

> The problem is solved by exporting this variable before running
> "configure":
> ==========
> export ac_cv_func_malloc_0_nonnull=yes

Rather than exporting the variable, the preferred syntax is:

./configure ac_cv_func_malloc_0_nonnull=yes

(that is, make it an explicit argument to configure, so that it will be
properly remembered for future runs, even if you change your environment
variables later).

> ==========
> 
> But I'd like to know how to solve this problem more elegantly: Where
> should I put this type of settings?

If you find yourself always having to correct pessimistic guesses when
cross-compiling, then it is worth adding a config.site file that will
properly prime the cache for what you know are the right answers for
your system.  But without a config.site file, your approach of
overriding the cache variable is indeed the documented way to fix the
pessimistic guess.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature