Mailing List Archive: Python: Bugs

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Index | Next | Previous | View Threaded

report at bugs

Oct 29, 2009, 3:07 AM

Post #1 of 24 (235 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1

Marc-Andre Lemburg <mal[at]egenix.com> added the comment:

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).

----------
nosy: +lemburg

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 29, 2009, 3:44 PM

Post #2 of 24 (219 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Roumen Petrov <bugtrack[at]roumenpetrov.info> added the comment:

Only about LDFLAGS.
The python build system evolve and executable and libraries are build
with LDFLAGS as is. So except passing LDFLAGS to setup.py rest of Bob
Atkins patch is in the makefile.

As part of issue 4010 I post a patch "py-issue-4010.patch" (thanks to
John P. Speno that point for quote of LDFLAGS), i.e. same as Bob patch.
The rest of "py-issue-4010.patch" is clean up of configure.in (avoid
options doubling on BSD based plaforms) and setup.py scripts.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 1:46 AM

Post #3 of 24 (216 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Martin v. Löwis <martin[at]v.loewis.de> added the comment:

[...]
> 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).

I still think that such a patch would be flawed, because it *still*
wouldn't follow the standards used in other OSS software, where setting
CFLAGS overrides *ALL* settings that configure may have come up with.

So if a CFLAGS environment variables is to be considered, it needs to
be considered correctly.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 3:00 AM

Post #4 of 24 (215 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Marc-Andre Lemburg <mal[at]egenix.com> added the comment:

Martin v. Löwis wrote:
>
> Martin v. Löwis <martin[at]v.loewis.de> added the comment:
>
> [...]
>> 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).
>
> I still think that such a patch would be flawed, because it *still*
> wouldn't follow the standards used in other OSS software, where setting
> CFLAGS overrides *ALL* settings that configure may have come up with.
>
> So if a CFLAGS environment variables is to be considered, it needs to
> be considered correctly.

Fair enough, then let's do that.

If we go down that road, we'd have to remove BASECFLAGS, OPT and
EXTRA_CFLAGS and replace it with the single standard CFLAGS
variable, or use an approach similar to the one taken for CPPFLAGS
(ie. we allow these extra variables to further customize a CFLAGS
setting):

CPPFLAGS= @BASECFLAGS@ @OPT@ @EXTRA_CFLAGS@ @CFLAGS@

FWIW, the reason behind the extra variables is not really clear. They only
appear to factor out different aspects of the same thing:

r38847 | bcannon | 2005-04-25 00:26:38 +0200 (Mon, 25 Apr 2005) | 6 lines

Introduced EXTRA_CFLAGS as an environment variable used by the Makefile. Meant
to be used for flags that change binary compatibility.

r30490 | montanaro | 2003-01-01 21:07:49 +0100 (Wed, 01 Jan 2003) | 10 lines

Split OPT make variable into OPT and BASECFLAGS. The latter contains those
compiler flags which are necessary to get a clean compile. The former is
for user-specified optimizer, debug, trace fiddling. See patch 640843.

BTW: I've checked the use of LDFLAGS - this is added to LDSHARED
on Mac OS X, FreeBSD, OpenBSD and NetBSD. Perhaps this is something
special needed on BSDish system ?!

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 4:35 AM

Post #5 of 24 (215 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Marc-Andre Lemburg <mal[at]egenix.com> added the comment:

[.Adding Jack Jansen to the nosy list, since he added the LDFLAGS parts
for Mac OS X]

Jack, could you please comment on why the LDFLAGS are added to LDSHARED
by configure, rather than using LDFLAGS as extra argument to LDSHARED ?

Thanks.

----------
nosy: +jackjansen

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 8:52 AM

Post #6 of 24 (214 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Bob Atkins <bob[at]digilink.net> added the comment:

I see that Martin's broken record still hasn't changed. I had warm,
nostalgic feelings as I re-read this thread. It is so sad to see that
this matter remains unresolved almost 3 years after I filed this bug.

As usual Martin is just flat wrong in his insistence that a defined
CFLAGS must overide any generated CFLAGS by configure to be consistent
with other OSS. But of course that is just his excuse for not accepting
this bug and fix. If it wasn't this assertion then he would find
something else equally absurd.

