Gentoo Archives: gentoo-dev

From: Mike Gilbert <floppym@g.o>
To: Gentoo Dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Re: [PATCH 6/6] toolchain-funcs.eclass: deprecate gen_usr_ldscript
Date: Mon, 15 Jul 2019 15:36:11
Message-Id: CAJ0EP42MFgHHEEfNu8qn=AFKg1OT0aV2snT28ZUonz5QwJACxA@mail.gmail.com
In Reply to: [gentoo-dev] Re: [PATCH 6/6] toolchain-funcs.eclass: deprecate gen_usr_ldscript by Jonathan Callen
1 On Mon, Jul 15, 2019 at 12:18 AM Jonathan Callen <jcallen@g.o> wrote:
2 >
3 > On 7/14/19 11:31 PM, Michał Górny wrote:
4 > > On Sun, 2019-07-14 at 19:50 -0400, Mike Gilbert wrote:
5 > >> Signed-off-by: Mike Gilbert <floppym@g.o>
6 > >> ---
7 > >> eclass/toolchain-funcs.eclass | 15 ++++-----------
8 > >> 1 file changed, 4 insertions(+), 11 deletions(-)
9 > >>
10 > >> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
11 > >> index 2e027015c684..7bd90bb4e4a0 100644
12 > >> --- a/eclass/toolchain-funcs.eclass
13 > >> +++ b/eclass/toolchain-funcs.eclass
14 > >> @@ -950,18 +950,11 @@ tc-enables-ssp-all() {
15 > >> # @FUNCTION: gen_usr_ldscript
16 > >> # @USAGE: [-a] <list of libs to create linker scripts for>
17 > >> # @DESCRIPTION:
18 > >> -# This function generate linker scripts in /usr/lib for dynamic
19 > >> -# libs in /lib. This is to fix linking problems when you have
20 > >> -# the .so in /lib, and the .a in /usr/lib. What happens is that
21 > >> -# in some cases when linking dynamic, the .a in /usr/lib is used
22 > >> -# instead of the .so in /lib due to gcc/libtool tweaking ld's
23 > >> -# library search path. This causes many builds to fail.
24 > >> -# See bug #4411 for more info.
25 > >> -#
26 > >> -# Note that you should in general use the unversioned name of
27 > >> -# the library (libfoo.so), as ldconfig should usually update it
28 > >> -# correctly to point to the latest version of the library present.
29 > >> +# This function is deprecated. Use the version from
30 > >> +# usr-ldscript.eclass instead.
31 > >> gen_usr_ldscript() {
32 > >> + ewarn "${FUNCNAME}: Please migrate to usr-ldscript.eclass"
33 > >> +
34 > >> local lib libdir=$(get_libdir) output_format="" auto=false suffix=$(get_libname)
35 > >> [[ -z ${ED+set} ]] && local ED=${D%/}${EPREFIX}/
36 > >>
37 > >
38 > > Wouldn't this trigger when both toolchain-funcs and usr-ldscript are
39 > > inherited, in reverse order?
40 > >
41 >
42 > I thought the same at first, but it looks like it will work because
43 > usr-ldscript inherits toolchain-funcs and both eclasses have include
44 > guards, so the toolchain-funcs version will always be overridden by
45 > usr-ldscript, if the later is inherited at all.
46
47 Exactly this. I put some thought into this before writing the patch,
48 and this is the conclusion I came to.
49
50 > I'm not sure how fragile this construct is, though.
51
52 I think a PMS-level change would be necessary for this to break.