This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS.
Type: behavior Stage: resolved
Components: Versions: Python 3.2, Python 3.3
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: trent Nosy List: koobs, trent
Priority: normal Keywords:

Created on 2012-08-21 21:29 by trent, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (5)
msg168805 - (view) Author: Trent Nelson (trent) * (Python committer) Date: 2012-08-21 21:29
All the FreeBSD build slaves seem to be experiencing the same symptom: ./configure --with-pydebug eventually results in this:

    gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes  -O2 -pipe -fno-strict-aliasing -Wall -march=native   -I. -I./Include    -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c

What I find odd:

  % grep -e '-O2' Makefile | wc -l
         0

There are references to -O2 elsewhere, like in configure.ac|configure, but, the Makefile doesn't source any of those.  (Right?)

This is occurring on all of my slaves as well as others, so I'm pretty sure it's not just specific to my environment.
msg168807 - (view) Author: Trent Nelson (trent) * (Python committer) Date: 2012-08-21 21:34
Ah!


% gmake
gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c
^C

% make

% make
gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes  -O2 -pipe   -I. -I./Include    -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes  -O2 -pipe   -I. -I./Include    -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c
gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes  -O2 -pipe   -I. -I./Include    -DPy_BUILD_CORE -o Parser/grammar1.o Parser/grammar1.c
^C

So, the default BSD make likes to add in -O2 -pipe.  I'll do a bit more digging.
msg168810 - (view) Author: Trent Nelson (trent) * (Python committer) Date: 2012-08-21 21:58
So, looks like FreeBSD's /usr/share/mk/sys.mk is to blame here.  It unconditionally sets CFLAGS to `-O2 -pipe`.


[trent@hydrogen/ttypts/1(~s/cpython)%] uname -a
FreeBSD hydrogen.snakebite.net 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r0: Mon Jul 16 06:28:19 UTC 2012     root@hydrogen.snakebite.net:/usr/obj/src/freebsd/9/r238513m/sys/AMD64  amd64

[trent@hydrogen/ttypts/1(~s/cpython)%] grep -A3 'bsd_make_test' Makefile
bsd_make_test:
	@echo "CFLAGS: $(CFLAGS)"
	@echo "EXTRA_CFLAGS: $(EXTRA_CFLAGS)"

[trent@hydrogen/ttypts/1(~s/cpython)%] make bsd_make_test        
CFLAGS: -O2 -pipe 
EXTRA_CFLAGS: 

[trent@hydrogen/ttypts/1(~s/cpython)%] make CFLAGS= bsd_make_test
CFLAGS: 
EXTRA_CFLAGS: 

I can think of a few ways to work around this... some better than others.

1. Change the FreeBSD buildbots to always invoke make via `make CFLAGS=`.

2. Hack configure.* to automatically invoke make via `make CFLAGS=` when `-O2 -pipe` crops up in a `--with-pydebug` build.

Some of the less desirable ones:

3. Switch FreeBSD to gmake.

4. Patch FreeBSD make so that it is 'debug aware' and stops appending `-O2` everywhere.
msg168849 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2012-08-22 07:47
> So, looks like FreeBSD's /usr/share/mk/sys.mk is to blame here.
> It unconditionally sets CFLAGS to `-O2 -pipe`.

I've been debugging this once, too. My conclusion was that if the OS is set up
that way, we shouldn't do anything about it in the Python source tree.

All important features of --with-pydebug should also work if -O0 is overridden
by -O2.

So I think that FreeBSD users who really want -O0 should change sys.mk
or set CFLAGS manually. For the buildbots it should not matter, except
that compile times are slower.
msg180130 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2013-01-17 13:23
Trent, do you want to keep this open? I think sys.mk is behaving exactly
as intended.
History
Date User Action Args
2022-04-11 14:57:35adminsetgithub: 59961
2021-12-10 09:42:24iritkatrielsetstatus: pending -> closed
stage: resolved
2019-02-16 23:27:54cheryl.sabellasetstatus: open -> pending
2014-05-13 21:58:01skrahsetnosy: - skrah
2013-01-17 13:23:46skrahsetmessages: + msg180130
2012-08-22 07:47:23skrahsetmessages: + msg168849
2012-08-21 21:58:20trentsetmessages: + msg168810
2012-08-21 21:34:41trentsetmessages: + msg168807
2012-08-21 21:29:40trentcreate