[tahoe-dev] tahoe not building on openbsd
kyle at arbyte.us
kyle at arbyte.us
Tue Nov 10 22:57:57 PST 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.
Thanks!
More information about the tahoe-dev
mailing list