Bug 1276066 - Not compiled with -fPIC for x86_64 and ARM
Not compiled with -fPIC for x86_64 and ARM
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: nacl (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jaroslav Škarvada
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-28 11:00 EDT by Stuart D Gathman
Modified: 2015-11-07 10:17 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-04 04:36:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stuart D Gathman 2015-10-28 11:00:23 EDT
Description of problem:
libnacl.a is not compiled with -fPIC on all architectures.

Version-Release number of selected component (if applicable):
nacl-devel-20110221-9.fc21.x86_64

How reproducible:
always

Steps to Reproduce:
1. attempt to link application compiled with -fPIC with libnacl
2. 
3.

Actual results:
/usr/lib/libnacl.a not compiled with -fPIC

Expected results:
successful link

Additional info:
https://bugzilla.redhat.com/show_bug.cgi?id=1268716

There may be good reasons for not using -fPIC.  I'm not sure what the solution is in that case.  Is a dynamic library a possibility?

Workaround: use an embedded copy of nacl
Comment 1 Jaroslav Škarvada 2015-10-29 06:30:38 EDT
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.
Comment 2 Jaroslav Škarvada 2015-10-29 08:09:25 EDT
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).
Comment 3 Jaroslav Škarvada 2015-10-29 10:10:53 EDT
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).
Comment 4 Stuart D Gathman 2015-10-29 14:33:13 EDT
The static library goes in nacl-devel, along with the headers and symlinks to dynamic libraries.
Comment 5 Stuart D Gathman 2015-10-29 14:35:56 EDT
The dynamic libraries go in the nacl package along with the included apps.
Comment 6 Stuart D Gathman 2015-10-29 16:48:32 EDT
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.
Comment 7 Stuart D Gathman 2015-11-03 12:40:04 EST
Any progress on this?  I'd like to be able to stop using embedded nacl in the cjdns package.
Comment 8 Jaroslav Škarvada 2015-11-03 14:01:16 EST
(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.
Comment 9 Jaroslav Škarvada 2015-11-04 04:36:52 EST
Closing as rawhide, let me know or reopen if the problem persist.
Comment 10 Stuart D Gathman 2015-11-04 19:02:35 EST
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)
Comment 11 Stuart D Gathman 2015-11-04 19:17:42 EST
Added -lstdc++, and got further.  I guess that is ok.
Comment 12 Stuart D Gathman 2015-11-04 20:23:21 EST
Sucessfully built cjdns package with dynamic libnacl, and it still works even.  Thanks!
Comment 13 Stuart D Gathman 2015-11-04 20:24:34 EST
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.
Comment 14 Jaroslav Škarvada 2015-11-05 04:31:00 EST
(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.
Comment 15 Stuart D Gathman 2015-11-07 10:17:47 EST
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.

Note You need to log in before you can comment on or make changes to this bug.