Too many flags in opensaml pkgconfig
rra at debian.org
Tue Feb 14 21:43:28 UTC 2012
"Cantor, Scott" <cantor.2 at osu.edu> writes:
> If you split LDFLAGS and LIBS, then how do you get any other relevant
> LDFLAGS into the build when the only option pkg-config has is --libs?
> The more important point though is the CFLAGS one. On some platforms,
> you need the right options to be in place consistently across the build
> to ensure thread safety. Just defining the right include path won't
> ensure a safe result. Solaris in particular.
> Admittedly there are other things in CFLAGS, but the macro didn't really
> give me a lot of control. I don't use the pkg-config tool so it's
> possible I erred by bothering to include it as a toss-in.
I thought more about this, particularly given some of the other issues
that we ran into with -pthread, and I think I was too aggressive in
wanting to drop @LDFLAGS@ and @CFLAGS@ in general. At the least, I'm not
sure what to do about the various threading cases.
What originally sparked the observation is that it does seem wrong for
linking with opensaml2 to automatically enable -O2 -g -DNDEBUG. Those
sort of flags seem a bit intrusive for downstream. But given the
structure of the current pkgconfig macro and the way configure is laid
out, I don't see a great way of preventing inclusion of those flags while
still getting the threading flags and other possible necessary flags.
This is probably really a bug report against the Autoconf archive macro
that you're using. I don't think it provides the right interfaces to use
What I'm doing for right now is just filtering out the Debian build flags
from the generated pkgconfig file, which at least removes the hardening
flags but which leaves "-g -Wall -O2 -O2 -DNDEBUG" behind. I guess the
only option I can think of would be to rearchitect how compiler flags are
handled in configure.ac so that the threading flags and flags derived from
pkgconfig are separated from the CFLAGS that you get by default or because
optimization or debugging is enabled, and only use the former to generate
pkgconfig rather than all of them. That seems like a chunk of Autoconf
work; I'm not sure if the benefit is compelling enough that it's worth
tracking as a low-priority bug in JIRA.
Russ Allbery (rra at debian.org) <http://www.eyrie.org/~eagle/>
More information about the Pkg-shibboleth-devel