in 3.x the _dbm extension can only be built with gdbm as the backend
library. gdbm is licensed under the GPL, so some people/projects like
Debian may have objections to build _dbm with the gdbm backend. It gets
difficult to determine, which code then uses _dbm/anydbm/... and then
check if it is compatible with the GPL.

Unless there is an alternative like dbm.sqlite (issue 3783), I would
like to re-add the detection of the BerkleyDB headers and libs, such
that _dbm can be built again without depending on gdbm. Adding a
configure flag to explicitely select one implementation (issue 4587)
would be helpful.

Ok to go ahead?

fixed on the 3.0 and 3.1 branches

This should be reverted on the py3k branch. The changes to setup.py
cause the select module to be loaded and that doesn't work when it
hasn't be built!

Traceback (most recent call last):
  File "./setup.py", line 1671, in <module>
    main()
  File "./setup.py", line 1666, in main
    'Lib/smtpd.py']
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/distutils/core.py",
line 149, in setup
    dist.run_commands()
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/distutils/dist.py",
line 943, in run_commands
    self.run_command(cmd)
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/distutils/dist.py",
line 963, in run_command
    cmd_obj.run()
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/distutils/command/build.py",
line 128, in run
    self.run_command(cmd_name)
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/distutils/cmd.py",
line 317, in run_command
    self.distribution.run_command(command)
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/distutils/dist.py",
line 963, in run_command
    cmd_obj.run()
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/distutils/command/build_ext.py",
line 347, in run
    self.build_extensions()
  File "./setup.py", line 103, in build_extensions
    missing = self.detect_modules()
  File "./setup.py", line 709, in detect_modules
    for x in gen_db_minor_ver_nums(4):
  File "./setup.py", line 686, in gen_db_minor_ver_nums
    if allow_db_ver((4, x)):
  File "./setup.py", line 677, in allow_db_ver
    arch = platform_machine()
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/platform.py",
line 1222, in machine
    return uname()[4]
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/platform.py",
line 1152, in uname
    processor = _syscmd_uname('-p','')
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/platform.py",
line 905, in _syscmd_uname
    f = os.popen('uname %s 2> /dev/null' % option)
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/os.py", line
629, in popen
    import subprocess, io
  File
"/home/buildbot/slave/py-build/3.x.norwitz-amd64/build/Lib/subprocess.py",
line 373, in <module>
    import select
ImportError: No module named select

I'm removing the db4.6 check instead. This was useful when building the
_bsddb3 extension, where threading tests would fail on these
architectures. It's not necessary for building the _dbm extension.

2009/4/7 Matthias Klose <report@bugs.python.org>:
>
> Matthias Klose <doko@debian.org> added the comment:
>
> I'm removing the db4.6 check instead. This was useful when building the
> _bsddb3 extension, where threading tests would fail on these
> architectures. It's not necessary for building the _dbm extension.

Ok. Just make sure "make clean; make" works.

> Ok. Just make sure "make clean; make" works.

done. the "make clean" was missing before.