[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: Hi Martin, On Mon, 2008-04-14 at 20:04 +, 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. I cannot do that. Actually, even if I could, I don't think this is the best way to handle this *Python*'s problem. 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. I know that. But the purpose of CC flag is to define a compiler to be used in the compilation, and not to specify compiler flags (for that, we have CFLAGS). 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? See above. Regards, _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: On Tue, 2008-04-15 at 02:01 +, Bob Atkins wrote: 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. Bob just took the words from my mouth. Martin, with all respect, your resistance in accepting this patch is making things much harder that they really are. The main point here is that this pacth actually *doesn't* break anything in Python! Please, take a time to consider our proposal. Thanks, _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: Hi Martin, 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): # ./configure --enable-shared --target=powerpc64-unknown-linux BASECFLAGS='-m64' output generated by configure script # make gcc -pthread -c -m64 -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from Include/Python.h:57, from ./Modules/python.c:3: Include/pyport.h:761:2: error: #error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?). make: *** [Modules/python.o] Error 1 As you can see, the compilation fails. Now, if I try this configure line: # ./configure --enable-shared --target=powerpc64-unknown-linux BASECFLAGS='-m64' CFLAGS='-m64' output from configure # make Compilation goes well untill: gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl -lutil -o Parser/pgen As you can see, in this specific line we don't have the '-m64' flag, what causes a bunch of errors (all of them due to the absence of '-m64' flag). Ok, so I decided to try with LDFLAGS: # ./configure --enable-shared --target=powerpc64-unknown-linux BASECFLAGS='-m64' CFLAGS='-m64' LDFLAGS='-m64' output from configure # make Now, the error happens when libpython.so is generated (and the reason is the same: missing '-m64'). Well, now I have a few questions: 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. 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. 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 :-). _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: Hi Martin, Actually, I know that you can use CC to do it, but IMHO that's not the correct approach. I understand too you concern about adding @CFLAGS@, but I think the user should be able to define his/her own CFLAGS, and this is not implemented yet. Do you agree with that? Regards. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue858809] Use directories from configure rather than hardcoded
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: Hi, Continuing with my effort to improve Python's build system, I'd really like to know why this issue has not been solved yet. I mean, apparently this problem is still present in Python 2.5, since I can't change the library's path with --libdir configure's flag. Any news about it? -- nosy: +sergiodj Tracker [EMAIL PROTECTED] http://bugs.python.org/issue858809 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: Hi, I'd like to know the status of this issue. I'm having the same problems here with PPC64, and the patch that Bob Atkins has sent works fine for me too. Would you intend to apply this patch in upstream? Thanks in advance. -- nosy: +sergiodj _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: Hi Martin, Thanks for your quick answer. I'd like to know what can we do to push this patch into upstream. Does the fact that the patch is posted in a bug report (and not in a developer's mailing list) is slowing down the reviewing process? Regards. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
