This is a slightly odd series of 2 patches. The two patches are actually alternative solutions to the same problem. I'm keen to see one of these merged, but I don't know which method would be preferred.
This commit aims to address an issue that was introduced / mentioned in commit 20554a78a9bba278c6b9cbbb4cfc5bde3772c56d (ARC: Conditionalise certain relocations as provided by TLS tools only). The problem is that not all historic versions of binutils have supported the @pcl relocation type. This problem is compounded by the fact that the arithmetic construct that was previously used to synthesise an @pcl like behaviour, does not work on recent versions of binutils. In the commit 20554a78a code was added that selects between the new style @pcl relocations, and the old style arithmetic construct, however, this selection is done based on whether the uClibc user has configured with native threads or not. Of course, a uClibc user could choose to use a modern version of binutils AND configure without native thread support, in which case uClibc will not compile. I have two proposed solutions. In patch 1/2 I simply drop support for the older versions of binutils in favour of the new @pcl relocation type. This feels the cleanest solution, but I don't know how strongly the uClibc(-ng) community feels about maintaining compatibility for older versions of the tools. Given that I anticipated push back against the first patch I took a look at how I might maintain compatibility. It turns out to be pretty easy, and that is patch 2/2. In this patch I drew inspiration from similar examples in the Rules.mak file to check if the toolchain supports @pcl relocations or not. With this done we have a new define based on the specific toolchain feature being supported or not, which can then be used to conditionalise the code. Would you consider merging one of these patches? Thanks, Andrew _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
