[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages 
From:       Michał_Górny <mgorny () gentoo ! org>
Date:       2017-09-29 10:51:36
Message-ID: 9C01C163-1EC3-453C-A9CE-2C561E6BF71A () gentoo ! org
[Download RAW message or body]

Dnia 29 września 2017 11:29:03 CEST, Michael Haubenwallner <haubi@gentoo.org> napisał(a):
>On 09/29/2017 10:33 AM, Marty E. Plummer wrote:
>> On Fri, Sep 29, 2017 at 08:29:07AM +0000, Michael Haubenwallner
>wrote:
>>> On 09/29/2017 03:36 AM, Marty E. Plummer wrote:
>>>> On Thu, Sep 28, 2017 at 07:35:20PM +0000, Mike Gilbert wrote:
>>>>> On Wed, Sep 20, 2017 at 10:01 PM, Marty E. Plummer
>>>>> <hanetzer@startmail.com> wrote:
>>>>>> arfrever suggests I send a mail here, as there are other packages
>which
>>>>>> may be affected by this issue and perhaps a more generalized fix
>is
>>>>>> required instead of an explicit fix in sys-libs/ncurses and other
>ebuilds
>>>>>> that may require it.
>>>>>
>>>>> I think the solution here is to remove those overly broad "find
>>>>> -delete" statements and replace them with something safer.
>>>>>
>>>>> Ideally the build system(s) would be patched to not compile static
>>>>> libs in the first place.
>>>>>
>>>>> If that's not possible, perhaps an eclass function could be
>created to
>>>>> safely remove static libs.
>>>>>
>>>> Honestly I already have a pr up that fixes this particular
>package's
>>>> issue, fairly simple fix https://github.com/gentoo/gentoo/pull/5734
>>>>
>>>> --- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
>>>> +++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
>>>> @@ -241,7 +241,8 @@ multilib_src_install() {
>>>>  		# Provide a link for -lcurses.
>>>>  		ln -sf libncurses$(get_libname)
>"${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
>>>>  	fi
>>>> -	use static-libs || find "${ED}"/usr/ -name '*.a' -delete
>>>> +	# don't delete '*.dll.a', needed for linking #631468
>>>> +	use static-libs || find "${ED}"/usr/ -name '*.a' ! -name
>'*.dll.a' -delete
>>>
>>> In prefix overlay we have this version:
>>>
>>>   use static-libs || find "${ED}"/usr/ -name '*.a' -not -name
>"*$(get_libname)" -delete
>>>
>> Won't work here, as $(get_libname) returns .dll in this case, which
>is
>> why the symlinking is busted
>
>Indeed! Although I do believe get_libname should return the
>(dynamically) linkable file
>name rather than the dynamically loadable one, because a build system's
>target often is
>the dynamically linkable file, creating the loadable as side effect.
>Note that only COFF
>based systems (AIX, Windows) may distinguish (dynamically) linkable and
>loadable files.

Why not add a separate function to avoid this ambiguity?

>
>Additionally (although unused in Prefix), AIX allows for one single
>file libN.a containing
>Shared Objects, which can be statically linked too!
>
>And for winnt I've yet to decide the value for $(get_libname) as the
>Import Library:
>Candidates are ".so", ".dll.a", ".dll.lib" - as I do support all of
>them in the msvc
>wrapper ("parity") to reduce the need of patching various build systems
>for now...
>
>So probably the real safe one here is (in case get_libname may return
>".a"):
>
>use static-libs || find "${ED}"/usr/ -name '*.a' -not -name '*.dll.a'
>-not -name "*$(get_libname)" -delete
>
>OR: Really have some function prune_static_libs to remove library files
>serving as
>Static Library only - neither as Import Library nor Shared Library:
>Implemented
>for some platforms to ignore the file name but inspect the content
>instead.
>
>Remember: This is (related but) different from prune_libtool_libs,
>which suggests the find "${D}" -name '*.la' -delete alternative only.
>
>/haubi/


-- 
Best regards,
Michał Górny (by phone)

[prev in list] [next in list] [prev in thread] [next in thread]