Does anyone know the meaning of NIH?

I'll bet that this matter will never be resolved until the Python
community simply takes Python and re-hosts it somewhere else as
OpenPython. As long as Martin is the gatekeeper you can be assured that
this bug (or any bug) that he doesn't agree with will never be accepted
or fixed and if he does accept this bug - he will insist on doing it the
wrong way (by overriding CFLAGS) to prove he was 'right' all along -
that this bug fix will break more than it fixes.

Keep up the good work Martin. I am expecting that this bug will continue
to provide me with nostalgic memories well into my retirement... ;-)

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 9:04 AM

Post #7 of 24 (214 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Antoine Pitrou <pitrou[at]free.fr> added the comment:

Martin isn't the gatekeeper, it's just that few people are really
motivated in solving tedious configuration-related problems, especially
when there are diverging concerns (legacy, habits, compatibility, etc.)
to take into account.

That said, I think the current CFLAGS situation is counter-intuitive and
would deserve being fixed.

----------
nosy: +pitrou

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 9:19 AM

Post #8 of 24 (214 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Jörg Prante <joergprante[at]gmx.de> added the comment:

> [...] because it *still*
> wouldn't follow the standards used in other OSS software, where setting
> CFLAGS overrides *ALL* settings that configure may have come up with.

Martin, can you please elaborate on this? I never heard of such
"standards" in OSS.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 9:34 AM

Post #9 of 24 (215 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Marc-Andre Lemburg <mal[at]egenix.com> added the comment:

Bob Atkins wrote:
>
> As usual Martin is just flat wrong in his insistence that a defined
> CFLAGS must overide any generated CFLAGS by configure to be consistent
> with other OSS. But of course that is just his excuse for not accepting
> this bug and fix. If it wasn't this assertion then he would find
> something else equally absurd.

I don't think so... we have to support multiple platforms
and doing so is rather difficult in the light of different
requirements and often missing ability to actually test on the
various platforms.

The configure/make system we have in Python has grown a lot over
the years and many people have contributed to it. As a result, it's
not as clean as it could be and there are many aspects that require
inside knowledge about the platforms.

Martin is right in saying that a CFLAGS environment variable has
to override the value determined by configure... see e.g.

http://www.gnu.org/software/hello/manual/autoconf/Preset-Output-Variables.html

However, the situation is a little more complex: CFLAGS should
normally *not* be used by the Makefile for things that configure
finds or regards as not user customizable.

Unfortunately, Python's Makefile does not work that way. It
builds its own CFLAGS value out of a combination of other
variables.

It should really be building a new variable based on CFLAGS and
the other variables and then use that in the build process.

The PY_CFLAGS variable appears to be a start in that direction,
though it's not being followed through.

What makes the situation even more complex is that C extensions
built with distutils will also use these variables for compilation,
so any changes to the way the variables work will have direct effect
on whether or not extensions build out of the box.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 1:33 PM

Post #10 of 24 (213 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Bob Atkins <bob[at]digilink.net> added the comment:

3 years and counting while everyone rings their hands and debates this
trivial issue.

3 years and counting while hundreds of builders encounter this problem
wasting countless of hours troubleshooting, possibly re-reporting the
problem.

Software is not a religion - but many software developers believe it is.

This issue could have been solved 3 years ago and more time spent on
other issues that really matter. Or you can spend the next 3 years
debating the fanatically correct way to solve this problem.

My money is that the fanatically 'correct' method will be implemented
that will require hundreds of lines of code, possibly re-engineering the
entire build process, introducing more problems and take a few more
years to implement and release.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 2:07 PM

Post #11 of 24 (213 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Marc-Andre Lemburg <mal[at]egenix.com> added the comment:

Bob Atkins wrote:
> My money is that the fanatically 'correct' method will be implemented
> that will require hundreds of lines of code, possibly re-engineering the
> entire build process, introducing more problems and take a few more
> years to implement and release.

Well, I guess that's not your problem anymore... you have your patch
and it works for you and perhaps a few others as well. That's fine
for the time being.

Without knowing the impact of the generic approach you've taken
in your patch we simply cannot just apply it. If you can prove that
the patch doesn't break other platforms or configuration setups,
that would help a lot.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 2:16 PM

