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!