Bug 382739 – dev-libs/isl-0.07 installs useless libtool file (.la) with USE=static-libs

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Samuli Suominen (RETIRED) 2011-09-12 19:45:28 UTC]

isl.pc's Libs -line covers everything required for static-linking, although to be exactly correct, it should list -lgmp in Libs.private -line instead of Libs -line, but it still works like this.

So this file should never get installed:

>>> /usr/lib64/libisl.la

[Comment 1 Ryan Hill (RETIRED) 2011-09-13 05:04:10 UTC]

dev-libs/cloog (the only package using isl) doesn't use pkgconfig.  Is it still safe to remove it?

[Comment 2 Samuli Suominen (RETIRED) 2011-09-13 06:55:33 UTC]

(In reply to comment #1)
> dev-libs/cloog (the only package using isl) doesn't use pkgconfig.  Is it still
> safe to remove it?

yes, it's safe:

dev-libs/cloog doesn't use dev-libs/isl[static-libs].   it doesn't use the libisl.a, only the libisl.so, thus it gains everything it needs for linking from the NEEDED entries itself.

in fact, whole USE=static-libs looks redudant in isl, i'd rather put the USE flag in packages that really need it, not just for "fun" as it seems to be the case here.

and in case cloog, or some other package not using pkg-config, needs to statically link to it, there are numerous workaround we can apply ebuild -wise to get the linker flags from the pkg-config file such as:

export PKG_CONFIG="pkg-config --static"
or
export ISL_LIBS="pkg-config --libs --static isl"
or
...

in any case, keeping the .la file isn't the solution, as the package would be still broken for non-libtool using packages, in state of inconsitency.

[Comment 3 SpanKY 2011-09-13 14:22:56 UTC]

obviously no one should ever execute `pkg-config` in an ebuild but instead use $(tc-getPKG_CONFIG) ...

as for USE=static-libs, the point isn't whether other ebuilds are using them.  an ebuild providing libraries today has two choices:
 - always provide static and shared libs
 - always provide shared libs and control static libs via IUSE=static-libs

always dropping static libs is unacceptable

[Comment 4 Samuli Suominen (RETIRED) 2011-09-13 14:29:48 UTC]

(In reply to comment #3)
> obviously no one should ever execute `pkg-config` in an ebuild but instead use
> $(tc-getPKG_CONFIG) ...

yeah, need to use toolchain-funcs

> 
> as for USE=static-libs, the point isn't whether other ebuilds are using them. 
> an ebuild providing libraries today has two choices:
>  - always provide static and shared libs
>  - always provide shared libs and control static libs via IUSE=static-libs
> 
> always dropping static libs is unacceptable

perhaps in case of "build static libraries [default=yes]" but not in case of "build static libraries [default=no]"
as in, not everything should provide .a just for the sake of it if nothing needs it, and nobody has requested it for their pet project

(anyway, the .la file can still go...)

[Comment 5 SpanKY 2011-09-13 15:01:05 UTC]

i disagree.  ive seen projects that default to no static libs but people wanted.  further, following upstream's most likely arbitrary choice should not filter into our ebuilds and set up a confusing state.

USE=static-libs support in the ebuild is cheap if not free in the case of autotools-utils.eclass.  because you dont need the static libs doesnt mean they shouldnt be available for the random person who does.

[Comment 6 Michał Górny 2011-09-18 15:07:32 UTC]

 * Removing unnecessary /usr/lib64/libisl.la (covered by .pc)

[Comment 7 Michał Górny 2011-09-18 15:08:02 UTC]

Also, please consider dropping USE=static-libs if not really requested by anyone.

[Comment 8 SpanKY 2011-09-18 19:04:08 UTC]

(In reply to comment #7)

you either didnt see my comments or ignored them, but doing that is an unacceptable policy violation