Skip to content

qrintf issues with autotools #11

@dhobsd

Description

@dhobsd

I'm not a fan of autotools, but can't work around using it in this case. I encountered several issues when integrating qrintf into our Varnish build:

Because qrintf.h is included very early in the compile process, a number of header files are pulled in before any chance of including config.h is allowed. This breaks packages that self-define C environment options like _GNU_SOURCE or _XOPEN_SOURCE or the like.

In my specific case, this was solved by hacking qrintf.h to include:

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

fixes the issue. I would submit a PR, but I'm sure that someone has an autotools build where the relevant guard is _HAVE_CONFIG_H and the file is also named differently.

I ran into a couple of other problems related to autohell:

  1. When qrintf-gcc is specified as the CC to use for configure, a number of header feature tests break. (A ffsl(3) test failed in jemalloc, for a specific case.) I worked around this by specifying CC as an argument to make.
  2. CFLAGS are not passed to qrintf-gcc. This requires one to set relevant build options a la CC="qrintf-gcc -std=gnu99 -Werror -Wall" make.

All of these things would be more easily resolved if it was easier / safer to include qrintf in projects built using these "tools". (In the meantime, I've worked around these issues, so this is not a high priority issue or anything. I'd be happy to submit patches if you have better ideas than the hacky ones I made.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions