Building python 2.4.2 on linux with static pthreads
I can build python 2.4.2 from source on the embedded linux box when I nfs mount and boot a full debian distribution. The embedded box also has stripped down linux distribution in onboard flash. My goal is to run python from the stripped down linux in onboard flash. I can successfully install python to the onboard flash when booted to the nfs version by using make install with $DESTDIR set to the onboard flash mounted directory I then reboot to the onboard flash and can run python from there. This works if I build python without threading support because the onboard flash does not include the libpthread.so library I need threading support for sockets etc. I believe that if I can build python with pthread linked statically then I should be able to run python when booted from the onboard flash without problem. Problem is I am clueless about how to do this. The setup and setup.py files only deal with building modules static or shared where as threading is build into the python interpreter it seems not as a module. I read the readme in the source distribution but can't find any configure options that will let me build python with static linking of the pthread library. I have searched google and find vague references to doing something like that. I don't understand the makefile well enough to know how to do it there. So does anyone understand how include threading support statically? What I have to modify to do it? When I tried to run python with shared threading support while booted from the onboard flash it got the following error ./python: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory I naively copied the pthread library from the nfs version to the onboard flash version and rebooted and ran python. This time I got the following error /usr/local/bin/python: relocation error: /lib/libpthread.so.0: symbol __libc_sigaction, ve rsion GLIBC_2.2 not defined in file libc.so.6 with link time reference so apparently I can't just copy shared libraries around. An alternative solution would be to correctly copy the shared library? Any help comments would be appreciated Sam ****** Samuel M. Smith Ph.D. 2966 Fort Hill Road Eagle Mountain, Utah 84043 801-768-2768 voice 801-768-2769 fax ** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ** -- http://mail.python.org/mailman/listinfo/python-list
Configure failing why?
I am trying to build python2.4.2 on an arm 9 running Debian 3 Sarge when I run ./configure it fails with ./configure checking MACHDEP... linux2 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no checking for c++... c++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... configure: error: cannot run C++ compiled pro grams. If you meant to cross compile, use `--host'. See `config.log' for more details. Inside config.log I find checking for C++ compiler default output file name configure:1782: c++conftest.cc >&5 configure:1785: $? = 0 configure:1831: result: a.out configure:1836: checking whether the C++ compiler works configure:1842: ./a.out ./configure: line 1: ./a.out: Permission denied configure:1845: $? = 126 configure:1854: error: cannot run C++ compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. It appears that for some reason the a.out file that the configure script is making is not getting execute permissions enable by the configure script I have build python 2.4.2 successfully on Debian 2 and never had this problem Any ideas why this is happening? ********** Samuel M. Smith Ph.D. 2966 Fort Hill Road Eagle Mountain, Utah 84043 801-768-2768 voice 801-768-2769 fax ** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ** -- http://mail.python.org/mailman/listinfo/python-list
Re: Configure failing why?
cat > foo.cpp
int main(){return 0;}
c++ foo.cpp
ll a.out
-rwxr-xr-x 1 root tsarm 12124 Nov 15 15:54 a.out
./a.out
but if I
gcc foo.cpp
ll a.out
-rw-r--r-- 1 root tsarm 12060 Nov 15 15:55 a.out
but if I do it again
# gcc foo.cpp
ll a.out
-rwxr-xr-x 1 root tsarm 12060 Nov 15 15:58 a.out
On 15 Nov, 2005, at 15:40, Fredrik Lundh wrote:
> Samuel M. Smith wrote:
>
>> I am trying to build python2.4.2 on an arm 9 running Debian 3 Sarge
>
>> configure:1842: ./a.out
>> ./configure: line 1: ./a.out: Permission denied
>> configure:1845: $? = 126
>> configure:1854: error: cannot run C++ compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details.
>>
>> It appears that for some reason the a.out file that the configure
>> script is making is not getting execute permissions enable by the
>> configure script
>
> on a sane standard Unixoid system, the compiler is required to set the
> following permission flags
>
> S_IRWXO | S_IRWXG | S_IRWXU
>
> if and only if the program was successfully compiled and linked.
>
> what happens if you do
>
> $ cat >foo.cpp
> int main(){ return 0; }
> $ c++ foo.cpp
> $ ls -l a.out
>
> ?
>
>
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
**
Samuel M. Smith Ph.D.
2966 Fort Hill Road
Eagle Mountain, Utah 84043
801-768-2768 voice
801-768-2769 fax
**
"The greatest source of failure and unhappiness in the world is
giving up what we want most for what we want at the moment"
**
--
http://mail.python.org/mailman/listinfo/python-list
Re: Configure failing why?
Thanks for your help.
Your confirmation that gcc should be setting the execute permissions
gave me something easy
to test against.
I finally discovered the problem. It was nfs. The file system was
nfs mounted and nfs is causing
the aberrant behavior. If I did the test on the onboard flash file
system it worked. I finally used a different
nfs server and the problem went away.
I was serving nfs from a Mac OS X 10.4.3 machine. The problem did not
occur on OS X 10.4.2 not does it occur
when serving nfs from OS X 10.3.9
It something new introduced in 10.4.3. I don't have a fix for it.
Anyone have a suggestion it would help.
On 15 Nov, 2005, at 15:40, Fredrik Lundh wrote:
> Samuel M. Smith wrote:
>
>> I am trying to build python2.4.2 on an arm 9 running Debian 3 Sarge
>
>> configure:1842: ./a.out
>> ./configure: line 1: ./a.out: Permission denied
>> configure:1845: $? = 126
>> configure:1854: error: cannot run C++ compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details.
>>
>> It appears that for some reason the a.out file that the configure
>> script is making is not getting execute permissions enable by the
>> configure script
>
> on a sane standard Unixoid system, the compiler is required to set the
> following permission flags
>
> S_IRWXO | S_IRWXG | S_IRWXU
>
> if and only if the program was successfully compiled and linked.
>
> what happens if you do
>
> $ cat >foo.cpp
> int main(){ return 0; }
> $ c++ foo.cpp
> $ ls -l a.out
>
> ?
>
>
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
**
Samuel M. Smith Ph.D.
2966 Fort Hill Road
Eagle Mountain, Utah 84043
801-768-2768 voice
801-768-2769 fax
**
"The greatest source of failure and unhappiness in the world is
giving up what we want most for what we want at the moment"
**
--
http://mail.python.org/mailman/listinfo/python-list
Re: Configure failing why?
I found a workaround,that is, to disable attribute caching using the "noac" nfs option. #These two worked on tiger 10.4.3 exec -c "console=ttyAM0,115200 ip=10.0.2.155:10.0.2.150:10.0.2.1:255.255.255.0:ts7250 nfsroot=10.0.2.150:/Data/nfsroot,noac" #fstab entry they have to match 10.0.2.150:/Data/nfsroot/ / nfs noac,noauto 0 0 #If use noac,sync,dirsync then gcc does not work -- http://mail.python.org/mailman/listinfo/python-list
Unexpected behavior of read only attributes and super
I have been playing around with a subclass of dict wrt a recipe for
setting dict items using attribute syntax.
The dict class has some read only attributes that generate an
exception if I try to assign a value to them.
I wanted to trap for this exception in a subclass using super but it
doesn't happen.
I have read Guido's tutorial on new style classes and Shalabh's
tuturial on new style attributes and methods, and thought
I understood what super was doing. But there is no discussion on read
only attributes and their associated magic.
It seems to me that there is some undocumented magic that does not
make sense to me.
for example
d = dict()
d.__iter__ returns
If I try to assign a value to d.__iter__
d.__iter__ = False
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: 'dict' object attribute '__iter__' is read-only
If I use the setattr method, I get the exception also as expected
d.__setattr__('__iter__', False)
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: 'dict' object attribute '__iter__' is read-only
but if I subclass and use super
class SD(dict):
pass
s = SD()
s.__iter__ returns
so the object s has this attribute
hasattr(s,'__iter__') also returns
True
but s.__dict__ is empty at this stage so s has inherited this
attribute as a method
so far so good.
If I assign a value
s.__iter__ = False
it lets me but adds the attribute to s.__dict__ thereby shadowing the
method, no surprises yet
s.__dict__ returns
{'__iter__': False}
but I want to know if the attribute is a read only attribute of the
super class so that I don't shadow it
in the subclass. So I start over and try
s = SD()
super(SD,s).__setattr__('__iter__', True)
Expecting to get the ReadOnly exception but I don't get the exception.
Instead the attribute is added to s.__dict__.
s.__dict__ returns
{'__iter__': True}
Shouldn't the super __setattr__ call be using the same code as the
direct call to dict's __setattr__
and therefore produce an exception?
--
http://mail.python.org/mailman/listinfo/python-list
Test Post Ignore
My posts don't seem to be showing up. This is a test. Sorry -- http://mail.python.org/mailman/listinfo/python-list
Re: Unexpected behavior of read only attributes and super
On 06 Dec, 2005, at 20:53, Steven Bethard wrote:
> Samuel M. Smith wrote:
>> The dict class has some read only attributes that generate an
>> exception
>> if I try to assign a value to them.
>> I wanted to trap for this exception in a subclass using super but it
>> doesn't happen.
>>
>> class SD(dict):
>>pass
>>
> [snip]
>> s = SD()
>> super(SD,s).__setattr__('__iter__', True)
>>
>> Expecting to get the ReadOnly exception but I don't get the
>> exception.
>
> Note that __iter__ is on the dict *type* not dict instances. Try
> this:
>
> py> class SD(dict):
> ... pass
> ...
> py> super(SD, SD).__init__ = False
> Traceback (most recent call last):
>File "", line 1, in ?
> AttributeError: 'super' object attribute '__init__' is read-only
>
> You can always shadow class-level attributes in the instance dict.
> (That's what you were doing.) If you want to (try to) replace an
> attribute in the class dict, you need to use the class object, not an
> instance object.
>
I guess that's where my understanding breaks down. I thought the only
way to access class attributes was by
calling the class directly as your example indicates but __iter__ is
a class attribute that I can access from the instance
at least to read it. So what determines which class attributes get
copied to the instance and which ones don't?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Unexpected behavior of read only attributes and super
>
>
> P.S. Note that there is an additional complication resulting from the
> fact that functions are descriptors:
>
class C(dict):
> ... pass
> ...
C.__iter__
>
C().__iter__
>
>
> Even though the C instance is accessing the __iter__ function on the
> class, it gets back a different value because descriptors return
> different values depending on whether they are accessed from a
> class or
> an instance. I don't think you need to understand this to solve your
> problem though, so I won't go into any more details unless you
> think it
> would be helpful.
I found your explanation very helpful. After reading it I went back
and read
my Nutshell book and realized that the explanation was in there but I
didn't "get" it until now.
Although I did find an exception to the rule for attribute writes.
(See !Whoops below)
If you would care to elaborate on the how the lookup differs with
method descriptor
it would be most appreciated. Mostly because it seems that having
slots defined
changes the method lookup as opposed to the variable lookup and
apparently some of the type class
variables are special enough that they have their own rules.
This might help explain why it is that when I define __slots__, the
behavior when writing an attribute is different for
attributes that exist in the class versus attributes that exist in
__slots__ versus attributes that
do not exist at all. It is also different if the class attribute is a
method vesus a variable.
For example
>>> class C(dict):
... __slots__ = ['a','b']
...
>>> c = C()
>>> c.a
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: a
So slot defined but not assigned gets error
>>> c.a = 5
>>> c.a
5
OK here
>>> c.c
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: 'C' object has no attribute 'c'
Surprise error gives no clue that slots is the reason for the error
>>> c.c = 4
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: 'C' object has no attribute 'c'
ditto
Now the behavior is different for class variables and methods when
slots defined
versus when slots is not defined.
>>> c.__iter__ = 4
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: 'C' object attribute '__iter__' is read-only
>>> super(C,c).__iter__ = 4
Traceback (most recent call last):
File "", line 1, in ?
TypeError: 'super' object has only read-only attributes (assign
to .__iter__)
>>>
>>> c.__class__ = C
>>> c.__class__
it let me assign it! But not shadowed
>>> c.__dict__
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: 'C' object has no attribute '__dict__'
!Whoops now I am confused again. Didn't you say
> When "writing" an attribute (i.e. using the assignment statement),
> Python does not try to do any namespace searching. Thus if you use
> the
> instance in an assignment statement, then it is the instance's
> attributes that get modified, and if you use the class in an
> assignment
> statement, then it is the class's attributes that get modififed:
Then why wasn't __class__ added to c.__dict__ ? Looks like namespace
searching to me.
So to cross check if slots is not defined
>>> class C(dict):
... pass
...
>>> c = C()
>>> c.__iter__ = 1
>>> c.__dict__
{'__iter__': 1}
>>> c.__class__ = C
>>> c.__dict__
{'__iter__': 1}
>>>
try again a different way
class B(C):
... pass
...
>>> c.__class__ = B
>>> c.__dict__
{'__iter__': 4}
OK but maybe __class__ is magic, so I tried again
>>> class C(dict):
... a = 0
...
>>> c = C()
>>> c.a
0
>>> c.a = 4
>>> c.__dict__
{'a': 4}
OK __class__ is special
now with slots defined
>>> class C(dict):
... __slots__ = ['b']
... a = 0
...
>>> c = C()
>>> c.a
0
>>> c.a = 4
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: 'C' object attribute 'a' is read-only
>>>
>>> C.a = 5
>>> c.a
5
>>>
So the rule is that when __slots__ is defined class variables become
read only.
What if the class variable is included in __slots__
>>> class C(dict):
... __slots__ = ['b']
... b = 1
...
>>> c = C()
>>> c.b
1
>>> c.b = 2
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: 'C' object attribute 'b' is read-only
So even though b is in slots I still can't create an instance
variable by that name
and shadow the class variable.
It feels like the implementation of slots is half baked.
Finally
Since the "way" of python is that if an object does not have an
attribute
but you can assign it one then it creates one dynamically (in the
same 'way' that if a variable does not
exist is creates one upon assignment).
Because slots break this paradigm then at the very least the error
messages should point out that this object
is using slots "so beware".
For example I would prefer something like the following
c.a
AttributeError: Slot 'a' not yet assigned
c.c
AttributeErr
Re: Unexpected behavior of read only attributes and super
> >> Then why wasn't __class__ added to c.__dict__ ? Looks like namespace >> searching to me. > > No, as you conclude later, __class__ is special, so you can still > assign > to __class__ even when __slots__ is defined because it's not > considered > a normal attribute. But note that __class__ is an *instance* > attribute, > not a class attribute, so "c.__class__ = C" changes the class of that > single instance, and makes no change to the type: > > So no, even with __class__, you're only assigning to the instance, and > so Python's not searching any additional namespaces. Thank you so much, very helpful comments. I hope it helps others as well. At the very least I now understand a little better about some of the special rules for special attributes. -- http://mail.python.org/mailman/listinfo/python-list
Re: building Python 2.4.2 on Mac OS X
On os x 10.4.3 to build a framework version unpack source dist python-2.4.2 ./configure --enable-framework make sudo makeframework install Please note that "sudo make install" won't work On 08 Jan, 2006, at 16:20, Vidar Gundersen wrote: > are there any easy to understand instructions > for building Python on Mac OS X Tiger? > are there any prerequisites that i have missed? > my ./configure && make stops here: > > Python/mactoolboxglue.c:462: warning: return makes integer from > pointer without a cast > make: *** [Python/mactoolboxglue.o] Error 1 > > -- > http://mail.python.org/mailman/listinfo/python-list ********** Samuel M. Smith Ph.D. 2966 Fort Hill Road Eagle Mountain, Utah 84043 801-768-2768 voice 801-768-2769 fax ** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ** -- http://mail.python.org/mailman/listinfo/python-list
ctypes on arm linux
/usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3398: error: syntax error before '*' token /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3399: warning: function declaration isn't a prototype /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: In function `CFuncPtr_traverse': /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3400: error: `self' undeclared (first use in this function) /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3400: warning: implicit declaration of function `visit' /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3400: error: `arg' undeclared (first use in this function) /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3407: error: `visit' undeclared (first use in this function) /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: At top level: /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3411: error: syntax error before '*' token /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3412: warning: function declaration isn't a prototype /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: In function `CFuncPtr_clear': /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3413: error: `self' undeclared (first use in this function) /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: At top level: /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3431: error: syntax error before '*' token /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3432: warning: function declaration isn't a prototype /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: In function `CFuncPtr_dealloc': /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3433: error: `self' undeclared (first use in this function) /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: At top level: /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3438: error: syntax error before '*' token /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3439: warning: function declaration isn't a prototype /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: In function `CFuncPtr_repr': /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3448: error: `self' undeclared (first use in this function) ** Samuel M. Smith Ph.D. 2966 Fort Hill Road Eagle Mountain, Utah 84005-4108 801-768-2768 voice 801-768-2769 fax ** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ** -- http://mail.python.org/mailman/listinfo/python-list
Help ctypes on arm linux not compile
/usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3398: error: syntax error before '*' token /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3399: warning: function declaration isn't a prototype /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: In function `CFuncPtr_traverse': /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3400: error: `self' undeclared (first use in this function) /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3400: warning: implicit declaration of function `visit' /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3400: error: `arg' undeclared (first use in this function) /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3407: error: `visit' undeclared (first use in this function) /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: At top level: /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3411: error: syntax error before '*' token /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3412: warning: function declaration isn't a prototype /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: In function `CFuncPtr_clear': /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3413: error: `self' undeclared (first use in this function) /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: At top level: /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3431: error: syntax error before '*' token /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3432: warning: function declaration isn't a prototype /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: In function `CFuncPtr_dealloc': /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3433: error: `self' undeclared (first use in this function) /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: At top level: /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3438: error: syntax error before '*' token /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3439: warning: function declaration isn't a prototype /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c: In function `CFuncPtr_repr': /usr/local/src/Python-2.5.1/Modules/_ctypes/_ctypes.c:3448: error: `self' undeclared (first use in this function) ** Samuel M. Smith Ph.D. 2966 Fort Hill Road Eagle Mountain, Utah 84005-4108 801-768-2768 voice 801-768-2769 fax ** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ** -- http://mail.python.org/mailman/listinfo/python-list
Re: Help ctypes on arm linux not compile
Sorry, thats a typo. Its python 2.5.1. as the error messages indicate. On 30 Oct 2007, at 02:55 , Thomas Heller wrote: > Samuel M. Smith schrieb: >> I have built python 1.5.1 from source for an embedded ARM9 debian >> linux Sarge distribution but >> ctypes doesn't build. Anybody have any idea what the problem is? Do >> I have to have the libffi package >> installed. >> See my errors below. > > ctypes won't work with Python 1.5 because it uses new style > classes, introduced in Python 2.2. > It uses other, newer features additionally, so it requires Python > 2.3 at least. > > Then, the included libffi package doesn't support ARM, you need a > newer libffi > version. > > I think that the current Python 2.5 sources, from SVN, should work. > > Thomas > > -- > http://mail.python.org/mailman/listinfo/python-list ** Samuel M. Smith Ph.D. 2966 Fort Hill Road Eagle Mountain, Utah 84005-4108 801-768-2768 voice 801-768-2769 fax ** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ** -- http://mail.python.org/mailman/listinfo/python-list
