backtrace() on openbsd?

[job]

Tried to compile this on openbsd -current

job@vurt FORT-validator$ AUTOMAKE_VERSION=1.16 AUTOCONF_VERSION=2.69 autoreconf --install --force
configure.ac:12: installing './compile'
configure.ac:8: installing './install-sh'
configure.ac:8: installing './missing'
src/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
job@vurt FORT-validator$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking for size_t... yes
checking for ssize_t... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for memset... yes
checking for socket... yes
checking for library containing pthread_create... -lpthread
checking for library containing X509_get_version... -lcrypto
checking for library containing backtrace... no
configure: error: unable to find backtrace() function

[ydahhrk]

Did you install libexecinfo?

pkg_add libexecinfo

[job]

yes, it is installed

On Tue, Sep 03, 2019 at 09:42:06AM -0700, Alberto Leiva Popper wrote:

Did you install libexecinfo?

pkg_add libexecinfo

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/NICMx/FORT-validator/issues/15#issuecomment-527540564

[ydahhrk]

Ok, replicated. The problem appears to be gcc.

OpenBSD's gcc is too old for Fort. Even if it doesn't blow up during the backtrace check, it's bound to do so later.

Try

env CC=clang CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure

[job]

openbsd is switching to LLVM, keep that in mind

On Tue, Sep 3, 2019 at 6:59 PM Alberto Leiva Popper < notifications@github.com> wrote:

Ok, replicated. The problem appears to be gcc.

OpenBSD's gcc is too old for Fort. Even if it doesn't blow op during the backtrace check, it's bound to do so later.

Try

env CC=clang CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/NICMx/FORT-validator/issues/15?email_source=notifications&email_token=AABFRWF2KSLI7Y7JXYUF4ZDQH2JVTA5CNFSM4ITIPSW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5Y3VKQ#issuecomment-527547050, or mute the thread https://github.com/notifications/unsubscribe-auth/AABFRWFYYDP4P4UGF3C2N6DQH2JVTANCNFSM4ITIPSWQ .

[ydahhrk]

Ok, noted. Is clang a sufficient workaround for now, though?

[job]

i think so? isnt clang == llvm?

On Tue, Sep 3, 2019 at 7:01 PM Alberto Leiva Popper notifications@github.com wrote:

Ok, noted. Is clang a sufficient workaround for now, though?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ydahhrk]

Oh yeah, my bad.