tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Is there some good reason for taking gdbm out of python build?

On Tue, 20 Aug 2013 06:32:31 +0900, Paul Ackersviller <> 

On Sun, Aug 11, 2013 at 06:48:59PM +0000, Paul Ackersviller wrote:
On Fri, Aug 09, 2013 at 09:13:23AM +0100, Jonathan Perkin wrote:
> Right, I had a horrid time trying to get any recent-ish version of
> Python building on HP/UX a few years ago, and had to settle on running
> an older 2.5 and modifying our code to support that.
> Great if a newer version helps, though.

Unfortunately I spoke to soon on this.  Python's build has the annoying
habit of a successful exit status even when many of the critical modules
didn't compile.  None of this is pkgsrc's problem as far as I can tell.

I'm wondering if, in the meantime, there might be ways for pkgsrc to
have fewer dependencies on python.  Anyone have pointers for this?

Replying to myself, since nobody else has... python 2.7.5 on HP-UX 11.31
does look to be in a reasonably good state after all.  However I'm building
for 64 bits, and the OS doesn't seem to come with a 64-bit libndbm, while
lang/python27/Makefile is specifying --with-dbmliborder=ndbm:bdb, i.e.
it's eliminating gdbm from the default dbmliborder for python.  Building
via --with-dbmliborder=gdbm:bdb after libgdbm solves my immediate problem,
allowing xcb-proto, libxcb, etc. to compile now.

What is happened for you?
`--with-dbmliborder=ndbm:bdb' will try to use ndbm first, and bdb seconded.
Then if ndbm is not provided, bdb will be used instead.

Aside from the issue, gdbm module is provided as databases/py-gdbm.

OBATA Akio /

Home | Main Index | Thread Index | Old Index