[Python-Dev] build problems large and small on FreeBSD

[Thomas Wouters]

On Fri, Oct 13, 2000 at 07:05:02PM -0400, Jeremy Hylton wrote:

> The warnings from the linker seem harmless enough.  I don't know why
> it is complaining about setkey and des_setkey.  

That's probably due to 'crypt()' being used, or some other library call that
Python uses indirectly. If you want crypt(), you need to install a seperate
DES encryption package under FreeBSD, IIRC. (It uses md5-hashes for all
crypt purposes by default, because of the US Counter-Espionage Protection
Plan or something :) If you don't want to install those, don't enable the
crypt module. There are a couple of pure python crypt() implementations
around, by the way, which always use pure DES crypt().

> /usr/lib/libc.so: warning: this program uses gets(), which is unsafe.

This one is weirdish. I don't see any gets() call in Python, so I have to
assume it's in some library or header file Python includes. A good candidate
would be readline, which has appalled me before :) but who knows :P I'm
inclined to think it isn't a library that comes with FreeBSD by default,
since they are usually pretty picky about such things. (especially if it
generates a linker warning each time it's used!)

> /usr/lib/libc.so: warning: mktemp() possibly used unsafely; consider using mkstemp()
> /usr/lib/libc.so: warning: tmpnam() possibly used unsafely; consider using mkstemp()
> /usr/lib/libc.so: warning: tempnam() possibly used unsafely; consider using mkstemp()

Yes, I've seen this before. Debian-unstable (I think ?) complains about
tmpnam() and tempnam() as well. The manpages just say 'don't use
this function, use mkstemp(3)'. It doesn't mention a reason, but it's
probably because the files/directories created by these functions are
predictable, which means you shouldn't use them for security-by-obscurity.

The mktemp() warning doesn't come from Python, looks like. Probably another
library that is included. If you really care about which it is, you'll have
to comment them out one by one (I'd suggest starting with the oldest and
least FreeBSDish one, i.e. readline :) but I don't think it's going to
really matter. Python does use 'tempnam' and 'tmpnam', but only in the
posixmodule, to provide Python versions. I'm not sure if we can just change
these functions to use mkstemp (or tempfile, see below) internally, without
breaking code, though I expect it'll be alright. What's more, these
functions are new since 1.5.2. And also, I just noticed a bug/typo in the
tempnam docstring.

The one funny bit, though, is that these three functions point to mkstemp(),
and the mkstemp() manpage reads this:

       Don't use this  function,  use  tmpfile(3)  instead.  It's
       better defined and more portable.

"When does the hurting stop ?"

> /usr/lib/libc.so: warning: this program uses f_prealloc(), which is stupid.

And this falls in the 'it wasn't us' category again.

> The compiler-time warnings look like they are caused by a configure
> problem.  If so, I don't know how to fix it :-).

> gcc -O3 -I../../Python/../Include -I.. -DHAVE_CONFIG_H -c ../../Python/thread.c
> In file included from /usr/include/unistd.h:42,
>                  from ../../Python/thread.c:28:
> /usr/include/sys/unistd.h:71: warning: `_POSIX_THREADS' redefined
> ../config.h:136: warning: this is the location of the previous definition

Hm, yes. This looks like an unfortunate clash between a Python internal
#define and a FreeBSD libc internal #define. I'm not sure if this is really
the case, maybe the Python one serves exactly the same purpose as the
FreeBSD one, but in that case, configure shouldn't redefine it. We can
either rename the #define in Python, as it's only used to determine which
thread functionality is available, or adjust the configure tests to see if
it is #defined and not redefine it if so.

(Or rather, to be sure that it defines the right thing, configure would have
to test for posix threads, check the #define (if any), and if they don't
match up, scream its head off. So perhaps renaming is the smarter thing.) On
the other hand, the fact that you only got a warning, and not an error,
means that Python isn't defining it to a different value than FreeBSD did, so
it's not really a problem. It might be a problem if Python #defines it, but
FreeBSD does not, but FreeBSD does have code that checks that #define, and
starts doing weird things...

> In file included from ../../Python/thread.c:118:
> ../../Python/thread_pthread.h:59: warning: `pthread_attr_default' redefined
> /usr/include/pthread.h:158: warning: this is the location of the previous definition
> ../../Python/thread_pthread.h:60: warning: `pthread_mutexattr_default' redefined
> /usr/include/pthread.h:157: warning: this is the location of the previous definition
> ../../Python/thread_pthread.h:61: warning: `pthread_condattr_default' redefined
> /usr/include/pthread.h:156: warning: this is the location of the previous definition

Not sure about these, because I don't know enough about the various types of
posix thread standards, and almost-posix thread almost-standards. I'm not
sure if those names are reserved in any way, but they are apparently
clashing with FreeBSD names. Or perhaps it's FreeBSD 'compatibility' code
that does the defines like Python does, too. A simple '#undef' or '#ifndef'
would suffice, here, I think, but I'm not sure.


-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!