Post #12 of 24 (213 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Jack Jansen <jackjansen[at]users.sourceforge.net> added the comment:

> Jack, could you please comment on why the LDFLAGS are added to
LDSHARED
> by configure, rather than using LDFLAGS as extra argument to LDSHARED
?

Because this worked, no deep reason. The initial framework builds were a
big hack, because they were neither static nor shared builds (because
the extensions were linked against the framework), so I had to find
something that worked while hoping I wouldn't break too much on other
platforms.

In case anyone is interested in my opinion: I would scratch the whole
configure/make suite and rebuild it from scratch. As others here have
noticed, the OPT/EXTRA_CFLAGS pattern that Python adhered to has lost
out the the CFLAGS/LDFLAGS pattern, and more such things. And this is
important if people want to do recursive builds.

But: it's a major undertaking to get this working, especially if you
don't want to pull in libtool:-(

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 2:31 PM

Post #13 of 24 (209 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Jörg Prante <joergprante[at]gmx.de> added the comment:

> Without knowing the impact of the generic approach you've taken
> in your patch we simply cannot just apply it. If you can prove that
> the patch doesn't break other platforms or configuration setups,
> that would help a lot.

I was able to build Python 2.5 on Solaris 10 Sparc, Mac OS X PPC, Linux
PPC/Intel, all 32bit and 64bit, shared and static, only with Bob's help.

It's not a proof. It's not mathematical correct. But it works. Grab all
your avalaible test platforms and try for yourself what Bob's patch will
'break', and report it.

Sorry, but that meta discussions about correct builds are not what a bug
report should be used for. Such improvements are up to developer forums
where you can design "correct" Python build scripts and discuss them
over and over again.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 3:10 PM

Post #14 of 24 (209 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Peter N <spacey-bugs.python.org[at]ssr.com> added the comment:

On Fri, Oct 30, 2009 at 09:31:38PM +0000, J??rg Prante wrote:
>
> J??rg Prante <joergprante[at]gmx.de> added the comment:
>
> > Without knowing the impact of the generic approach you've taken
> > in your patch we simply cannot just apply it. If you can prove that
> > the patch doesn't break other platforms or configuration setups,
> > that would help a lot.
>
> I was able to build Python 2.5 on Solaris 10 Sparc, Mac OS X PPC, Linux
> PPC/Intel, all 32bit and 64bit, shared and static, only with Bob's help.

Ditto for python 2.5 on Solaris 10 x86 64-bit. It was simply
impossible without these patches.

> It's not a proof. It's not mathematical correct. But it works. Grab all
> your avalaible test platforms and try for yourself what Bob's patch will
> 'break', and report it.
>
> Sorry, but that meta discussions about correct builds are not what a bug
> report should be used for. Such improvements are up to developer forums
> where you can design "correct" Python build scripts and discuss them
> over and over again.

