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! _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
