[issue27849] that is so great!
New submission from David Kirkby: Hey, Look what I've just found on the web! It's so amazing, check it out <http://guxustatri.scalrentals.com/aednig> Yours, david.kirkby -- messages: 273550 nosy: drkirkby priority: normal severity: normal status: open title: that is so great! ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1759169] clean up Solaris port and allow C99 extension modules
David Kirkby david.kir...@onetel.net added the comment: Is there any progress on this? I see it is marked as Status: closed Resolution: accepted Stage: patch review That apparently means: ''There is a patch, but it needs reviewing or is in the process of being reviewed. This can be done by any triager as well as a core developer.'' So is there any movement on this, which will allow it to be fixed? I'm somewhat puzzled the Status is marked as closed when apparently the patch is still awaiting review. Dave -- nosy: +drkirkby ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1759169 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11667] 'configure' script overrides users setting of CFLAGS
David Kirkby david.kir...@onetel.net added the comment: Yes, I think this could do with being documented, as it is not obvious. Generally one would expect CFLAGS to do this, and not OPT. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11667] 'configure' script overrides users setting of CFLAGS
David Kirkby david.kir...@onetel.net added the comment: Thank you. That solved it, so you can close this. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6006] ffi.c compile failures on AIX 5.3 with xlc
David Kirkby david.kir...@onetel.net added the comment: I've just downloaded libffi-3.0.9 (the latest) and it builds with no problems on my AIX 5.3 system. Is there any chance of the version of libffi in Python being updated? -- nosy: +drkirkby ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11667] 'configure' script overrides users setting of CFLAGS
New submission from David Kirkby david.kir...@onetel.net: I'm trying to build a version of Python *without* debugging information. The reason for me wanting to do this is because there is a bug which is either in gcc or AIX , that prevents recently patched versions of AIX building code where there are static variables that are unitilized. So I have tried $ export CFLAGS=-g0 $export CXXFLAGS=-g0 The -g0 should disable debugging information. But instead the option occurs before the automatically inserted options, so I see: gcc -c -fno-strict-aliasing -g0 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Parser/pgen.o Parser/pgen.c Because of this, the -g overrides the -g0 and I get debugging information. Is there any way to not add -g when building Python? -- components: Installation messages: 132056 nosy: drkirkby priority: normal severity: normal status: open title: 'configure' script overrides users setting of CFLAGS type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment: Thank you Mark for confirming what I found. I understand your reservations about the code if you don't know of its correctness. I must admit I don't myself. I don't have a clue how this _socket module should be built. But it is clear to me that the original code is attempting to compile code using PACKET_LOOPBACK, PACKET_FASTROUTE and SIOCGIFNAME, despite they are not defined. Although I'm not a mind-reader, I believer the original programmer probably thought they were defined in the header file netpacket/packet.h, when in fact they are not on Solaris. I wish I could take Martin v. Löwis up on his 5-for-one deal, where I review 5 issues and he deals with this one. Unfortunately, I'm very new to python, so really are not going to be a lot of help to anyone in reviewing issues. I will just have to keep that patch in Sage until it either gets to the top of Martin's TODO list, or someone else deals with it. Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Hi, __EXTENSIONS__ is defined to 1. Give me an hour, and I'll attach a log. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Here's a build done the same way as you. This gives the same result as you here. But an attempt to run the test suite fails because of _socket. I need to patch that in order that I can run the test suite. See http://bugs.python.org/issue8852 -- Added file: http://bugs.python.org/file17775/build-with_socket-failure.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Here's the header file that gets created -- Added file: http://bugs.python.org/file17776/pyconfig.h ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Sorry, I seem to have wasted a lot of your time here. Python was built from a script which applied some patches - including that one that allows _socket to build. Without that (which is not commit to python and I'm told it might not be done this year), its impossible to run the test suite. It looks like of the patches has messed up with test_float. Unfortunately, if I just apply the patch at issue8852, then the test suite hangs at: test_posix It's used 48 minutes of CPU time on a 3.33 GHz Xeon as I write, passing most tests up to test_posix, but hanging there. Sorry to have wasted your time. BTW, are you able to run the full test suite, or does the test suite simply not run at all? Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment:
I think I spoke too soon.
I just downloaded the 2.7.rc2. Using both 32 and 64-bit builds, with the only
patch being that I attached to issue8852 some months back, the problem occurs
again.
test_float
test test_float failed -- Traceback (most recent call last):
File /export/home/drkirkby/Python-2.7rc2/Lib/test/test_float.py, line 1297,
in test_roundtrip
self.identical(-x, roundtrip(-x))
File /export/home/drkirkby/Python-2.7rc2/Lib/test/test_float.py, line 907,
in identical
self.fail('%r not identical to %r' % (x, y))
AssertionError: -0.0 not identical to 0.0
test_fnmatch
test_fork1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8852
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment: Sorry, I put that note on the wrong issue! ignore it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment:
test_float
test test_float failed -- Traceback (most recent call last):
File /export/home/drkirkby/Python-2.7rc2/Lib/test/test_float.py, line 1297,
in test_roundtrip
self.identical(-x, roundtrip(-x))
File /export/home/drkirkby/Python-2.7rc2/Lib/test/test_float.py, line 907,
in identical
self.fail('%r not identical to %r' % (x, y))
AssertionError: -0.0 not identical to 0.0
test_fnmatch
test_fork1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Sorry, I missed out the comment there. This is failing for me, in boht 32 and 64-bit builds with Python-2.7rc2 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: I'm glad you can reproduce it! I can understand you wanting to close it in this case. I've no problem with that. To me at least, it does not seem anywhere near as serious as the other problem. I will try it on Linux though. I have access to reasonably decent (24 core) Linux box, so I'll try it on that. But it means a lot of messing around, downloading mpir, mpfr, possibly newer versions of the GNU binutils etc. Not a 5 minute job. The weather here in the UK is too nice to site behind a computer screen! Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment:
Hi,
I had hoped to devote more time to this, but have been able to. I will do at
the weekend.
I would add I was building 64-bit, so adding the compiler flag -m64 on 'hawk'
at least some of the time. Depending on your hardware, assuming you have
installed !OpenSolaris as a Virtual machine in VirtualBox, it may be a 32 or
64-bit version of OpenSolaris. You need specific instructions from the
processor for a 64-bit version and Sony in their infinite wisdom have disabled
it on my Vaio laptop, so whilst I can install OpenSolaris as a 64-bit host
operating system, any attempt to install a 64-bit guest will fail.
If I don't chose to compile C99, then I need to add the compiler flag
-DHAVE_DECL_ISFINITE=0.
Otherwise I see:
Objects/object.c:1036: warning: implicit declaration of function 'isinf'
Undefined first referenced
symbol in file
isfinite./libpython2.6.so
ld: fatal: symbol referencing errors. No output written to python
Again, the Solaris man page says:
Mathematical Library Functions isfinite(3M)
NAME
isfinite - test for finite value
SYNOPSIS
c99 [ flag... ] file... -lm [ library... ]
#include math.h
int isfinite(real-floating x);
implying this is a C99 function.
This conflicting behavior could be the result of what linker or assembler is
being used. On SPARC, I use Sun linker and assembler. On OpenSolaris I use the
Sun linker, but the GNU assembler.
I would have thought it was better to test this out with small bits of test
code like I posted, rather than the complete Python source code.
It might be better if I just create you an account on 'hawk'. Drop me an email
at david dot kirkby {at} onetel |dot| net if you want.
I can also get you an account at the University of Washington if you want on a
Sun T5240 SPARC. I've not verified the problem on that machine, but I can do
so. Just drop me an email with a preferred user name and I'll sort it out.
The SPARC is very slow - despite it being a current model of a high end server.
It is designed for a different sort of task to developing software. The CPUs
are pretty slow (1167 MHz) and pretty dumb, but there are 128 hardware threads.
In order to get any useful performance from the T5240, the code needs to be
highly parallel or have lots of processes like on busy web servers. That is
what 't2' is designed for - a high end web server.
But 'hawk' is a pretty high spec PC which I run 24/7.
Dave
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8265] test_float fails on ARM Linux EABI with soft floating point
David Kirkby david.kir...@onetel.net added the comment: I'm seeing this failure on both Solaris 10 (SPARC processor) in 32-bit mode and OpenSolaris 06/2009 (Intel Xeon) in 64-bit mode using Python 2.6.4. So it is not just an ARM Linux issue. See http://trac.sagemath.org/sage_trac/ticket/9297 http://trac.sagemath.org/sage_trac/ticket/9299 Note, Solaris supports both a 32 and 64-bit ABI. Not sure if that is relevant, but I see ABI in the title, so perhaps it might be. Dave -- nosy: +drkirkby ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8265 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment:
Hi Mark,
Here's the info on the two systems - first the SPARC system, secondly the Intel
Xeon system.
1) SPARC
* Sun Blade 2000, with 2 x UltraSPARC III+ 1200 MHZ processors
* 8 GB RAM
* Solaris 10 update 8 10/09 release (This is the latest release of Solaris 10).
drkir...@swan:~$ cat /etc/release
Solaris 10 10/09 s10s_u8wos_08a SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 16 September 2009
drkir...@swan:~$ uname -a
SunOS swan 5.10 Generic_141444-09 sun4u sparc SUNW,Sun-Blade-1000
Python 2.6.4 (r264:75706, Jun 24 2010, 10:39:29)
[GCC 4.4.4] on sunos5
Type help, copyright, credits or license for more information.
float.hex(-0.0)
'0x0.0p+0'
float.fromhex('-0x0.0p+0')
-0.0
When configure runs, I see:
checking for copysign... yes
In pyconfig.h I have:
/* Define to 1 if you have the `copysign' function. */
#define HAVE_COPYSIGN 1
==
==
2) Intel Xeon system.
* Sun Ultra 27, quad core 3.33 GHz Intel Xeon processor
* 12 GB RAM
* OpenSolaris 06/2009, updated to build 134
* 64-bit installation.
* Note, this is the native operating system on this machine, so VirtualBox is
not used.
drkir...@hawk:~$ cat /etc/release
OpenSolaris Development snv_134 X86
Copyright 2010 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 01 March 2010
drkir...@hawk:~$ uname -a
SunOS hawk 5.11 snv_134 i86pc i386 i86pc
Python 2.6.4 (r264:75706, Jun 24 2010, 17:38:56)
[GCC 4.4.4] on sunos5
Type help, copyright, credits or license for more information.
float.hex(-0.0)
'0x0.0p+0'
float.fromhex('-0x0.0p+0')
-0.0
When configure runs, I see:
checking for copysign... yes
In pyconfig.h I have:
/* Define to 1 if you have the `copysign' function. */
#define HAVE_COPYSIGN 1
If you feel access to the SPARC system could help you debug this (or any of the
other test failures I get), I can get you access to a machine 16-core Sun T5240
which was donated by Sun.
I can't provide such easy access to the Xeon system, though you can install
OpenSolaris as a Virtual machine in VirtualBox quite easily - its a free
download.
Dave
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Just to clarify something, in case you notice something does not look quite right. The link I provided to the build failure on the SPARC machine http://trac.sagemath.org/sage_trac/ticket/9297 was a Sun Blade 1000. It is *not* the same machine from which I just copied the output, which was a Sun Blade 2000. The two machines are pretty similar though - the motherboards, processors, disks, RAM are interchangeable. In fact,'uname' shows Sun-Blade-1000 in both of them. I think the only real difference between them is that the Blade 2000 looks a bit nicer, and is officially supported with faster CPUs. The link I provided to the failure on the Xeon machine http://trac.sagemath.org/sage_trac/ticket/9299 is the same machine where I just posted the output. If you need an account on a SPARC, it will be a more modern Sun T5240 with 32 GB RAM. Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: I'll take a look at this in an hour or two. I'll restrict the testing to the Xeon machine, as it is a zillion times quicker than the old SPARCs. What comes to my mind, is that perhaps 'copysign' is only defined in C99. Solaris header files are pretty strict about what gets defined and not defined depending on the mode of compilation. The compiler option -std=c99 is not being passed yet the man page for copysign on my OpenSolaris laptop (yet another system) says: drkir...@laptop:~$ man copysign Mathematical Library Functions copysign(3M) NAME copysign, copysignf, copysignl - number manipulation func- tion SYNOPSIS c99 [ flag... ] file... -lm [ library... ] #include math.h double copysign(double x, double y); float copysignf(float x, float y); long double copysignl(long double x, long double y); DESCRIPTION These functions produce a value with the magnitude of x and the sign of y. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Using the compiler option -std=c99 allows this test to pass. Perhaps adding the macro AC_PROG_CC_C99 to autoconf to add the right compiler option might be a solution. I know Solaris headers are often quite strict, and will not define something in a header file if the right things are not defined to indicate C99. I would add, there is quite a serious problem on Solaris with _socket failing to build. http://bugs.python.org/issue8852 Unless one uses that workaround, which is not committed to the python source code yet, one can not run any tests of python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment:
Hi Mark,
Since 'copysign' is in the maths library, I would not expect the link phase to
fail. Solaris does not ship with different maths libraries for C99 (one just
links to libm).
However, I would not be surprised if the behavior was ill defined if the
compiler is not C99. Certainly header files behave differently on Solaris
depending on the mode of the compiler. For example, trying to use the INFINITY
macro when the compiler is not C99 seems to work on Linux, but fails on Solaris
unless you force C99 mode with gcc -std=c99.
The following bit of code gives the same results whether one uses 'gcc' or 'gcc
-std=c99' on OpenSolaris or Linux. However, if one uses 'gcc -ansi' then the
behavior is totally different.
drkir...@hawk:~$ cat cs.c
#include stdio.h
#include math.h
int main(int argc, char **argv) {
double x, y;
/* Set x and y differently if a command line arguement is given.
This will avoid the compiler optimising the values out, as they
will not be known in advance. */
if (argc==1) { /* This will stop compiler optimising 0.0 out x */
x=1.0;
y=0.0;
} else {
x=2.0;
y=-0.0;
}
printf(copysign(%lf,%lf)=%lf\n, x, y, copysign(x, y));
}
drkir...@hawk:~$ gcc -lm cs.c
drkir...@hawk:~$ ./a.out
copysign(1.00,0.00)=1.00
drkir...@hawk:~$ ./a.out z
copysign(2.00,-0.00)=-2.00
drkir...@hawk:~$ gcc -lm -std=c99 cs.c
drkir...@hawk:~$ ./a.out
copysign(1.00,0.00)=1.00
drkir...@hawk:~$ ./a.out z
copysign(2.00,-0.00)=-2.00
Note how -ansi screws it up completely
drkir...@hawk:~$ gcc -lm -ansi cs.c
drkir...@hawk:~$ ./a.out
copysign(1.00,0.00)=0.00
drkir...@hawk:~$ ./a.out z
copysign(2.00,-0.00)=0.00
I also tried it on a Sun SPARC running a recent version of Solaris (2009
release). Again the results are the same.
I then tried it on a Solaris box running the first release of Solaris 10
(03/2005). Then one gets even stranger behavior if one defines -ansi, where the
results are almost right, but with poor rounding errors.
drkir...@redstart:~$ gcc -ansi -lm cs.c
drkir...@redstart:~$ ./a.out
copysign(1.00,0.00)=1.01
drkir...@redstart:~$ ./a.out d
copysign(2.00,-0.00)=-2.02
But in C99 mode, it works fine.
drkir...@redstart:~$ gcc -std=c99 -lm cs.c
drkir...@redstart:~$ ./a.out
copysign(1.00,0.00)=1.00
drkir...@redstart:~$ ./a.out d
copysign(2.00,-0.00)=-2.00
So I draw two conclusions.
1) 'copysign' is in the maths library, so a program which tries to link to
'copysign' will succeed.
2) The behavior of 'copysign' is ill defined unless the compiler is a C99
compiler.
I don't think you should use copysign unless the compiler is C99. Trying to
come up with a test for 'copysign' working is probably an impossible task, as
it undefined. So you could try 99 different values of x and y and they all
work, but its anyone guess what will happen with the 100th set of values.
Dave
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Just to clarify the hostnames and hardware used, in case you look at the results here or the links to the Sage maths bug tracker and are not sure what is what. Note some are Solaris and some are OpenSolaris. Some have SPARC and some have Intel processors. All machines are 64-bit, but note that by default executables are created 32-bit on Solaris and OpenSolaris. * hawk = Sun Ultra 27, 3.33 GHz quad core Xeon, OpenSolaris 06/2009, but updated to the latest build of OpenSolaris. * laptop = Sony laptop, 2.0 GHz Intel CPU core2 duo, OpenSolaris 06/2009. * swan = Sun Blade 2000, 2 x 1200 MHz SPARC processors, Solaris 10 10/2009 release (Latest release of Solaris 10 at the time I'm writing this) * redstart = Sun Blade 1000, 2 x 900 MHz SPARC processors, Solaris 10 03/2005 (First Solaris 10 release) Although I've not shows the results from them, if I do show any others, likely candidates will be * sage = x86 Linux box (Ubunta I think) 24 cores. * t2 = Sun T5240, T2+ SPARC processors, 16 cores 1167 MHz, Solaris 10 05/2009 (A recent, but not the very latest release of Solaris 10) * bsd = OS X box of some sort. * hpbox = HP C3600 running HP-UX 11.11B, PA-RISC processors. * chaffinch = Virtual machine running Solaris 10 10/2009. (Runs as a guest operating system in VirtualBox) Sometimes having access to different hardware can be useful, but it can get confusing if someone sees a lot of different host names! Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment: Hi Martin, I appreciate your point. But do you know if anyone has it on their TODO list? If not, is there anything I could do about it? I don't have commit access to the Python source code, but if there is anything else I can do I'd like to. This is a pretty serious bug, as it stops one running the self-tests. Although Python builds and 99% of it works with this bug, an attempt to run the self-tests exits fairly quickly, with no tests performed. So despite there being over 300 tests, note one of them gets run unless one works around this bug. Hence the implication is a lot more than the fact that one can't use _socket. Dave drkir...@hawk:~/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src$ make test running build running build_ext building '_socket' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.o /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c: In function 'makesockaddr': /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1103: error: 'struct ifreq' has no member named 'ifr_ifindex' /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1104: error: 'SIOCGIFNAME' undeclared (first use in this function) /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1104: error: (Each undeclared identifier is reported only once /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1104: error: for each function it appears in.) /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c: In function 'getsockaddrarg': /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1411: error: 'SIOCGIFINDEX' undeclared (first use in this function) /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:1423: error: 'struct ifreq' has no member named 'ifr_ifindex' /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c: In function 'init_socket': /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:4589: error: 'PACKET_LOOPBACK' undeclared (first use in this function) /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/socketmodule.c:4590: error: 'PACKET_FASTROUTE' undeclared (first use in this function) building '_ssl' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_ssl.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_ssl.o gcc -shared build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.solaris-2.11-i86pc-2.6/_ssl.so *** WARNING: renaming _ssl since importing it failed: No module named _socket building '_curses' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/./Include -I. -IInclude -I./Include -I/usr/local/include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Include -I/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src -c /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.c -o build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.o /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.c: In function 'PyCursesWindow_ChgAt': /export/home/drkirkby/parallel/sage-4.4.4/spkg/standard/python-2.6.6/src/Modules/_cursesmodule.c:708: warning: implicit declaration of function 'mvwchgat' /export/home/drkirkby
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment: Has anyone done anything about fixing this issue? The patch I attached appears to allow _socket to build on OpenSolaris and when I run the test suite, there is no failure of _socket. I've just downloaded the latest source code for the 3.1.2, 2.6.5 and Python-2.7rc2. All three have this problems, so it needs fixing. As far as I can ascertain, the patch socketmodule.c.patch solves it. Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment: Is there anything I can do to get someone to do something about it? I would have thought with a patch, it would not be hard for someone to fix. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
Changes by David Kirkby david.kir...@onetel.net: Removed file: http://bugs.python.org/file17497/socketmodule.c.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment: I'd made a mistake when manually applying your patch, although my mistake made no practical difference. I'm attaching a corrected patch, which has all the changes needed to get this to build on OpenSolaris. It basically only checks for things before trying to compile with them, so it should be safe (and desirable) on any platform. I've not checked this on OpenSolaris on the SPARC hardware, though the use of OpenSolaris on SPARC hardware is very rare I believe. I' 99% sure that _socket builds ok on Solaris 10 on SPARC without any changes from the 2.6.4 source (I've not tried with 2.6.5) Dave -- Added file: http://bugs.python.org/file17498/socketmodule.c.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
New submission from David Kirkby david.kir...@onetel.net:
Using Python 2.6.5, the module _socket is failing to build on OpenSolaris. The
problem can be worked around with a hack, but I've not verified if the hack
actually results in working code - but at least it compiles. See below.
The problem seems to be that HAVE_NETPACKET_PACKET_H gets defined, despite the
fact there is no file called netpacket.h
running build
running build_ext
building '_socket' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/export/home/drkirkby/Python-2.6.5/Include
-I/export/home/drkirkby/Python-2.6.5 -c
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c -o
build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.o
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c: In function
‘makesockaddr’:
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1107: error: ‘struct
ifreq’ has no member named ‘ifr_ifindex’
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1108: error:
‘SIOCGIFNAME’ undeclared (first use in this function)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1108: error: (Each
undeclared identifier is reported only once
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1108: error: for each
function it appears in.)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c: In function
‘getsockaddrarg’:
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1415: error:
‘SIOCGIFINDEX’ undeclared (first use in this function)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:1427: error: ‘struct
ifreq’ has no member named ‘ifr_ifindex’
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c: In function
‘init_socket’:
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4596: error:
‘PACKET_LOOPBACK’ undeclared (first use in this function)
/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4597: error:
‘PACKET_FASTROUTE’ undeclared (first use in this function)
building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/export/home/drkirkby/Python-2.6.5/Include
-I/export/home/drkirkby/Python-2.6.5 -c
/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c -o
build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.o
/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c: In function
‘PyCursesWindow_ChgAt’:
/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c:708: warning:
implicit declaration of function ‘mvwchgat’
/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.c:712: warning:
implicit declaration of function ‘wchgat’
gcc -shared
build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_cursesmodule.o
-L/usr/local/lib -lcurses -ltermcap -o
build/lib.solaris-2.11-i86pc-2.6/_curses.so
*** WARNING: renaming _curses since importing it failed: ld.so.1: python:
fatal: relocation error: file build/lib.solaris-2.11-i86pc-2.6/_curses.so:
symbol mvwchgat: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I.
-IInclude -I./Include -I/usr/local/include
-I/export/home/drkirkby/Python-2.6.5/Include
-I/export/home/drkirkby/Python-2.6.5 -c
/export/home/drkirkby/Python-2.6.5/Modules/_curses_panel.c -o
build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_curses_panel.o
gcc -shared
build/temp.solaris-2.11-i86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/_curses_panel.o
-L/usr/local/lib -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.11-i86pc-2.6/_curses_panel.so
*** WARNING: renaming _curses_panel since importing it failed: No module
named _curses
building 'sunaudiodev' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I.
-IInclude -I.
A patch (which is a hack, rather than a real solution), is below.
drkir...@hawk:~/Python-2.6.5/Modules$ diff -U 10 socketmodule.c.orig
socketmodule.c
--- socketmodule.c.orig Sat May 29 14:58:17 2010
+++ socketmodule.c Sat May 29 15:26:08 2010
@@ -1089,20 +1089,21 @@
}
#endif
default:
PyErr_SetString(PyExc_ValueError,
Unknown Bluetooth protocol);
return NULL;
}
#endif
+#undef HAVE_NETPACKET_PACKET_H /* Hack to build on OpenSolaris x64 */
#ifdef HAVE_NETPACKET_PACKET_H
case AF_PACKET:
{
struct sockaddr_ll *a = (struct sockaddr_ll *)addr;
char
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment: I was obviously looking for the wrong file. ./pyconfig.h shows: /* Define to 1 if you have the netpacket/packet.h header file. */ #define HAVE_NETPACKET_PACKET_H 1 the file does indeed exist drkir...@hawk:~$ find /usr/include -name packet.h /usr/include/netpacket/packet.h -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment: Two points I should have stated. 1) http://www.lotuseyes.de/blog/error-installing-plone-on-opensolaris-using-the-unified-installer has a discussion about this issue. It was related to someone trying to install Plone but the problem is a failure of _socket to build. I'm trying to build the port the Sage maths software to OpenSolaris, and hit the problem there. 2) If a *serious* developer would like access to the OpenSolaris machine which shows this problem, I can give you a temporary account. Drop me a private email. Otherwise, you can install OpenSolaris on a virtual machine under VirtualBox, or I can do my best to debug it with some help from a developer. Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment: Hi, thank you for the patch. I hope you can keep Python building the same modules on Solaris as Linux, as that would be a real shame if it did not. This module is used in the Sage maths software. I had some difficulty applying your patch using the 'patch' command. 'patch' just kept rejecting the file. Finally I gave up and patched it manually. It did not completely solve the problem as PACKET_FASTROUTE and PACKET_LOOPBACK were undeclared too building '_socket' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/export/home/drkirkby/Python-2.6.5/./Include -I. -IInclude -I./Include -I/usr/local/incl ude -I/export/home/drkirkby/Python-2.6.5/Include -I/export/home/drkirkby/Python-2.6.5 -c /export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c -o build/temp.solaris-2.11-i 86pc-2.6/export/home/drkirkby/Python-2.6.5/Modules/socketmodule.o /export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c: In function ‘init_socket’: /export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4597: error: ‘PACKET_LOOPBACK’ undeclared (first use in this function) /export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4597: error: (Each undeclared identifier is reported only once /export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4597: error: for each function it appears in.) /export/home/drkirkby/Python-2.6.5/Modules/socketmodule.c:4598: error: ‘PACKET_FASTROUTE’ undeclared (first use in this function) building '_ssl' extension However, I decided to alter the Modules/socketmodule.c further and finally _socket built. I don't however know how to test _socket, so I don't know if it working or not. (I'm not a python programmer - just about to start learning it). But using drkir...@hawk:~/Python-2.6.5$ ./python Python 2.6.5 (r265:79063, May 29 2010, 21:17:44) [GCC 4.4.4] on sunos5 Type help, copyright, credits or license for more information. import _socket it would appear its not completely broken. BTW, for the record, the hardware is a Sun Ultra 27 (quad core Xeon) running OpenSolaris 06/2009 which has been updated to build 134. drkir...@hawk:~$ cat /etc/release OpenSolaris Development snv_134 X86 Copyright 2010 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 01 March 2010 I've built Sage on Solaris 10 (on SPARC hardware), so I don't think this patch is needed on Solaris 10, though I've not checked on Solaris 10 using Intel/AMD hardware. Dave -- Added file: http://bugs.python.org/file17497/socketmodule.c.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8852] _socket fails to build on OpenSolaris x64
David Kirkby david.kir...@onetel.net added the comment: I forget to say I had attached the patch 'socketmodule.c.patch' which allows _socket to build. (I know you can see that if you look, but I thought it useful to write it). I do have some other modules not building on OpenSolaris (_curses, _curses_panel, _tkinter sunaudiodev) but I'll create separate tickets for those. All of those 4 modules are included in the Python 2.6.4 shipped as part of OpenSolaris, so they can be built. Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7836] Add /usr/sfw/lib to OpenSSL search path for Solaris.
New submission from David Kirkby david.kir...@onetel.net: In the top level setup.py there is a list of directories searched for the OpenSSL libraries. ssl_libs = find_library_file(self.compiler, 'ssl',lib_dirs, ['/usr/local/ssl/lib', '/usr/contrib/ssl/lib/' ] ) # Detect SSL support for the socket module (via _ssl) search_for_ssl_incs_in = [ '/usr/local/ssl/include', '/usr/contrib/ssl/include/' On Solaris 10, (but not Open Solaris), OpenSSL comes as part of the operating system, but the libraries reside in /usr/sfw/lib. drkir...@kestrel:~$ ls /usr/sfw/lib/libssl* /usr/sfw/lib/libssl.so/usr/sfw/lib/libssl.so.0.9.7 Could you simply add /usr/sfw/lib to the library search path, so they are found on Solaris 10? The include files reside in /usr/sfw/include/openssl on Solaris 10. -- components: Build messages: 98725 nosy: drkirkby severity: normal status: open title: Add /usr/sfw/lib to OpenSSL search path for Solaris. type: feature request versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7836 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
