[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tmpfile64 broken in libc
From: |
Robert Millan |
Subject: |
Re: tmpfile64 broken in libc |
Date: |
Mon, 14 Apr 2003 00:53:59 +0200 |
User-agent: |
Mutt/1.5.3i |
On Sun, Apr 13, 2003 at 11:10:21PM +0200, Joachim Nilsson wrote:
>
> I've found a similar error when trying to build Python. However,
> this time it's tmpfile() that cannot be found. The error only
> occurrs when linking with --export-dynamic, when I build my own
> no-brainer C test case I don't have any problems linking in the
> tmpfile() function.
It's actualy tmpfile64. from Glibc docs:
When the sources are compiled with `_FILE_OFFSET_BITS == 64' on a
32-bit system this function is in fact `tmpfile64', i.e. the LFS
interface transparently replaces the old interface.
the problem is in libc, for some reason tmpfile64 is not present in
the shared object. but IIRC it *is* in the static object ar file.
btw, i wouldn't bother much with python2.2, 2.3 works on GNU and we
can expect a migration eventualy.
on the other hand, python2.2 has other nasty bugs. i hacked it to
compile and there's a patch+binary in my repository you can use.
look for python in http://people.debian.org/~rmh/apt/00README
and lastly, python2.2 reveals a bug in libpthread. when built with
threads enabled, it triggers a weird libpthread error. i have no
clue about it, i think it's a task for someone who knows libpthread
internals well. if anyone reproduces it, please post the error here
so the "wise minds that be" around have a look at it :)
p.s: btw it sucks to be reportbug crashing due to be using a ripped
python2.2 without pthreads ;)
--
Robert Millan
make: *** No rule to make target `war'. Stop.
Another world is possible - Just say no to genocide