Why pass debugging, warning and optimization flags to downstream consumers?

[Branko Čibej <br...@apache.org>]

Looking at this, from a trunk build:

$ tail -1 apr.pc
Cflags: -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -g -O2 -I${includedir}
$ ./apr-2-config --cflags
  -g -O2


or from APR installed by Homebrew on macOS:

$ /opt/homebrew/opt/apr/bin/apr-1-config --cflags
  -g -O2 -Wall
$ tail -1 /opt/homebrew/opt/apr/lib/pkgconfig/apr-1.pc
Cflags: -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -g -O2 -Wall -I${includedir}


(note that MacPorts evidently takes the trouble to remove those flags 
from the results.)

Why? Why are we telling our library consumers about debugging, 
optimisation and warning flags? This makes no sense to me and is 
actively detrimental. In Serf, for example, we go through extra hoops to 
remove this crud from the APR flags; and I believe Subversion does 
something similar. APR should not dictate how its consumers are 
compiled. The --cppflags, sure, those are necessary on some platforms in 
order to make the resulting linked code work; but --cflags?

The culprit seems to be our construction of CFLAGS, then copying them 
wholesale to EXTRA_CFLAGS, which then get interpolated into the 
pkg-config file and the apr-X-config scripts. What, exactly, is the 
point of that interpolation? If it's to pass flags that were set 
explicitly at configure or build time, then that clearly is not how its 
implemented, because setting CFLAGS for configure removes them from 
apr-X-config and the pkg-config file.

My knee-jerk reaction was to just stop interpolating EXTRA_CFLAGS, but 
then, I've no clue what that would break. Someone with a deeper 
understanding of the autotools build, please speak up. I'm happy to dig 
into the build code to get this fixed, but I would appreciate a place to 
start; not just on trunk but the 1.7 and 1.8 branches, too.

-- Brane

Re: Why pass debugging, warning and optimization flags to downstream consumers?

[Joe Orton <jo...@redhat.com>]

On Mon, Aug 11, 2025 at 02:06:13PM +0200, Branko Čibej wrote:
> Well, this is a good start. It's tricky that we don't seem to have a
> mechanism for the user to set ABI-related flags in such a way that we end up
> exporting them from the config, but that's a whole other issue. I suppose
> we'll have to split the EXTRA_CFLAGS in two -- one for internal consumption
> and one for exported configuration. This will be tricky with, as you note,
> all the copious documentation. :)

Yeah :( We could probably safely remove half of apr_hints.m4 and nobody 
would ever notice, that was inherited from the httpd 1.3 build system 
and a bunch of it has likely never been executed from an APR release.

The other thing is that pkg-config does not expose the same set of data 
as apr-N-config (e.g. $CC, no $CFLAGS/$CPPFLAGS distinction), so there 
is more complexity in considering build system interactions which rely 
exclusively on one not the other.

(If we are proposing radical changes for v2, maybe getting rid of 
$bindir/apr-N-config entirely might be on the list?)

Regards, Joe

Re: Why pass debugging, warning and optimization flags to downstream consumers?

[Branko Čibej <br...@apache.org>]

On 11. 8. 25 11:53, Joe Orton wrote:
> On Thu, Aug 07, 2025 at 04:54:09PM +0200, Branko Čibej wrote:
>> Why? Why are we telling our library consumers about debugging, optimisation
>> and warning flags? This makes no sense to me and is actively detrimental. In
>> Serf, for example, we go through extra hoops to remove this crud from the
>> APR flags; and I believe Subversion does something similar. APR should not
>> dictate how its consumers are compiled. The --cppflags, sure, those are
>> necessary on some platforms in order to make the resulting linked code work;
>> but --cflags?
> Not sure I can answer all of this and don't want to defend the current
> design particularly, but:
>
> In general, how do you distinguish "debugging, optimisation and warning"
> flags from compiler flags which might impact ABI choices at cc or libc
> level?  e.g. -DNDEBUG is a "debugging flag." but -D_FILE_OFFSET_BITS=64
> is a libc ABI choice. -O2 is a optimisation flag, for *bsdi* in the
> hints, -m486 is... possibly an ABI choice?


In this particular case, it shouldn't be that hard: configure adds -g, 
-O2, and possibly -Wall itself, so all we need to do is make sure those 
flags are used for building but not for configuring consumers. Things 
like -D_FILE_OFFSET_BITS=64 or -DREENTRANT or -D_GNU_SOURCE are added to 
--cppflags, etc. User-supplied flags are _not_ exported, so getting some 
kind of cross-compilation to work with a whole stack of packages is, I 
guess, a bit more involved?

> Historically part of the problem APR solved was "pick a set of compiler
> flags for weird Unix platforms which give me a compiler which DTRT, and
> apply them everywhere". So, CFLAGS was part of that. There was/is a
> blurred line between "picking good defaults" and allowing users to
> pick/override those, and this stuff was not really designed/documented
> in sufficient detail.

Yes, I gathered as much from reading the code...

> (Building on 32-bit Linux with -D_FILE_OFFSET_BITS=64 and on 64-bit
> platforms with gcc -m32 were always two good tests of ABI consistency
> via inherited $CC or $CFLAGS/$CPPFLAGS)

Well, this is a good start. It's tricky that we don't seem to have a 
mechanism for the user to set ABI-related flags in such a way that we 
end up exporting them from the config, but that's a whole other issue. I 
suppose we'll have to split the EXTRA_CFLAGS in two -- one for internal 
consumption and one for exported configuration. This will be tricky 
with, as you note, all the copious documentation. :)

