[tahoe-dev] tahoe not building on openbsd
kyle at arbyte.us
kyle at arbyte.us
Wed Nov 11 19:10:37 PST 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