Stefan Krah <stefan-use...@bytereef.org> added the comment: Chris Lambacher <rep...@bugs.python.org> wrote: > I was cross-compiling to a target architecture that does not support > the -march option so I would not be able to provide a different one > as override.
Just out of curiosity: You are cross-compiling a C-extension? How can you be sure that all values in pyconfig.h are correct? > The debian-sysconfig-flags looks the most correct because it allows > override at any point by emulating the CFLAGS = $(BASECFLAGS) $(OPT) > $(EXTRA_CFLAGS) logic. > > It still looks like it needs an override for EXTRA_CFLAGS and the > logic for LD_SHARED looks wrong. In the Makefile LDSHARED is just: > LDSHARED= $(CC) -shared -Wl,-O1 -Wl,-Bsymbolic-functions I think Antoine is correct: EXTRA_CFLAGS show up as an empty string in sysconfig (even if passed to configure and make), so there is no need to override them. As an aside, why do EXTRA_CFLAGS still exist in py3k when CFLAGS can already be passed to configure and make? I agree that the ldshared logic looks wrong. It is possible to specify LDFLAGS via the environment, so why append CFLAGS. Changing this could break existing build scripts though. However, I don't see how the Debian patch could break anything, unless someone relies on the fact that BASECFLAGS are suppressed in case CFLAGS are given. I think the odds of this are virtually zero. Any interest in a cleaned up version of the Debian patch (remove double opt, line length, add documentation for overriding BASECFLAGS and OPT)? I'm asking, since I'm unsure about the degree of frozenness of distutils. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue969718> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
