Bug #175


Passing --disable-prelude to configure seems to instead enable prelude

Added by Robert Kerr almost 14 years ago. Updated almost 14 years ago.

Target version:
Affected Versions:


Tested on 0.9.1 and latest git (3005297af2e1b4a8355e3f27e43541f6a70aa314)
The configure script seems to check for prelude if you pass --disable-prelude:

$ ./configure --disable-prelude
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for pthread_create in -lpthread... yes
checking for libprelude-config... no
checking for libprelude - version >= 0.9.9... no
*** The libprelude-config script installed by LIBPRELUDE could not be found
*** If LIBPRELUDE was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the LIBPRELUDE_CONFIG environment variable to the
*** full path to libprelude-config.
configure: error: Cannot find libprelude: Is libprelude-config in the path?


Actions #1

Updated by Victor Julien almost 14 years ago

  • Due date set to 06/11/2010
  • Assignee set to Pierre Chifflier
  • Target version set to 0.9.2
  • Estimated time set to 0.00 h
Actions #2

Updated by Robert Kerr almost 14 years ago

This seems to fix the problem:

diff --git a/ b/
index 849545d..af68365 100644
--- a/
+++ b/
@@ -430,10 +430,8 @@ esac

-            [  --enable-prelude  Enable Prelude support for alerts],
-            [ enable_prelude=yes ],
-            [ enable_prelude=no ])
-    if test "$enable_prelude" = "yes"; then
+            [  --enable-prelude  Enable Prelude support for alerts])
+    if test "x$enable_prelude" != "xno"; then
         AM_PATH_LIBPRELUDE(0.9.9, , AC_MSG_ERROR(Cannot find libprelude: Is libprelude-config in the path?), no)
         if test "x${LIBPRELUDE_CFLAGS}" != "x"; then

Don't know it's necessarily the 'right' way to fix it though. Also - the various other --enable/--disable options probably need checking, at least --disable-nfqueue seems to exhibit the same problem.

Actions #3

Updated by Pierre Chifflier almost 14 years ago


Here is a fix for this specific problem.

Indeed, the problem is present for other options as well, and is caused by a wrong use of AC_ARG_ENABLE: the third and forth arg are used if option is specified (resp. no specified), not if enabled or not. This means --disable-option will can the third argument (specified) ...

The real fix is not to use these args, and use some logic to get the option value.

Note that, if you don't want support for Prelude, you should just not provide the option and it wouldn't be searched

Actions #4

Updated by Robert Kerr almost 14 years ago

Thanks Pierre - I am aware that one workaround is not passing --disable-prelude.

The basic issue I had was that I was writing a gentoo ebuild for suricata, and as part of that you give it a list of acceptable configure options and it automatically handles setting them to enable/disable based on the 'use flags' configured for the underlying OS build. In that case if you tell the ebuild a flag exists it must have a value one way or another.

More generally - I think it is useful to have these args and not some automated logic. There are cases where you may not want to build in a feature even if the build OS supports it, perhaps you are planning on using the binary on many other systems, etc...

Actions #5

Updated by Will Metcalf almost 14 years ago

Attached is a patch to Pierre's patch that impliments the change for all AC_ARG_ENABLE() options. The only modification that I made was defaulting the action-if-not-given to setting the enable_var to "no" so that we can test the value as yes/no elsewhere in the configure script for example the summary of enabled options at the end of the configure script.

Actions #6

Updated by Victor Julien almost 14 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

Both applied to my local tree, thanks guys. Will push it out soon.


Also available in: Atom PDF