Christophe Lyon <christophe.l...@linaro.org> writes: > On Fri, 12 Jul 2019 at 08:49, Richard Sandiford > <richard.sandif...@arm.com> wrote: >> >> Christophe Lyon <christophe.l...@st.com> writes: >> > The new arm-uclinuxfdpiceabi target behaves pretty much like >> > arm-linux-gnueabi. In order the enable the same set of features, we >> > have to update several configure scripts that generally match targets >> > like *-*-linux*: in most places, we add *-uclinux* where there is >> > already *-linux*, or uclinux* when there is already linux*. >> > >> > In gcc/config.gcc and libgcc/config.host we use *-*-uclinuxfdpiceabi >> > because there is already a different behaviour for *-*uclinux* target. >> > >> > In libtool.m4, we use uclinuxfdpiceabi in cases where ELF shared >> > libraries support is required, as uclinux does not guarantee that. >> > >> > 2019-XX-XX Christophe Lyon <christophe.l...@st.com> >> > >> > config/ >> > * futex.m4: Handle *-uclinux*. >> > * tls.m4 (GCC_CHECK_TLS): Likewise. >> > >> > gcc/ >> > * config.gcc: Handle *-*-uclinuxfdpiceabi. >> > >> > libatomic/ >> > * configure.tgt: Handle arm*-*-uclinux*. >> > * configure: Regenerate. >> > >> > libgcc/ >> > * config.host: Handle *-*-uclinuxfdpiceabi. >> > >> > libitm/ >> > * configure.tgt: Handle *-*-uclinux*. >> > * configure: Regenerate. >> > >> > libstdc++-v3/ >> > * acinclude.m4: Handle uclinux*. >> > * configure: Regenerate. >> > * configure.host: Handle uclinux* >> > >> > * libtool.m4: Handle uclinux*. >> >> Has the libtool.m4 patch been submitted to upstream libtool? >> I think this is supposed to be handled by submitting there first >> and then cherry-picking into gcc, so that the change isn't lost >> by a future import. > > Yes, this was raised by Joseph when I first posted this patch series last > year: > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01507.html > I sent a patch there: > https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg00000.html > but didn't get any feedback :-(
Ah, OK. In that case, it might be worth adding a comment to libtool.m4 that this has been submitted to libtool but not (yet?) accepted, so at the moment it's a GCC-local change. That might help the next person applying libtool patches to understand the history. >> > diff --git a/config/tls.m4 b/config/tls.m4 >> > index 1a5fc59..a487aa4 100644 >> > --- a/config/tls.m4 >> > +++ b/config/tls.m4 >> > @@ -76,7 +76,7 @@ AC_DEFUN([GCC_CHECK_TLS], [ >> > dnl Shared library options may depend on the host; this check >> > dnl is only known to be needed for GNU/Linux. >> > case $host in >> > - *-*-linux*) >> > + *-*-linux* | -*-uclinux*) >> > LDFLAGS="-shared -Wl,--no-undefined $LDFLAGS" >> > ;; >> > esac >> >> Is this right for all uclinux targets? > > So...... Let me bring back a bit of history/context. When we developed > FDPIC support in ST several years ago, we used arm-linux-uclibceabi as > triplet. > But when I posted the binutils patch series, Joseph said it wasn't > appropriate and suggested arm-*-uclinuxfdpiceabi instead. > https://sourceware.org/ml/binutils/2018-03/msg00324.html > > This had an impact on the GCC side, because some parts weren't enabled > anymore after the triplet change, so I had to introduce this > configure* patch to restore the missing features. > > Then, I wondered about the impact on other uclinux targets, but it was > hard to find a supported-supposed-to-work one. > I asked for help on the gcc list > (https://gcc.gnu.org/ml/gcc/2018-10/msg00154.html), and finally > managed to build and test an xtensa toolchain. > > And this has an impact on the results on xtensa, as I reported in V3 > of this patch: > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00713.html > > But given the little feedback, I'm wondering whether uclinux targets > are actually still alive/maintained? Well, maybe not maintained :-) But while supporting -shared is AIUI the main goal of FDPIC, I'd be surprised if it was the right thing to test for all uclinux targets. Testing *-*-uclinuxfdpic* would be more obvious IMO. (But there again, I'm not an expert on this stuff.) Thanks, Richard
