[tahoe-dev] tahoe not building on openbsd

kyle at arbyte.us kyle at arbyte.us
Wed Nov 11 06:57:57 UTC 2009

Zooko et al,

>> relocation R_X86_64_32S can not be used when making a shared  
>> object; recompile with -fPIC
> ...
> Hm, maybe -fPIC is required to build Crypto++ on OpenBSD?  This page  
> claims that Crypto++ 5.6.0 built okay on OpenBSD 4.4 with gcc 3.3.5:  
> http://www.cryptopp.com/cgi-bin/fom.cgi?_recurse=1&file=99#file_107

I figured out how get pycryptopp to build on my system.  The problem is
that the linker was defaulting to the non-PIC version of libgcc.  A PIC
version exists too (in .../3.3.5/fpic/ instead of in ...3.3.5/) but I do
not know how to make that the default.

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.  I can do that
manually, on a copy of pycryptopp that I separately downloaded.  But I
don't know how to fix the pycryptopp compilation process to add that switch
automatically -- and it's even less clear how I would get that switch added
during the tahoe build process and automagically passed down to the
embedded pycryptopp download and compile.

Is there an easy fix for me?

> What we really need is an OpenBSD buildslave to add to http:// 
> allmydata.org/buildbot-pycryptopp/waterfall .  Then we'll always know  
> whether the current darcs head of pycryptopp builds and passes tests  
> on OpenBSD.
> Regards,
> Zooko

I'd volunteer to do this, but I suspect that not knowing Python may make me
ineffective here.


More information about the tahoe-dev mailing list