On Mon, Jul 15, 2019 at 12:18 AM Jonathan Callen <jcal...@gentoo.org> wrote:
>
> On 7/14/19 11:31 PM, Michał Górny wrote:
> > On Sun, 2019-07-14 at 19:50 -0400, Mike Gilbert wrote:
> >> Signed-off-by: Mike Gilbert <flop...@gentoo.org>
> >> ---
> >> eclass/toolchain-funcs.eclass | 15 ++++-----------
> >> 1 file changed, 4 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> >> index 2e027015c684..7bd90bb4e4a0 100644
> >> --- a/eclass/toolchain-funcs.eclass
> >> +++ b/eclass/toolchain-funcs.eclass
> >> @@ -950,18 +950,11 @@ tc-enables-ssp-all() {
> >> # @FUNCTION: gen_usr_ldscript
> >> # @USAGE: [-a] <list of libs to create linker scripts for>
> >> # @DESCRIPTION:
> >> -# This function generate linker scripts in /usr/lib for dynamic
> >> -# libs in /lib. This is to fix linking problems when you have
> >> -# the .so in /lib, and the .a in /usr/lib. What happens is that
> >> -# in some cases when linking dynamic, the .a in /usr/lib is used
> >> -# instead of the .so in /lib due to gcc/libtool tweaking ld's
> >> -# library search path. This causes many builds to fail.
> >> -# See bug #4411 for more info.
> >> -#
> >> -# Note that you should in general use the unversioned name of
> >> -# the library (libfoo.so), as ldconfig should usually update it
> >> -# correctly to point to the latest version of the library present.
> >> +# This function is deprecated. Use the version from
> >> +# usr-ldscript.eclass instead.
> >> gen_usr_ldscript() {
> >> + ewarn "${FUNCNAME}: Please migrate to usr-ldscript.eclass"
> >> +
> >> local lib libdir=$(get_libdir) output_format="" auto=false
> >> suffix=$(get_libname)
> >> [[ -z ${ED+set} ]] && local ED=${D%/}${EPREFIX}/
> >>
> >
> > Wouldn't this trigger when both toolchain-funcs and usr-ldscript are
> > inherited, in reverse order?
> >
>
> I thought the same at first, but it looks like it will work because
> usr-ldscript inherits toolchain-funcs and both eclasses have include
> guards, so the toolchain-funcs version will always be overridden by
> usr-ldscript, if the later is inherited at all.
Exactly this. I put some thought into this before writing the patch,
and this is the conclusion I came to.
> I'm not sure how fragile this construct is, though.
I think a PMS-level change would be necessary for this to break.
