Project

General

Profile

Actions

Bug #2653

closed

llc detection failure in configure.ac

Added by Gatewatcher Dev Team about 6 years ago. Updated almost 6 years ago.

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

Description

Hi,

We believe we discovered a bug in configure.ac, relative to the
detection of the LLC compiler, by the m4 macro AC_PROG_PATH.

In configure.ac, we can read:

AC_PROG_PATH(HAVE_LLC, llc, "yes", "no")

The prototype of AC_PROG_PATH is:

AC_PATH_PROG (variable, prog-to-check-for, [value-if-not-found], [path = ‘$PATH’])

This means that llc is sought in the path no, which is obviously
incorrect.

Thus, the following test should be a "not equal no" instead of a "equal yes"
if test "$HAVE_LLC" = "yes"; then

To reproduce the issue, one need to have CC equal to exactly clang and have
llc not found in path. This would trigger an error during compilation,
because llc would be used while not being findable.

We would also like to emphasize that the LLC detection instruction
sequence is making the assumption that if CC is clang, then LLC could
be llc or llc-<version> but if CC is clang-<version> then LLC
should also be named llc-<version> and not llc. We believe this assumption
to be excessive; for one, in our linux distro, this was not the case;
clang was named clang-version but LLC was named llc. While this is
probably not a desirable behavior of the LLVM package, we would advise
having a more resilient configure.ac script for Suricata.

Cheers,
ArmatureTech Dev Team

Actions

Also available in: Atom PDF