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 eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