Agreed. +1 from me if it counts for anything (which it probably doesn't).

-Peter

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 3:12 PM

Post #15 of 24 (209 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Antoine Pitrou <pitrou[at]free.fr> added the comment:

First, the current patch doesn't apply cleanly to trunk. The following
patch should be ok (some of the changes of the original patch apparently
have been committed separately in the meantime).

Second, the patch allows me to do a 32-bit build (under 64-bit Linux) by
doing:
CFLAGS=-m32 LDFLAGS=-m32 ./configure
rather than:
CC="gcc -m32" ./configure
However, if I omit LDFLAGS it doesn't work, I don't know if it's intended.

Third, while the 32-bit build does work, the shared objects are still
placed in a directory called "lib.linux-x86_64-2.7", which I suppose is
wrong:

$ ./python
Python 2.7a0 (trunk:75966:75967M, Oct 30 2009, 22:55:18)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import _socket
>>> _socket.__file__
'/home/antoine/cpython/__svn__/build/lib.linux-x86_64-2.7/_socket.so'

$ file /home/antoine/cpython/__svn__/build/lib.linux-x86_64-2.7/_socket.so
/home/antoine/cpython/__svn__/build/lib.linux-x86_64-2.7/_socket.so: ELF
32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically
linked, not stripped

----------
keywords: +patch
Added file: http://bugs.python.org/file15236/Makefile.pre.in.patch

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 3:42 PM

Post #16 of 24 (209 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Roumen Petrov <bugtrack[at]roumenpetrov.info> added the comment:

Marc-Andre,
Thanks for the reference but what about to open manual for AC_PROG_CC ?

Antoine,
please don't mess kind of cross compilation into this thread.

About patches:
Change of libdir are subject to other requests - require changes in
distutils - out of scope.

About CFLAGS :
To ignore options like -g -O2 set by AC_PROG_CC just enclose macro in
py_save_CFLAGS ... CFLAGS=$py_save_CFLAGS. Тhe python build system use
own options OPT to set -g -O3 and etc. Please see comments in configure
for OPT.

About LDFLAGS with passing to setup.py (last place without it) is good
to remove all other references as I do in other issue . I won't update
my patch to apply cleanly to trunk if there is no interest.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 3:45 PM

Post #17 of 24 (209 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Marc-Andre Lemburg <mal[at]egenix.com> added the comment:

Antoine Pitrou wrote:
> Second, the patch allows me to do a 32-bit build (under 64-bit Linux) by
> doing:
> CFLAGS=-m32 LDFLAGS=-m32 ./configure
> rather than:
> CC="gcc -m32" ./configure
> However, if I omit LDFLAGS it doesn't work, I don't know if it's intended.

Without the patch,

BASECFLAGS=-m32 LDFLAGS=-m32 ./configure

should work the same way.

LDFLAGS defines the linker options, CFLAGS the compiler options,
and since both tools have to know that you're generating 32-bit code,
you have to pass the option to both env vars.

> Third, while the 32-bit build does work, the shared objects are still
> placed in a directory called "lib.linux-x86_64-2.7", which I suppose is
> wrong:

That's a side-effect of distutils using os.uname() for determining
the platform. It doesn't know that you're actually telling the
compiler to build a 32-bit binary.

On some platforms you can use these commands to emulate 32- or
64-bit environments:

$ linux32 python -c 'import os; print os.uname()'
('Linux', 'newton', '2.6.22.19-0.4-default', '#1 SMP 2009-08-14 02:09:16 +0200', 'i686')
$ linux64 python -c 'import os; print os.uname()'
('Linux', 'newton', '2.6.22.19-0.4-default', '#1 SMP 2009-08-14 02:09:16 +0200', 'x86_64')

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 3:46 PM

Post #18 of 24 (210 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Antoine Pitrou <pitrou[at]free.fr> added the comment:

> Antoine,
> please don't mess kind of cross compilation into this thread.

This is not cross-compilation, a 32-bit binary will run fine on a x86-64
system.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 4:08 PM

Post #19 of 24 (209 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Marc-Andre Lemburg <mal[at]egenix.com> added the comment:

Roumen Petrov wrote:
>
> Roumen Petrov <bugtrack[at]roumenpetrov.info> added the comment:
>
> Marc-Andre,
> Thanks for the reference but what about to open manual for AC_PROG_CC ?

Could you please elaborate a bit ?

> Antoine,
> please don't mess kind of cross compilation into this thread.

That was just an example of how CFLAGS can be used.

However, with the patch you still don't get complete control
of the C compiler flags - which is what the env var should
be all about.

The reason is that the actually used CFLAGS argument then
becomes a combination of these env vars/settings:

CFLAGS= $(BASECFLAGS) @CFLAGS@ $(OPT) $(EXTRA_CFLAGS)

To regain control over CFLAGS, you'd have to define these
env vars:

CFLAGS, BASECFLAGS, OPT, EXTRA_CFLAGS

That's not really how it should be... (see the autoconf
reference URL I posted).

> About patches:
> Change of libdir are subject to other requests - require changes in
> distutils - out of scope.

True.

> About CFLAGS :
> To ignore options like -g -O2 set by AC_PROG_CC just enclose macro in
> py_save_CFLAGS ... CFLAGS=$py_save_CFLAGS. Тhe python build system use
> own options OPT to set -g -O3 and etc. Please see comments in configure
> for OPT.

In the early days we only allowed customization of the optimization
settings when compiling Python, nothing more. That's where OPT
originated.

