Bug #1192: Suricata does not compile on OS X/Clang due to redefinition of string functions - Suricata - Open Information Security Foundation

Actions

Copy link

Bug #1192

closed

Suricata does not compile on OS X/Clang due to redefinition of string functions

Added by Adam Vandenberg over 10 years ago. Updated almost 10 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Victor Julien

Target version:

2.0.6

Affected Versions:

Effort:

Difficulty:

Label:

Description

Using this system configuration:
$ brew --config
HOMEBREW_VERSION: 0.9.5
ORIGIN: git@github.com:adamv/homebrew.git
HEAD: cb75d101c0b213b2ca6ae0e60b8df6494acf6125
HOMEBREW_PREFIX: /Users/adamv/.hb
HOMEBREW_CELLAR: /Users/adamv/homebrew/Cellar
CPU: 8-core 64-bit haswell
OS X: 10.9.2-x86_64
Xcode: 5.1.1
CLT: 5.1.0.0.1.1396320587
Clang: 5.1 build 503
X11: 2.7.5 => /opt/X11
System Ruby: 1.8.7-358
Perl: /usr/bin/perl
Python: /usr/bin/python
Ruby: /usr/bin/ruby

Suricata does not compile with clang as clang provides definitions for strlcat and strlcpy.

To enable compilation with clang, see attached patch.
(Of course, the correct fix would be to detect these two string functions and not provide definitions if they are already present.)

Files

no-strings.diff (1.95 KB) no-strings.diff

Adam Vandenberg, 05/15/2014 10:11 PM

Actions

Copy link

Updated by Victor Julien over 10 years ago

The patch doesn't really make sense to me for 2 reasons:
1. Makefile.in is auto generated by the build system
2. by removing the strlcat and strlcpy definitions from suricata-common.h the code using those functions won't know their types

The proper fix for this issue would be to detect in configure (configure.ac) if the system/compiler/libc already provides strlcpy and strlcat and make compilation of the implementation we provide conditional.

Actions

Copy link

Updated by Victor Julien over 10 years ago

Assignee set to Jason Ish
Target version set to 2.0.2

Actions

Copy link

Updated by Jason Ish over 10 years ago

Sorry guys, I'm not sure how useful I'm going to be here. After moving MacPorts out of the way and installing Brew, things fail for me way before any .c file even gets to compile.

Personally I use MacPorts for building Suricata, using gcc from MacPorts. This is fine for me as I don't use the Mac for production purposes, and well, its mostly just worked.

Actions

Copy link

Updated by Victor Julien over 10 years ago

Thanks Jason.

I may just rename our strlcpy and strlcat and prefix it with SC_ or something, that should resolve this naming clash. Doesn't feel right, but I have no way of debugging this.

Actions

Copy link