Bug 1276066 - Not compiled with -fPIC for x86_64 and ARM
Summary: Not compiled with -fPIC for x86_64 and ARM
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: nacl
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-28 15:00 UTC by Stuart D Gathman
Modified: 2015-11-07 15:17 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-04 09:36:52 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Stuart D Gathman 2015-10-28 15:00:23 UTC
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 10:30:38 UTC
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 12:09:25 UTC
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 14:10:53 UTC
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 18:33:13 UTC
The static library goes in nacl-devel, along with the headers and symlinks to dynamic libraries.

Comment 5 Stuart D Gathman 2015-10-29 18:35:56 UTC
The dynamic libraries go in the nacl package along with the included apps.

Comment 6 Stuart D Gathman 2015-10-29 20:48:32 UTC
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 17:40:04 UTC
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 19:01:16 UTC
(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 09:36:52 UTC
Closing as rawhide, let me know or reopen if the problem persist.

Comment 10 Stuart D Gathman 2015-11-05 00:02:35 UTC
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-05 00:17:42 UTC
Added -lstdc++, and got further.  I guess that is ok.

Comment 12 Stuart D Gathman 2015-11-05 01:23:21 UTC
Sucessfully built cjdns package with dynamic libnacl, and it still works even.  Thanks!

Comment 13 Stuart D Gathman 2015-11-05 01:24:34 UTC
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 09:31:00 UTC
(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 15:17:47 UTC
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.