Things started to get complicated when the recursive make process
was flattened starting in Python 2.1.

> About LDFLAGS with passing to setup.py (last place without it) is good
> to remove all other references as I do in other issue . I won't update
> my patch to apply cleanly to trunk if there is no interest.

Could you provide an issue number ?

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 4:18 PM

Post #20 of 24 (209 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Marc-Andre Lemburg <mal[at]egenix.com> added the comment:

Jack Jansen wrote:
>
> Jack Jansen <jackjansen[at]users.sourceforge.net> added the comment:
>
>> Jack, could you please comment on why the LDFLAGS are added to
> LDSHARED
>> by configure, rather than using LDFLAGS as extra argument to LDSHARED
> ?
>
> Because this worked, no deep reason. The initial framework builds were a
> big hack, because they were neither static nor shared builds (because
> the extensions were linked against the framework), so I had to find
> something that worked while hoping I wouldn't break too much on other
> platforms.

Well, it does break on Mac OS X (and only there) now, since for
universal builds, the Mac gcc complains if you pass in the
-sysroot option more than once :-)

I was under the impression that the "-bundle" option was
needed as last linker option and that this was the reason
for adding LDFLAGS directly into LDSHARED.

But if there are no deep reasons, then I'd suggest to not add
LDFLAGS to LDSHARED anymore and instead just use it normally.

> In case anyone is interested in my opinion: I would scratch the whole
> configure/make suite and rebuild it from scratch. As others here have
> noticed, the OPT/EXTRA_CFLAGS pattern that Python adhered to has lost
> out the the CFLAGS/LDFLAGS pattern, and more such things. And this is
> important if people want to do recursive builds.

Even though we do have a flat Makefile now, there still is
some recursion left: Python uses distutils to build most of the
included C extension modules.

Part of the patch targets exactly this recursion: LDFLAGS
is currently not being passed on to the shared mod build
sub-process.

> But: it's a major undertaking to get this working, especially if you
> don't want to pull in libtool:-(

What if we just remove all the extra cruft and just use
CFLAGS ?

LDFLAGS is not such a mess. It just needs to be propagated
to all parts of the process.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 30, 2009, 4:45 PM

Post #21 of 24 (201 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Roumen Petrov <bugtrack[at]roumenpetrov.info> added the comment:

Mark issue is 4010 (see message #msg94686 above) .

About the control of the flags :) ... the Bob's post "... method will be
implemented that will require hundreds of lines of code ..." is true.

Order $(BASECFLAGS) @CFLAGS@ $(OPT) $(EXTRA_CFLAGS) look good as first
start with project CFLAGS followed by env. CFLAGS and why will read
README file for OPT and EXTRA_CFLAGS ?

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Oct 31, 2009, 1:04 AM

Post #22 of 24 (188 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Martin v. Löwis <martin[at]v.loewis.de> added the comment:

> Martin, can you please elaborate on this? I never heard of such
> "standards" in OSS.

MAL already gave the link. From the link:

Sometimes package developers are tempted to set user variables such as
CFLAGS because it appears to make their job easier. However, the package
itself should never set a user variable, particularly not to include
switches that are required for proper compilation of the package. Since
these variables are documented as being for the package builder, that
person rightfully expects to be able to override any of these variables
at build time.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 1, 2009, 11:14 PM

Post #23 of 24 (137 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Changes by Ronald Oussoren <ronaldoussoren[at]mac.com>:

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Nov 2, 2009, 12:57 PM

Post #24 of 24 (115 views)
Permalink

[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1 [In reply to]

Roumen Petrov <bugtrack[at]roumenpetrov.info> added the comment:

> > Martin, can you please elaborate on this? I never heard of such
> > "standards" in OSS.
>
> MAL already gave the link. From the link:
>
> Sometimes package developers are tempted to set user variables such as
> CFLAGS because it appears to make their job easier. However, the package
> itself should never set a user variable, particularly not to include
> switches that are required for proper compilation of the package. Since
> these variables are documented as being for the package builder, that
> person rightfully expects to be able to override any of these variables
> at build time.

So one day package builder by right will set CFLAGS to make their job
easier and python build system will not ignore it.

----------

_______________________________________
Python tracker <report[at]bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com