Bug 1276066

Could you check rawhide? It should be compiled as PIC there. I don't like to backport, because all depending packages would require recompilation. I will also check possibility of the dynamic library.

Also built shared library in rawhide, it is in 'nacl' package. The static libraries are now in 'nacl-static' subpackage.

Is it enough to fix it in rawhide? I could probably backport to f23, because it's already PIC there (IMHO), but probably not to f22 (it's not PIC there).

Reassigning to rawhide and closing as rawhide - the linked review is also against rawhide. Please let me know if backport is needed (f23 shouldn't be problem, IMHO f22 is not worth the effort).

The static library goes in nacl-devel, along with the headers and symlinks to dynamic libraries.

The dynamic libraries go in the nacl package along with the included apps.

I built the SRPM from rawhide for f22, and the dynamic object only has one entry point: randombytes.  I'll extract the so from the rawhide package and see if it has the same problem... yep, same problem.

Any progress on this?  I'd like to be able to stop using embedded nacl in the cjdns package.

(In reply to Stuart D Gathman from comment #7)
> Any progress on this?  I'd like to be able to stop using embedded nacl in
> the cjdns package.

Please try nacl-20110221-14.fc24 and report problems.

Alternatively you may link with static libraries - all are compiled with -fPIC in rawhide.

Closing as rawhide, let me know or reopen if the problem persist.

How are these resolved in the static library?  

Error: gcc -Wl,-z,relro,-z,now,-z,noexecstack,-pie,-flto,-O3 -o build_linux/contrib_c_privatetopublic_c build_linux/util_Assert_c.o,build_linux/util_Bits_c.o,build_linux/crypto_AddressCalc_c.o,build_linux/memory_Allocator_c.o,build_linux/util_CString_c.o,build_linux/benc_String_c.o,build_linux/crypto_Key_c.o,build_linux/util_Hex_c.o,build_linux/util_platform_Sockaddr_c.o,build_linux/util_AddrTools_c.o,build_linux/dht_Address_c.o,build_linux/contrib_c_privatetopublic_c.o -lnacl,build_linux/dependencies/libuv/out/Release/libuv.a,-lpthread,-lrt

/usr/lib/gcc/i686-redhat-linux/5.1.1/../../../libnacl.so: undefined reference to `__cxa_allocate_exception'
/usr/lib/gcc/i686-redhat-linux/5.1.1/../../../libnacl.so: undefined reference to `typeinfo for char const*'
/usr/lib/gcc/i686-redhat-linux/5.1.1/../../../libnacl.so: undefined reference to `__gxx_personality_v0'
/usr/lib/gcc/i686-redhat-linux/5.1.1/../../../libnacl.so: undefined reference to `__cxa_throw'
/usr/lib/gcc/i686-redhat-linux/5.1.1/../../../libnacl.so: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, unsigned int, std::allocator<char> const&)'
/usr/lib/gcc/i686-redhat-linux/5.1.1/../../../libnacl.so: undefined reference to `std::string::_Rep::_M_destroy(std::allocator<char> const&)'
/usr/lib/gcc/i686-redhat-linux/5.1.1/../../../libnacl.so: undefined reference to `std::string::_Rep::_S_empty_rep_storage'
/usr/lib/gcc/i686-redhat-linux/5.1.1/../../../libnacl.so: undefined reference to `std::string::assign(std::string const&)'
collect2: error: ld returned 1 exit status

    at error (/home/stuart/rpm/BUILD/cjdns-cjdns-v17.1/node_build/builder.js:52:15)
    at /home/stuart/rpm/BUILD/cjdns-cjdns-v17.1/node_build/builder.js:121:22
    at /home/stuart/rpm/BUILD/cjdns-cjdns-v17.1/node_build/builder.js:91:13
    at ChildProcess.<anonymous> (/home/stuart/rpm/BUILD/cjdns-cjdns-v17.1/node_build/Semaphore.js:7:30)
    at ChildProcess.emit (events.js:98:17)
    at maybeClose (child_process.js:766:16)
    at Process.ChildProcess._handle.onexit (child_process.js:833:5)
error: Bad exit status from /var/tmp/rpm-tmp.NB1fu8 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.NB1fu8 (%build)

Added -lstdc++, and got further.  I guess that is ok.

Sucessfully built cjdns package with dynamic libnacl, and it still works even.  Thanks!

BTW, the SRPM from rawhide builds with no issues on f22 and f23.  Why can't it simply be rebuilt for those releases?  It can't break any programs built from the static libs.

(In reply to Stuart D Gathman from comment #13)
> BTW, the SRPM from rawhide builds with no issues on f22 and f23.  Why can't
> it simply be rebuilt for those releases?  It can't break any programs built
> from the static libs.

Probably no problem with f23, but (IMHO) on f22 it's compiled without PIC and so did other projects using it there. By changing to PIC we would force them to rebuild with PIC (and all their deps) in case they issue updates there. I think we should avoid such change in approx. half of the live cycle of the stable release.

No problem.  I doubt my cjdns package will get approved for f22.  I am just including an updated nacl in my private repo for f22.