Gentoo Archives: gentoo-dev

From: Michael Haubenwallner <haubi@g.o>
To: gentoo-dev@l.g.o
Cc: "Marty E. Plummer" <hanetzer@×××××××××.com>
Subject: [gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected
Date: Fri, 29 Sep 2017 09:29:12
Message-Id: d7223a27-6e14-2218-7b73-4500b84bcb15@gentoo.org
In Reply to: [gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected by "Marty E. Plummer"
1 On 09/29/2017 10:33 AM, Marty E. Plummer wrote:
2 > On Fri, Sep 29, 2017 at 08:29:07AM +0000, Michael Haubenwallner wrote:
3 >> On 09/29/2017 03:36 AM, Marty E. Plummer wrote:
4 >>> On Thu, Sep 28, 2017 at 07:35:20PM +0000, Mike Gilbert wrote:
5 >>>> On Wed, Sep 20, 2017 at 10:01 PM, Marty E. Plummer
6 >>>> <hanetzer@×××××××××.com> wrote:
7 >>>>> arfrever suggests I send a mail here, as there are other packages which
8 >>>>> may be affected by this issue and perhaps a more generalized fix is
9 >>>>> required instead of an explicit fix in sys-libs/ncurses and other ebuilds
10 >>>>> that may require it.
11 >>>>
12 >>>> I think the solution here is to remove those overly broad "find
13 >>>> -delete" statements and replace them with something safer.
14 >>>>
15 >>>> Ideally the build system(s) would be patched to not compile static
16 >>>> libs in the first place.
17 >>>>
18 >>>> If that's not possible, perhaps an eclass function could be created to
19 >>>> safely remove static libs.
20 >>>>
21 >>> Honestly I already have a pr up that fixes this particular package's
22 >>> issue, fairly simple fix https://github.com/gentoo/gentoo/pull/5734
23 >>>
24 >>> --- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
25 >>> +++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
26 >>> @@ -241,7 +241,8 @@ multilib_src_install() {
27 >>> # Provide a link for -lcurses.
28 >>> ln -sf libncurses$(get_libname) "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
29 >>> fi
30 >>> - use static-libs || find "${ED}"/usr/ -name '*.a' -delete
31 >>> + # don't delete '*.dll.a', needed for linking #631468
32 >>> + use static-libs || find "${ED}"/usr/ -name '*.a' ! -name '*.dll.a' -delete
33 >>
34 >> In prefix overlay we have this version:
35 >>
36 >> use static-libs || find "${ED}"/usr/ -name '*.a' -not -name "*$(get_libname)" -delete
37 >>
38 > Won't work here, as $(get_libname) returns .dll in this case, which is
39 > why the symlinking is busted
40
41 Indeed! Although I do believe get_libname should return the (dynamically) linkable file
42 name rather than the dynamically loadable one, because a build system's target often is
43 the dynamically linkable file, creating the loadable as side effect. Note that only COFF
44 based systems (AIX, Windows) may distinguish (dynamically) linkable and loadable files.
45
46 Additionally (although unused in Prefix), AIX allows for one single file libN.a containing
47 Shared Objects, which can be statically linked too!
48
49 And for winnt I've yet to decide the value for $(get_libname) as the Import Library:
50 Candidates are ".so", ".dll.a", ".dll.lib" - as I do support all of them in the msvc
51 wrapper ("parity") to reduce the need of patching various build systems for now...
52
53 So probably the real safe one here is (in case get_libname may return ".a"):
54
55 use static-libs || find "${ED}"/usr/ -name '*.a' -not -name '*.dll.a' -not -name "*$(get_libname)" -delete
56
57 OR: Really have some function prune_static_libs to remove library files serving as
58 Static Library only - neither as Import Library nor Shared Library: Implemented
59 for some platforms to ignore the file name but inspect the content instead.
60
61 Remember: This is (related but) different from prune_libtool_libs,
62 which suggests the find "${D}" -name '*.la' -delete alternative only.
63
64 /haubi/

Replies