Bob Atkins <[EMAIL PROTECTED]> added the comment:
Martin,
I've been quietly reading all of the back and forth regarding this problem.
Your suggestion for using the CC variable to fix the problem that I
reported won't work - I already tried it and based on what others are
reporting, you are beating a dead horse. Believe me I would rather not
modify anyone's code in order to build something. The problem is that
the CC variable doesn't fix the link stages and overall your autconf
build is broken particularly as it relates to flowing variables down to
sub builds.
I don't know why you are resisting this change. I took the time to
report the bug, proposed a fix /_*and*_/ contributed the patch that
would make the Python build process more standard relative to the vast
majority of open source packages that use autoconf. I am glad to see
that my patch appears to be generic enough that it works on other
platforms as well. I didn't have to post a bug report let alone
contribute a patch but, I believe strongly that is what open source is
all about. As the maintainer you don't have to accept either the bug or
the patch but, resisting without good cause will discourage further
contributions - certainly from me because I won't waste my time
submitting something when I know that a maintainer of a package is being
closed minded. We do a lot of work with open source software here and it
is our policy to contribute back to the community as much as possible.
However, when we run into a brick wall we quickly give up because we
can't justify the time and effort. As an example, we have completely
suspended all contributions to the asterisk project. We operate a very
large asterisk environment with a lot of fixes and improvements that I
am sure lots of others would love to have but the maintainer's attitude
was that a Sun Solaris platform was not important. What the maintainer
doesn't know is that many of our fixes and changes affect /_*all*_/
platforms. So now they get nothing from us and the asterisk community as
a whole is deprived of the benefits of our work. I also know that many
others have also suspended contributions for the same reason and as a
result the asterisk package suffers. The resistance on your part to
recognizing this problem and a fix is unjustified.
Overall it improves the Python package if it can be built on more
platforms in different ways - especially if it uses the standard
autoconf approach that the majority of other open source packages use.
Those of us that have to deal with building almost a hundred different
packages for different platforms and architectures very much appreciate
not having to deal with unnecessary exceptions or idiosyncrasies.
I don't care whether you incorporate the change or not - we certainly
will continue to patch future versions of Python (we have a fully
automated build process here) in order to produce a successful build.
Clearly the genie is out of the bottle and others will also likely use
the patch for their builds. Why not just make everyone happy and
incorporate it or a reasonably similar approach that properly implements
the flow of /_*all*_/ autoconf variables to the sub-builds of the Python
package so that more people can take full advantage of Python on their
64 bit platforms and also deal with whatever unique build requirements
that they might have.
Sincerely,
Bob Atkins
Martin v. Löwis wrote:
>Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>
>
>
>>This is what you get when you try to build a 64-bit Python on a biarch
>>machine (64-bit kernel, 32-bit userspace), using a gcc that generates
>>natively 32-bit objects (therefore, you *must* pass the '-m64' option
>>for the compiler):
>>
>>
>
>Or you install an additional, different, C compiler that defaults to
>AMD64.
>
>
>
>>1) As you could see above, actually you need CFLAGS in order to compile
>>Python correctly. As far as I could investigate, the reason you need
>>this is because of the tests that are done by configure. Without the
>>CFLAGS, configure will think it's building a 32-bit Python, despite of
>>the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS
>>through Makefile or not? IMHO, we do.
>>
>>
>
>Not necessarily. I think you can achieve the same effect by specifying
>CC="gcc -m64" to configure.
>
>
>
>>2) Even with CFLAGS and BASECFLAGS set, the compilation fails. Using
>>LDFLAGS makes the compilation process continue a little more, but it
>>still doesn't solve the problem. AFAIK, the reason it doesn't solve the
>>problem is, again, because we are not propagating it through the
>>Makefile. Can you see any different reason? Also, should we propagate
>>LDFLAGS through Makefile? IMHO, we should.
>>
>>
>
>Again, if you specify CC as above, you don't have to.
>
>
>
>>Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'.
>>But again, I don't think this is a solution for this issue :-).
>>
>>
>
>Why not?
>
>Regards,
>Martin
>
>_____________________________________
>Tracker <[EMAIL PROTECTED]>
><http://bugs.python.org/issue1628484>
>_____________________________________
>
>
>
>
Added file: http://bugs.python.org/file10031/unnamed
_____________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1628484>
_____________________________________
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
Martin,<br>
<br>
I've been quietly reading all of the back and forth regarding this
problem.<br>
<br>
Your suggestion for using the CC variable to fix the problem that I
reported won't work - I already tried it and based on what others are
reporting, you are beating a dead horse. Believe me I would rather not
modify anyone's code in order to build something. The problem is that
the CC variable doesn't fix the link stages and overall your autconf
build is broken particularly as it relates to flowing variables down to
sub builds.<br>
<br>
I don't know why you are resisting this change. I took the time to
report the bug, proposed a fix <i><u><b>and</b></u></i> contributed
the patch that would make the Python build process more standard
relative to the vast majority of open source packages that use
autoconf. I am glad to see that my patch appears to be generic enough
that it works on other platforms as well. I didn't have to post a bug
report let alone contribute a patch but, I believe strongly that is
what open source is all about. As the maintainer you don't have to
accept either the bug or the patch but, resisting without good cause
will discourage further contributions - certainly from me because I
won't waste my time submitting something when I know that a maintainer
of a package is being closed minded. We do a lot of work with open
source software here and it is our policy to contribute back to the
community as much as possible. However, when we run into a brick wall
we quickly give up because we can't justify the time and effort. As an
example, we have completely suspended all contributions to the asterisk
project. We operate a very large asterisk environment with a lot of
fixes and improvements that I am sure lots of others would love to have
but the maintainer's attitude was that a Sun Solaris platform was not
important. What the maintainer doesn't know is that many of our fixes
and changes affect <i><u><b>all</b></u></i> platforms. So now they get
nothing from us and the asterisk community as a whole is deprived of
the benefits of our work. I also know that many others have also
suspended contributions for the same reason and as a result the
asterisk package suffers. The resistance on your part to recognizing
this problem and a fix is unjustified.<br>
<br>
Overall it improves the Python package if it can be built on more
platforms in different ways - especially if it uses the standard
autoconf approach that the majority of other open source packages use.
Those of us that have to deal with building almost a hundred different
packages for different platforms and architectures very much appreciate
not having to deal with unnecessary exceptions or idiosyncrasies. <br>
<br>
I don't care whether you incorporate the change or not - we certainly
will continue to patch future versions of Python (we have a fully
automated build process here) in order to produce a successful build.
Clearly the genie is out of the bottle and others will also likely use
the patch for their builds. Why not just make everyone happy and
incorporate it or a reasonably similar approach that properly
implements the flow of <i><u><b>all</b></u></i> autoconf variables to
the sub-builds of the Python package so that more people can take full
advantage of Python on their 64 bit platforms and also deal with
whatever unique build requirements that they might have.<br>
<br>
Sincerely,<br>
Bob Atkins<br>
<br>
Martin v. Löwis wrote:
<blockquote cite="mid:[EMAIL PROTECTED]" type="cite">
<pre wrap="">Martin v. Löwis <a class="moz-txt-link-rfc2396E"
href="mailto:[EMAIL PROTECTED]"><[EMAIL PROTECTED]></a> added the
comment:
</pre>
<blockquote type="cite">
<pre wrap="">This is what you get when you try to build a 64-bit Python on
a biarch
machine (64-bit kernel, 32-bit userspace), using a gcc that generates
natively 32-bit objects (therefore, you *must* pass the '-m64' option
for the compiler):
</pre>
</blockquote>
<pre wrap=""><!---->
Or you install an additional, different, C compiler that defaults to
AMD64.
</pre>
<blockquote type="cite">
<pre wrap="">1) As you could see above, actually you need CFLAGS in order
to compile
Python correctly. As far as I could investigate, the reason you need
this is because of the tests that are done by configure. Without the
CFLAGS, configure will think it's building a 32-bit Python, despite of
the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS
through Makefile or not? IMHO, we do.
</pre>
</blockquote>
<pre wrap=""><!---->
Not necessarily. I think you can achieve the same effect by specifying
CC="gcc -m64" to configure.
</pre>
<blockquote type="cite">
<pre wrap="">2) Even with CFLAGS and BASECFLAGS set, the compilation fails.
Using
LDFLAGS makes the compilation process continue a little more, but it
still doesn't solve the problem. AFAIK, the reason it doesn't solve the
problem is, again, because we are not propagating it through the
Makefile. Can you see any different reason? Also, should we propagate
LDFLAGS through Makefile? IMHO, we should.
</pre>
</blockquote>
<pre wrap=""><!---->
Again, if you specify CC as above, you don't have to.
</pre>
<blockquote type="cite">
<pre wrap="">Ohh, before I forget: compilation succeeds if we use only
CC='gcc -m64'.
But again, I don't think this is a solution for this issue :-).
</pre>
</blockquote>
<pre wrap=""><!---->
Why not?
Regards,
Martin
_____________________________________
Tracker <a
class="moz-txt-link-rfc2396E" href="mailto:[EMAIL PROTECTED]"><[EMAIL
PROTECTED]></a>
<a class="moz-txt-link-rfc2396E"
href="http://bugs.python.org/issue1628484";><http://bugs.python.org/issue1628484></a>
_____________________________________
</pre>
</blockquote>
<br>
<div class="moz-signature">
<p>Â </p>
</div>
</body>
</html>
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
