Re: tmpfile64 broken in libc

[Robert Millan]

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