Bug #175
closed
Passing --disable-prelude to configure seems to instead enable prelude
Added by Robert Kerr almost 14 years ago.
Updated almost 14 years ago.
Description
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?
Files
- 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
This seems to fix the problem:
diff --git a/configure.in b/configure.in
index 849545d..af68365 100644
--- a/configure.in
+++ b/configure.in
@@ -430,10 +430,8 @@ esac
#prelude
AC_ARG_ENABLE(prelude,
- [ --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
CFLAGS="$CFLAGS -DPRELUDE"
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.
Hi,
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
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...
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.
- 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