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 bobatkins
Recipients bobatkins, loewis, sergiodj
Date 2008-04-15.08:21:51
SpamBayes Score 0.0026001306
Marked as misclassified No
Message-id <4804659A.1050007@digilink.net>
In-reply-to <48043880.1040106@v.loewis.de>
Content
Martin,

Martin v. Löwis wrote:

It does not when link stage specific options are required that are not 
valid for compilation stages.

My mistake. I was thinking of another package - you can scratch that 
comment.

There is no hard and fast rule that specifying the CFLAGS or other 
configure variables have to override /_*all*_/ of the compile flags that 
a developer chooses to use in their build process. Most open source 
packages use the configure CFLAGS, LDFLAGS, etc, variables to add to the 
compile and link flags and not completely override them. My patch 
follows the same philosophy that I have seen in the majority of other 
open source packages.

On the contrary - it does /_*not*_/ make it more complex and it 
/_*does*_/ provide a solution to a number of compile and link failures 
that have been reported over and over again. When I first posted this 
bug I read through the various forums and bug reports and I noticed 
quite a bit of complaining regarding this issue and I acknowledged that 
by noting in my report that what I was opening a bug report on what was 
clearly a sore subject within the Python community. To be specific the 
complaints were regarding the symptoms (unusual compile and link 
problems) related to this issue, not the specific cause of the problem 
which is why I filed the bug as I did.

The patch that I submitted will allow a build of Python to be performed 
the /_exact_/ same way it is today without any modifications to CFLAGS 
or LDFLAGS, etc. Those of us that /need/ to use these variables will be 
able to modify the build options to the configure script as necessary 
/_*without*_/ any complexity and without losing 'important' compile 
options that are currently generated by configure. All of your 
suggestions to use the CC variable in lieu of using the more appropriate 
CFLAGS, LDFLAGS, etc., introduce the very complexity and non-standard 
approach you are claiming you want top avoid.

Again, I don't see what your concerns are. My patch is a completely 
non-affecting change to the way Python is built today /_*but*_/ it does 
add the necessary fixes so that those that require specific compile and 
link options can specify them to the configure script.

In addition, while you are fixing the build/compile options, I noticed 
that you are missing the -fPIC compile option. Without it you can't link 
shared libraries and the build fails. You should probably be including 
-fPIC as a standard compile option so it is not required to be passed 
into the build via the configure script.

---
Bob
Files
File name Uploaded
unnamed bobatkins, 2008-04-15.08:21:48
History
Date User Action Args
2008-04-15 08:21:52bobatkinssetspambayes_score: 0.00260013 -> 0.0026001306
recipients: + bobatkins, loewis, sergiodj
2008-04-15 08:21:51bobatkinslinkissue1628484 messages
2008-04-15 08:21:51bobatkinscreate