Project

General

Profile

Actions
Copy link

Bug #1835

closed

AC_ARG_ENABLE usage is incorrect

Added by Daniel Weeks over 8 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

Description

In several locations in configure.ac the AC_ARG_ENABLE usage is incorrect or at least non-standard. Whether --enable-<feature> or --disable-<feature> flag is passed to configure it is treated as if the feature is enabled. The only way to disable a feature is to not pass either option to configure. A user that explicitly disables a feature because a dependency is not available will be met with a unexpected error.

Related issues 3 (0 open — 3 closed)

Related to Suricata - Bug #2468: The autoconf process fails when some options are disabledClosedActions
Related to Suricata - Bug #2473: Please allow disabling every option (add --without-{option})ClosedActions
Is duplicate of Suricata - Bug #2797: configure.ac: broken --{enable,disable}-xxx optionsClosedFabrice FontaineActions
Actions
Copy link
 #1

Updated by Victor Julien over 8 years ago

Can you be more specific about which ones are incorrect?

Actions
Copy link
 #2

Updated by Andreas Herz over 8 years ago

  • Tracker changed from Bug to Optimization
  • Assignee set to Andreas Herz
  • Target version set to TBD

We will try to improve the whole configure.ac file to be more consistent so we can address that within the general rework. But yes, please provide more details so we can take that into account :)

Actions
Copy link
 #3

Updated by Daniel Weeks over 8 years ago

I originally discovered it in the hiredis option but I can see at a glance the same structure exists with the nflog, nfqueue, dag, napatech, and lua options. It appears the form assumed in configure.ac is AC_ARG_ENABLE(..., [action-if-disabled], [action-if-enabled]) when in fact it is AC_ARG_ENABLE(..., [action-if-given], [action-if-not-given]). This leads to configure checking for libraries after the feature has been disabled because /some/ option has been supplied.

Also, in my opinion, this is a clear bug, not an optimization. When a user explicitly sets a feature to be disabled, they expect that to be honored. It is not in these cases.

Actions
Copy link
 #4

Updated by Victor Julien almost 8 years ago

  • Tracker changed from Optimization to Bug
  • Status changed from New to Assigned
  • Priority changed from Normal to High
  • Target version changed from TBD to 70
Actions
Copy link
 #5

Updated by Victor Julien almost 7 years ago

  • Related to Bug #2468: The autoconf process fails when some options are disabled added
Actions
Copy link
 #6

Updated by Victor Julien over 6 years ago

  • Related to Bug #2473: Please allow disabling every option (add --without-{option}) added
Actions
Copy link
 #7

Updated by Victor Julien almost 6 years ago

  • Is duplicate of Bug #2797: configure.ac: broken --{enable,disable}-xxx options added
Actions
Copy link
 #8

Updated by Victor Julien almost 6 years ago

  • Status changed from Assigned to Closed
  • Assignee deleted (Andreas Herz)
  • Priority changed from High to Normal
  • Target version deleted (70)

Fixed in #2797

Actions
Copy link

Also available in: Atom PDF