Thread: python / 7.4 / FC5 / x86_64
I see that my new 64 bit / FC5 buildfarm member died on building 7.4
due to the following line in the configure script:
python_configdir="${python_execprefix}/lib/python${python_version}/config"
On my machine, this should be lib64, not lib. In fact, both
/usr/lib/python2.4 and /usr/lib64/python2.4 exist, so I can't just use a
soft link to get around this.
I could just disable building with python on that branch on my buildfarm
member. Or we could fix it in the config script properly, although I am
not sure how possible that is, nor if it is at all worth it -
backporting the 8.0 changes would be the way I guess.
Thoughts?
cheers
andrew
Am Dienstag, 29. August 2006 16:25 schrieb Andrew Dunstan: > On my machine, this should be lib64, not lib. In fact, both > /usr/lib/python2.4 and /usr/lib64/python2.4 exist, so I can't just use a > soft link to get around this. Ideally, we would get Python to tell us the right location, because "use lib64 if it exists" isn't the right solution. Is this fixed somewhere post 7.4? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Andrew Dunstan wrote:
>
> I see that my new 64 bit / FC5 buildfarm member died on building 7.4
> due to the following line in the configure script:
>
> python_configdir="${python_execprefix}/lib/python${python_version}/config"
>
> On my machine, this should be lib64, not lib. In fact, both
> /usr/lib/python2.4 and /usr/lib64/python2.4 exist, so I can't just use a
> soft link to get around this.
>
> I could just disable building with python on that branch on my buildfarm
> member. Or we could fix it in the config script properly, although I am
> not sure how possible that is, nor if it is at all worth it -
> backporting the 8.0 changes would be the way I guess.
>
> Thoughts?
Use a different CPP_FLAGS? That is what we have to do on our hosting-two
box.
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL
solutionssince 1997 http://www.commandprompt.com/
Peter Eisentraut wrote: > Am Dienstag, 29. August 2006 16:25 schrieb Andrew Dunstan: > >> On my machine, this should be lib64, not lib. In fact, both >> /usr/lib/python2.4 and /usr/lib64/python2.4 exist, so I can't just use a >> soft link to get around this. >> > > Ideally, we would get Python to tell us the right location, because "use lib64 > if it exists" isn't the right solution. > > Is this fixed somewhere post 7.4? > > Yes, but it was never backported. See: http://developer.postgresql.org/cvsweb.cgi/pgsql/config/python.m4 cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes: > Peter Eisentraut wrote: >> Ideally, we would get Python to tell us the right location, because "use lib64 >> if it exists" isn't the right solution. >> >> Is this fixed somewhere post 7.4? > Yes, but it was never backported. See: > http://developer.postgresql.org/cvsweb.cgi/pgsql/config/python.m4 My recollection is that there are a number of interrelated changes going on there, and that a backport would have to touch a lot more than just the python stuff. So I'd recommend that it's not worth the trouble/risk. But if you want to have a go at extracting a small patch from the CVS history, have at it. regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> Peter Eisentraut wrote: >> >>> Ideally, we would get Python to tell us the right location, because "use lib64 >>> if it exists" isn't the right solution. >>> >>> Is this fixed somewhere post 7.4? >>> > > >> Yes, but it was never backported. See: >> http://developer.postgresql.org/cvsweb.cgi/pgsql/config/python.m4 >> > > My recollection is that there are a number of interrelated changes going > on there, and that a backport would have to touch a lot more than just > the python stuff. So I'd recommend that it's not worth the trouble/risk. > But if you want to have a go at extracting a small patch from the CVS > history, have at it. > > > Patch attached - seems to work on my FC5/x86_64 box. Also contains the OSX fix backported. Not sure that it qualifies as small though :-) Unless there's an objection I will apply this soon (when were we thinking of putting out the new point releases?) cheers andrew
Am Montag, 4. September 2006 04:06 schrieb Andrew Dunstan: > Patch attached - seems to work on my FC5/x86_64 box. Also contains the > OSX fix backported. Not sure that it qualifies as small though :-) It looks pretty scary to me. Didn't we say once that we don't want to backport fixes for platforms that didn't exist at the time of first release? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Montag, 4. September 2006 04:06 schrieb Andrew Dunstan:
>> Patch attached - seems to work on my FC5/x86_64 box. Also contains the
>> OSX fix backported. Not sure that it qualifies as small though :-)
> It looks pretty scary to me.
> Didn't we say once that we don't want to backport fixes for platforms that
> didn't exist at the time of first release?
There's no agreed-on policy that says that, but I'd sure be hesitant to
make any invasive changes in support of adding a new port. However,
this patch doesn't look unreasonably scary to me --- AFAICS it's just
syncing python.m4 and the plpython Makefile with 8.0's versions. I
guess the question is does it break any old platforms? Are we
comfortable with the buildfarm's coverage for python on 7.4?
regards, tom lane