Re: FTBFS: python
On Sun, Nov 02, 2003 at 03:43:00PM -0500, Neal H. Walfield wrote: > At Sun, 2 Nov 2003 19:53:31 +0100 (CET), > Santiago Vila wrote: > > > > And this is what happens when compiling python2.3: > > > > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC > > -fno-strict-aliasing -DWITH_APPINIT=1 -DWITH_BLT=1 > > -I/usr/include/tcl8.4 -I/usr/X11R6/include -I. > > -I/build/buildd/python2.3-2.3.2/./Include > > -I/build/buildd/python2.3-2.3.2/Include > > -I/build/buildd/python2.3-2.3.2/build-static -c > > /build/buildd/python2.3-2.3.2/Modules/_tkinter.c -o > > build/temp.gnu-0.3-i386-AT386-2.3/_tkinter.o gcc -shared > > build/temp.gnu-0.3-i386-AT386-2.3/_tkinter.o > > build/temp.gnu-0.3-i386-AT386-2.3/tkappinit.o -L/usr/X11R6/lib -lBLT > > -ltk8.4 -ltcl8.4 -lX11 -o > > build/lib.gnu-0.3-i386-AT386-2.3/_tkinter.so > > python: ../../libpthread/sysdeps/generic/pt-mutex-timedlock.c:55: > > __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' > > failed. > > It seems that the pthread init hook is not being run by libc during > start up. Try adding -lpthread and see if that makes a difference. That indeed helps. On the other hand, generally adding -lpthread to $LDFLAGS makes linking libpython fail. I've built _tkinter.so manually and assembled a hacked python2.3 package which I've uploaded to ftp.gnuab.org: http://ftp.gnuab.org/debian/pool/main/p/python2.3/python2.3_2.3.3-6.0.1.changes I've CC'ed the python maintainers, perhaps they have an idea how to handle this. Would be nice if people interested in python would test the packages, they seem to work fine for me but I did not have the time to install any other python packages/modules yet. A couple of tests failed (namely, 'cpickle', 'parser', 'poll', 're' and 'socket'. 'class' did fail, too, but changing recursion_limit in Python/ceval.c from 1000 to 930 made that pass on my machine at least) with segfaults, which I removed (test-suite failures are not fatal to the build, but the tests get byte-compiled during installation for whatever reason and the segfaults happen there, too). I had a look at a couple of them but when I was unable to figure out the third segfault in a couple of hours I stopped there and gave up :-/ As the tests get removed in the package building later on anyway, perhaps it can be avoided to byte-compile them at all? enjoy, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: FTBFS: python
Michael Banck writes:
> > It seems that the pthread init hook is not being run by libc during
> > start up. Try adding -lpthread and see if that makes a difference.
>
> That indeed helps. On the other hand, generally adding -lpthread to
> $LDFLAGS makes linking libpython fail. I've built _tkinter.so manually
> and assembled a hacked python2.3 package which I've uploaded to
> ftp.gnuab.org:
>
> http://ftp.gnuab.org/debian/pool/main/p/python2.3/python2.3_2.3.3-6.0.1.changes
In setup.y, add after "# Add the Tcl/Tk libraries"
if platform == '':
libs.append('pthread')
what does sys.platform print?
> I've CC'ed the python maintainers, perhaps they have an idea how to
> handle this. Would be nice if people interested in python would test the
> packages, they seem to work fine for me but I did not have the time to
> install any other python packages/modules yet.
>
> A couple of tests failed (namely, 'cpickle', 'parser', 'poll', 're' and
> 'socket'. 'class' did fail, too, but changing recursion_limit in
> Python/ceval.c from 1000 to 930 made that pass on my machine at least)
that could be hacked with an architecture specific patch. Is this new
for python2.3?
> with segfaults, which I removed (test-suite failures are not fatal to
> the build, but the tests get byte-compiled during installation for
> whatever reason and the segfaults happen there, too). I had a look at a
> couple of them but when I was unable to figure out the third segfault in
> a couple of hours I stopped there and gave up :-/
>
> As the tests get removed in the package building later on anyway,
> perhaps it can be avoided to byte-compile them at all?
byte-compiling at this time should be done for qa during package build
time. I'll skip this for the test directories in the next build.
Matthias
Re: FTBFS: python
On Sun, Apr 25, 2004 at 05:05:32PM +0200, Matthias Klose wrote:
> Michael Banck writes:
> > > It seems that the pthread init hook is not being run by libc during
> > > start up. Try adding -lpthread and see if that makes a difference.
> >
> > That indeed helps. On the other hand, generally adding -lpthread to
> > $LDFLAGS makes linking libpython fail. I've built _tkinter.so manually
> > and assembled a hacked python2.3 package which I've uploaded to
> > ftp.gnuab.org:
> >
> > http://ftp.gnuab.org/debian/pool/main/p/python2.3/python2.3_2.3.3-6.0.1.changes
>
> In setup.y, add after "# Add the Tcl/Tk libraries"
>
> if platform == '':
> libs.append('pthread')
Ah, great. I only looked at the Makefiles and forgot about setup.py.
I'll report back whether that works when I've got the time to test this
(probably later today).
> what does sys.platform print?
Ah, that's one thing I forgot to report. The platform string seems broken:
Python 2.3.3 (#2, Apr 24 2004, 24:05:06)
[GCC 3.3.3 (Debian 20040321)] on gnu0
[...]
>>> import sys
>>> sys.platform
'gnu0'
>>>
I't probably supposed to be 'gnu0.3', perhaps the dot confuses python?
Or is 'gnu0' really the right platform string?
Hmm, looking at 'linux2' on GNU/Linux, 'gnu0' does not look so far off
anymore :)
> > I've CC'ed the python maintainers, perhaps they have an idea how to
> > handle this. Would be nice if people interested in python would test the
> > packages, they seem to work fine for me but I did not have the time to
> > install any other python packages/modules yet.
> >
> > A couple of tests failed (namely, 'cpickle', 'parser', 'poll', 're' and
> > 'socket'. 'class' did fail, too, but changing recursion_limit in
> > Python/ceval.c from 1000 to 930 made that pass on my machine at least)
>
> that could be hacked with an architecture specific patch. Is this new
> for python2.3?
No idea. We did not have python2.3 (or any other python packages, for
that matter) in a looong time. 2.2.92-1exp1 is the version on
ftp.debian.org, I don't know whether the test suite was even run back
then, there's no test-suite output in /usr/share/doc/python2.3 at least.
So it could be nobody tried to run the test-suite before, dunno :-/
> > As the tests get removed in the package building later on anyway,
> > perhaps it can be avoided to byte-compile them at all?
>
> byte-compiling at this time should be done for qa during package build
> time. I'll skip this for the test directories in the next build.
Great, thanks. Alternatively, I could provide a patch to just remove
those tests after the check target and before installation on hurd-i386.
But then, these failures should be investigated anyway. I just don't
know whether I'll have the time in the near future.
Michael
--
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html
