[gentoo-dev] Re: [PATCH 6/6] toolchain-funcs.eclass: deprecate gen_usr_ldscript

[Jonathan Callen]

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 <floppym@g.o>
>> ---
>>  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.  I'm not sure how
fragile this construct is, though.

-- 
Jonathan