On Fri, 30 Aug 2019 at 16:49, Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Christophe Lyon <christophe.lyon@linaro.org> writes:
> > On Fri, 30 Aug 2019 at 11:00, Richard Sandiford
> > <richard.sandiford@arm.com> wrote:
> >>
> >> Christophe Lyon <christophe.lyon@st.com> writes:
> >> > @@ -785,7 +785,7 @@ case ${target} in
> >> >    esac
> >> >    tmake_file="t-slibgcc"
> >> >    case $target in
> >> > -    *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
> >> > +    *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu  | *-*-uclinuxfdpiceabi)
> >> >        :;;
> >> >      *-*-gnu*)
> >> >        native_system_header_dir=/include
> >>
> >> I don't think this is necessary, since this target will never match the
> >> following *-*-gnu*) stanza anyway.
> > OK (I thought it was clearer to add the fdpic config where we already
> > have linux that would not match)
>
> I think the idea is to match pure GNU systems only in the second stanza
> (i.e. GNU/Hurd).  So we need the first stanza to exclude hybrid-GNU
> systems like GNU/Linux, GNU/Solaris, GNU/FreeBSD, etc.
>
> Since uclinuxfdpiceabi isn't a GNU-based system, I don't think it
> needs to appear at all.
>
> >> > diff --git a/libtool.m4 b/libtool.m4
> >> > index 8966762..64e507a 100644
> >> > --- a/libtool.m4
> >> > +++ b/libtool.m4
> >> > @@ -3734,7 +3739,7 @@ m4_if([$1], [CXX], [
> >> >           ;;
> >> >       esac
> >> >       ;;
> >> > -      linux* | k*bsd*-gnu | kopensolaris*-gnu)
> >> > +      linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
> >> >       case $cc_basename in
> >> >         KCC*)
> >> >           # KAI C++ Compiler
> >>
> >> Is this needed?  It seems to be in the !GCC branch of an if/else.
> > I must admit I didn't test this case. I thought it was needed because
> > this target does not match "linux*", in case someone tries to compile
> > with another compiler...
> >
> >
> >>
> >> If it is needed, the default:
> >>
> >>         _LT_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
> >>
> >> seems correct for non-FDPIC uclinux.
> >>
> > So, either use uclinuxfdpiceabi above, or do nothing and do not try to
> > support other compilers?
>
> Yeah.  I think the latter's better, since in this context we only
> need libtool.m4 to support building with GCC.  The decision might
> be different for upstream libtool, but do any commercial compilers
> support Arm FDPIC yet?
>
> >> > @@ -4032,7 +4037,7 @@ m4_if([$1], [CXX], [
> >> >        _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
> >> >        ;;
> >> >
> >> > -    linux* | k*bsd*-gnu | kopensolaris*-gnu)
> >> > +    linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
> >> >        case $cc_basename in
> >> >        # old Intel for x86_64 which still supported -KPIC.
> >> >        ecc*)
> >>
> >> Same here.
> >>
> >> > @@ -5946,7 +5951,7 @@ if test "$_lt_caught_CXX_error" != yes; then
> >> >          _LT_TAGVAR(inherit_rpath, $1)=yes
> >> >          ;;
> >> >
> >> > -      linux* | k*bsd*-gnu | kopensolaris*-gnu)
> >> > +      linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
> >> >          case $cc_basename in
> >> >            KCC*)
> >> >           # Kuck and Associates, Inc. (KAI) C++ Compiler
> >>
> >> Here too the code seems to be dealing specifically with non-GCC compilers.
> >>
> >> > @@ -6598,7 +6603,7 @@ interix[[3-9]]*)
> >> >    _LT_TAGVAR(postdeps,$1)=
> >> >    ;;
> >> >
> >> > -linux*)
> >> > +linux* | uclinux*)
> >> >    case `$CC -V 2>&1 | sed 5q` in
> >> >    *Sun\ C*)
> >> >      # Sun C++ 5.9
> >>
> >> Here too.  (It only seems to do anything for Sun's C compiler.)
> >>
> >> The fewer hunks we have to maintain downstream the better :-)
> >>
> > Sure.
> >
> > I thought safer/cleaner to prepare the cases for non-GCC compilers, I
> > guess it's better not to add that until proven useful?
>
> Yeah, I think so.  I guess it depends on your POV.  To me, it seems
> cleaner to add uclinux* and uclinuxfdpiceabi only where we know there's
> a specific need, since that's also how we decide which of uclinux* and
> uclinuxfdpiceabi to use.
>

OK, here is an updated version of this patch.

Christophe

> Thanks,
> Richard