[tahoe-dev] tahoe not building on openbsd

kyle at arbyte.us kyle at arbyte.us
Thu Nov 12 03:10:37 UTC 2009

> Message: 2
> Date: Wed, 11 Nov 2009 00:20:37 -0700
> From: Zooko Wilcox-O'Hearn <zooko at zooko.com>
> Subject: Re: [tahoe-dev] tahoe not building on openbsd
> To: tahoe-dev at allmydata.org
> Message-ID: <BBFB157C-4140-4ED7-A37E-372A257D58C1 at zooko.com>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
> On Tuesday, 2009-11-10, at 23:57 , <kyle at arbyte.us> <kyle at arbyte.us>  
> wrote:
>> The problem on my end is that I don't know Python (I'm a Perl guy,  
>> don't
>> hurt me!) so I don't know what to tweak.  I know that if I take the  
>> failing
>> ld command and just add
>> -L/usr/lib/gcc-lib/amd64-unknown-openbsd4.6/3.3.5/fpic as the first  
>> switch,
>> the linker will use the correct libgcc and succeed.
> Edit pycryptopp's setup.py [1], find the variable named  
> "extra_link_args", and add the following line:
> extra_link_args.append("-L/usr/lib/gcc-lib/amd64-unknown- 
> openbsd4.6/3.3.5/fpic ")
> Then see if it works.  Hey look!  You just learned Python.  :-)

Yep, it works.  So how do I integrate this change to pycryptopp with the
tahoe build process?  I *could* install pycryptopp as root, then let tahoe
see that pycryptopp already exists, but I would rather do all of this
without being root.  I'll mention again, the fact that the temporary
pycryptopp build area gets automatically deleted when something goes wrong
is a bug.  I wish I could let it fail, then edit and rerun pycryptopp's
setup.py, and then rerun tahoe's setup.py to pick up where I left off. 
Automation is great until it doesn't handle error recovery gracefully.

Is there a fairly straightforward way around this, or am I going to have to
bite the bullet and do this stuff as root?

More information about the tahoe-dev mailing list