-- Brane

Re: Why pass debugging, warning and optimization flags to downstream consumers?

[Joe Orton <jo...@redhat.com>]

On Thu, Aug 07, 2025 at 04:54:09PM +0200, Branko Čibej wrote:
> Why? Why are we telling our library consumers about debugging, optimisation
> and warning flags? This makes no sense to me and is actively detrimental. In
> Serf, for example, we go through extra hoops to remove this crud from the
> APR flags; and I believe Subversion does something similar. APR should not
> dictate how its consumers are compiled. The --cppflags, sure, those are
> necessary on some platforms in order to make the resulting linked code work;
> but --cflags?

Not sure I can answer all of this and don't want to defend the current 
design particularly, but:

In general, how do you distinguish "debugging, optimisation and warning" 
flags from compiler flags which might impact ABI choices at cc or libc 
level?  e.g. -DNDEBUG is a "debugging flag." but -D_FILE_OFFSET_BITS=64 
is a libc ABI choice. -O2 is a optimisation flag, for *bsdi* in the 
hints, -m486 is... possibly an ABI choice?

Historically part of the problem APR solved was "pick a set of compiler 
flags for weird Unix platforms which give me a compiler which DTRT, and 
apply them everywhere". So, CFLAGS was part of that. There was/is a 
blurred line between "picking good defaults" and allowing users to 
pick/override those, and this stuff was not really designed/documented 
in sufficient detail.

(Building on 32-bit Linux with -D_FILE_OFFSET_BITS=64 and on 64-bit 
platforms with gcc -m32 were always two good tests of ABI consistency 
via inherited $CC or $CFLAGS/$CPPFLAGS)

Regards, Joe

Re: Why pass debugging, warning and optimization flags to downstream consumers?

[Graham Leggett via dev <de...@apr.apache.org>]

On 07 Aug 2025, at 15:54, Branko Čibej <br...@apache.org> wrote:

> Why? Why are we telling our library consumers about debugging, optimisation and warning flags? This makes no sense to me and is actively detrimental. In Serf, for example, we go through extra hoops to remove this crud from the APR flags; and I believe Subversion does something similar. APR should not dictate how its consumers are compiled. The --cppflags, sure, those are necessary on some platforms in order to make the resulting linked code work; but --cflags?
> 
> The culprit seems to be our construction of CFLAGS, then copying them wholesale to EXTRA_CFLAGS, which then get interpolated into the pkg-config file and the apr-X-config scripts. What, exactly, is the point of that interpolation? If it's to pass flags that were set explicitly at configure or build time, then that clearly is not how its implemented, because setting CFLAGS for configure removes them from apr-X-config and the pkg-config file.
> 
> My knee-jerk reaction was to just stop interpolating EXTRA_CFLAGS, but then, I've no clue what that would break. Someone with a deeper understanding of the autotools build, please speak up. I'm happy to dig into the build code to get this fixed, but I would appreciate a place to start; not just on trunk but the 1.7 and 1.8 branches, too.

Agree this is wrong, I've had pain in the past having to recompile half the stack just to make the debugger work.

This definitely needs to be aligned with everything else.

Regards,
Graham
--