Bug 11616 - 2018.02.09 fails to build libzlib with full RELRO protection
Summary: 2018.02.09 fails to build libzlib with full RELRO protection
Status: RESOLVED WONTFIX
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: 2018.02.9
Hardware: Other Linux
: P5 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-11 07:39 UTC by Karl Krach
Modified: 2019-01-14 21:33 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:

Attachments
defconfig which fails (2.44 KB, text/plain)
2019-01-11 07:39 UTC, Karl Krach 		Details
compile output with full RELRO (failed) (19.81 KB, text/plain)
2019-01-11 07:44 UTC, Karl Krach 		Details
compile output with partial RELRO (succeeded) (20.13 KB, text/plain)
2019-01-11 07:45 UTC, Karl Krach 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Karl Krach 2019-01-11 07:39:28 UTC 
Created attachment 7911 [details]
defconfig which fails

Compiling libzlib the given defconfig (powerpc, GCC 7.3, BR2_RELRO_FULL=y) fails with

     sysroot/usr/lib/Scrt1.o: In function `_start':
(.text+0x42): undefined reference to `main'
     collect2: error: ld returned 1 exit status


Switching RELRO off or to partial, compiles successfully.
Comment 1 Karl Krach 2019-01-11 07:44:54 UTC 
Created attachment 7916 [details]
compile output with full RELRO (failed)
Comment 2 Karl Krach 2019-01-11 07:45:18 UTC 
Created attachment 7921 [details]
compile output with partial RELRO (succeeded)
Comment 3 Matt Weber 2019-01-11 14:16:52 UTC 
Could you do a build with this stock config in Buildroot and verify the issue is repeatable?

qemu_ppc64_e5500_defconfig


This doesn't isolate the issue to the specific architecture but should simplify your defconfig so I can help further.
Comment 4 Thomas Petazzoni 2019-01-12 09:21:22 UTC 
Matt: the bug is reported against 2018.02.9, i.e the LTS branch and not 2018.11 or master. Back in 2018.02.x, the support in the wrapper for RELRO was not there.
Comment 5 Matt Weber 2019-01-12 13:59:11 UTC 
Tho(In reply to Thomas Petazzoni from comment #4)

Oh right.  So then for this failure case it is a known issue that the ordering of linker steps in most packages are not correct to support RELRO full.  Which is what lead to using the toolchain wrapper to adjust ordering as the current solution.

Karl, are you able to bump versions to 2018.11 or next month to the new LTS?  If not I can help you find the series of commits to add to your LTS that enable the toolchain wrapper method, however you'd have to carry your own LTS branch locally for this to work.
Comment 6 Karl Krach 2019-01-14 07:49:59 UTC 
Matt, for me partial RELRO is fine for now. I will switch to the next LTS when available. Thanks.
Comment 7 Matt Weber 2019-01-14 14:06:47 UTC 
If you did need to do full RELRO, you could pull the following commits in on your LTS to change the toolchain-wrapper behavior.

git cherry-pick d4f5801027f3329fb6c2cd096f3396d3cd067390  01d8a0a9455f9408819d7f135fba5139f0672507 7484c1c3b8065d6f2f5a67607e9917ecfea022eb f10822d151085bcbfecd0ecf2542ac5f5623fd9d 


Care to mark this one closed?
Comment 8 Thomas Petazzoni 2019-01-14 21:33:23 UTC 
Full RELRO has been fixed post-2018.02 by changing the toolchain-wrapper. This is too invasive to backport in 2018.02, so only later Buildroot versions will have proper full RELRO support.