2.1.0 Build failure on FreeBSD [+ easy fix]

Bug #518852 reported by dns
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Python-Crypto
Fix Released
Undecided
Unassigned
Tahoe-LAFS
New
Unknown

Bug Description

In src/libtom/tomcrypt_pk.h:499, there is a check for whether wchar_t is defined. We have one FreeBSD 5.3 (which I know is an extremely old version, but we still build on it for compatibility reasons) system where stdlib.h defines wchar_t and defines _WCHAR_T_DECLARED. But that's not one of the flags tomcrypt_pk.h checks, so wchar_t ends up being redefined. Simple fix is to just add _WCHAR_T_DECLARED to the list of checks.

Revision history for this message
Daira Hopwood (daira) wrote :

This also happens on a NetBSD system (one of the buildslaves for Tahoe-LAFS):

In file included from src/libtom/tomcrypt.h:72,
                 from src/libtom/tomcrypt_des.c:11,
                 from src/DES.c:32:
src/libtom/tomcrypt_pk.h:502: error: conflicting types for 'wchar_t'
/usr/include/stdlib.h:52: error: previous declaration of 'wchar_t' was here
error: Setup script exited with error: command 'cc' failed with exit status 1

If PyCrypto does not depend on the functions that use wchar_t, then it may be better to disable that code rather than adding _WCHAR_T_DECLARED to the checks.

Revision history for this message
midnightmagic (midnightlaunch) wrote :

Note also; the NetBSD machine in question does not define _WCHAR_T_DECLARED, neither do NetBSD systems up to at least 2009 or so.

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

So the simple fix of adding _WCHAR_T_DECLARED to the list of checks won't fix this issue for NetBSD.

The other solution of removing the declaration of wchar_t entirely since PyCrypto does not use it would certainly fix the issue for NetBSD.

Changed in tahoe-lafs:
importance: Undecided → Unknown
status: New → Unknown
Revision history for this message
Darsey Litzenberger (dlitz) wrote :

I'd rather not modify the libtomcrypt code too much if I can avoid it. Does this patch work for you?

diff --git a/setup.py b/setup.py
index 9346a3d..67d8c59 100644
--- a/setup.py
+++ b/setup.py
@@ -121,6 +121,9 @@ class PCTBuildExt (build_ext):

         # Tweak compiler options
         if self.compiler.compiler_type in ('unix', 'cygwin', 'mingw32'):
+ # Tell GCC to compile using the C99 standard.
+ self.__add_compiler_option("-std=c99")
+
             # Make assert() statements always work
             self.__remove_compiler_option("-DNDEBUG")

Revision history for this message
Darsey Litzenberger (dlitz) wrote :

Do you mean _WCHAR_T_DECLARED or _WCHAR_T_DEFINED? The latter is already checked for in libtom_pk.h

Revision history for this message
Darsey Litzenberger (dlitz) wrote :

The relevant code looks like this:

/* UTF-8 */
#if (defined(SIZE_MAX) || __STDC_VERSION__ >= 199901L || defined(WCHAR_MAX) || defined(_WCHAR_T) || defined(_WCHAR_T_DEFINED)) && !defined(LTC_NO_WCHAR)
#include <wchar.h>
#else
typedef ulong32 wchar_t;
#endif

Changed in pycrypto:
status: New → Confirmed
Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

The NetBSD user of Tahoe-LAFS has patched his NetBSD system in some way to work-around or fix this bug, so our NetBSD buildslave is now green:

http://tahoe-lafs.org/buildbot/builders/MM%20netbsd4%20i386%20warp/builds/283

Our OpenSolaris buildslave is still red:

http://tahoe-lafs.org/buildbot/builders/David%20A.%20OpenSolaris%20i386/builds/196/steps/build/logs/stdio

That one is due to a different problem -- the detection of libgmp and gmp.h -- and I don't know if the owner of that machine is willing to install patches to PyCrypto.

Changed in tahoe-lafs:
status: Unknown → New
Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

A user of Tahoe-LAFS tried to build on FreeBSD and hit this problem:

http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004514.html

Revision history for this message
Darsey Litzenberger (dlitz) wrote :

Is that with the -std=c99 patch?

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

No, the user of Tahoe-LAFS acquired PyCrypto v2.1.0 and built it (actually setuptools did so automatically). They didn't apply any patch.

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Another user tried to build Tahoe-LAFS and hit this problem on FreeBSD:

Downloading http://www.pycrypto.org/files/pycrypto-2.1.0.tar.gz
Processing pycrypto-2.1.0.tar.gz
Running pycrypto-2.1.0/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-3Wigpx/pycrypto-2.1.0/egg-dist-tmp-L9T405
Unable to execute darcs -- if you are building a package with 'setup.py
sdist', 'setup.py bdist_egg', or other package-building commands, then the
resulting package might be missing some files. If you are not building a
package then you can ignore this warning.
warning: GMP library not found; Not building Crypto.PublicKey._fastmath.
src/SHA256.c: In function 'hash_digest':
src/SHA256.c:225: warning: passing argument 1 of 'hash_copy' discards
qualifiers from pointer target type
src/SHA256.c: In function 'ALG_new':
src/SHA256.c:208: warning: passing argument 2 of 'sha_process' discards
qualifiers from pointer target type
src/SHA256.c: In function 'ALG_update':
src/SHA256.c:208: warning: passing argument 2 of 'sha_process' discards
qualifiers from pointer target type
In file included from src/libtom/tomcrypt.h:72,
                from src/libtom/tomcrypt_des.c:11,
                from src/DES.c:32:
src/libtom/tomcrypt_pk.h:502: error: conflicting types for 'wchar_t'
/usr/include/stdlib.h:58: error: previous declaration of 'wchar_t' was here
error: Setup script exited with error: command 'cc' failed with exit status
1

Revision history for this message
Darsey Litzenberger (dlitz) wrote :

See: http://gitweb.pycrypto.org/?p=crypto/pycrypto-2.x.git;a=commitdiff;h=574ffac9f5d290933e8c0678c430fa8eabc962d0

I'm marking this as fixed. Feel free to re-open the bug if it's still a problem in PyCrypto 2.2.

Changed in pycrypto:
status: Confirmed → In Progress
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.