The cross_prelink_staging branch seems to work for our ARM Cortex-A53 configuration.
The only issue that I ran into was building src/rtld/dl-open.c. I guess the GCCVERSION we declared (4.9%) was defaulting to a language standard that didn't support for loop initial declarations. On Mon, Jun 20, 2016 at 9:15 AM, Mark Hatle <mark.ha...@windriver.com> wrote: > On 6/20/16 7:24 AM, Kyle Russell wrote: > > It looks like the image-prelink support is still disabled in master > because of > > an issue with IFUNC symbol relocation. > > > > > https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta-poky/conf/local.conf.sample?id=8debfea81e69d038bd2d56314b272cb74f5582ed > > > > Is there still a problem, or is it safe to reenable image-prelink? I > see a "Fix > > ARM IFUNC support" in the prelink-cross repo, but that appears to have > been > > committed several months before image-prelink was disabled. We'd like > to enable > > image-prelink on a build off jethro. > > > > Any help or links to a recent discussion thread would be helpful. > Thanks! > > > > > > The ARM fix is for a different IFUNC problem. > > Disabling the prelinker was caused by a serious of problems that started > with a > fork failure traced back to shared library processing orders. > > (For comments below, I'm referring to the repository: > http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/) > > The initial problem, IFUNC processing, showed that processing order of the > shared libraries could lead to a case where the wrong IFUNC was used. We > believe this particular issues was fixed in the staging tree. > > In the tree you'll see a cross_prelink_staging branch. In that branch the > fix > is commit ID: "8f55afd84b3580b1f1d6af904e8c2a39221055b7" This fixes the > 'fork' > issue by ensuring the proper sort order for shared library processing. > (This > was finally fixed in March.) > > However with that we determined there was at least one more issue related > to > section ordering. The prelink test suite was failing due to various > integrity > checks showing that once we prelinked something, we could not reverse the > process. It has taken us months to identify the cause of the problem and > the > solution. (Cause BTW was a change in binutils-2.22 that no longer ensured > that > the section order was sorted by offset order... a small amount of the > prelink > processing needed to be changed to deal with that behavior. It's taken far > longer to fix then we had ever expected.) > > See commit (33be255d62af533189f1f7bc66c06602b703980a) in the > cross_prelink_staging branch. > > With this commit, I think the two major issues have been resolved. I've > got a > small set of additional patches I need to put into place -- and then I > have to > finish going through the regression suite to verify everything is working > properly. (Seems like every time I get to this step, something else comes > up > and I'm not getting it done...) > > So if you've read this far, the point in all of this is that I THINK that > the > cross_prelink_staging branch and current top commit > "33be255d62af533189f1f7bc66c06602b703980a" are working. However, I've not > completed testing so I'm not sure of that yet. > > If you can help with testing, you should modify your prelink recipe to use > the > 'cross_prelink_staging' branch, and the 33be255 commit. Verify that this > is > working for your use cases. If you are using glib or graphical > environments pay > particular attention to process startup messages that indicate failures. > > If this IS working for you, I'd like a reply back with the architecture and > processor you are using so I can add that to my matrix. (I'm traveling > for the > next couple of days, and then should be back in the officer where I hope to > finish my regression testing, apply the last couple of patches from Gentoo > developers, regression test again and prepare a release version.) > > Any help is appreciated, thanks for understanding why this is taking so > long. > > --Mark >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto