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.

Author lemburg
Recipients bobatkins, jprante, lemburg, loewis, rpetrov, sergiodj, spacey
Date 2009-10-29.10:07:51
SpamBayes Score 3.5018044e-11
Marked as misclassified No
Message-id <1256810874.67.0.236188387569.issue1628484@psf.upfronthosting.co.za>
In-reply-to
Content
Perhaps we can get some movement regarding this problem again, as it
also applies to other platforms that require special gcc options for the
compiler and linker.

A common case where such settings were needed is Mac OS X - in the case
of building universal binaries. Since this was too tedious to get right,
Python 2.5 introduced new configure options to simplify this. In Python
2.4, you had to configure Python using these  configure options to get a
universal build:

BASECFLAGS="-arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk" LDFLAGS="-arch i386 -arch ppc -isysroot
/Developer/SDKs/MacOSX10.4u.sdk"

... and that shows part of the problem with the Python configure/make
system: it simply doesn't follow the standards used in other OSS
software of passing through CFLAGS et al. to all subsequent compiler and
linker calls.

In order to get compiler options passed through, you have to set BASECFLAGS.

For linker options, you may have some luck with using LDFLAGS, but not
always, since e.g. the configure script may sometimes add LDFLAGS to
LDSHARED (e.g. on Mac OS X using the universal binary options), which
then results in the options to show up twice on the linker line. Using
LDSHARED directly instead then helps.

As a result, simply adding CFLAGS and LDFLAGS to a few more targets
definitions in the Makefile will likely cause more trouble on other
platforms and in other situations.

Overall, the whole configure/Makefile system for defining compiler and
linker options has gotten somewhat messy over the years and much of it
is not documented (at least I'm not aware of any such documentation
apart from the ticket and checkin messages related to the various changes).

I think a first step in the right direction would be to make sure that
LDSHARED never automagically gets additional values from LDFLAGS. Then
we could at least add LDFLAGS to all targets that use LDSHARED as linker
command for shared libs.

As second step, I think that the CFLAGS environment variable passed to
configure should be made to init the BASECFLAGS Makefile variable, since
that's what the user would expect (if he knew how the system works).
History
Date User Action Args
2009-10-29 10:07:54lemburgsetrecipients: + lemburg, loewis, bobatkins, sergiodj, spacey, rpetrov, jprante
2009-10-29 10:07:54lemburgsetmessageid: <1256810874.67.0.236188387569.issue1628484@psf.upfronthosting.co.za>
2009-10-29 10:07:53lemburglinkissue1628484 messages
2009-10-29 10:07:51lemburgcreate