On 09/13/2011 12:51 AM, Donnie Berkholz wrote:
> On 00:46 Tue 13 Sep , Samuli Suominen wrote:
>>> If I understand correctly, this will break for any packages that
>>> don't use pkg-config to link. The maintainers will manually need to
>>> add pkg-config calls to the ebuilds of anything that could
>>> statically link against a library using only libtool and not
>>> pkg-config. Is that accurate?
>> Yes, seems accurate.
>> I can think of 'export PKG_CONFIG="$($(tc-getPKG_CONFIG) --static)' or
>> something like 'export FOO_LIBS="$($(tc-getPKG_CONFIG) --libs --static
>> foo)"' to accomplish getting static flags from an ebuild using
>> toolchain-funcs.eclass if required.
>> Or they do it like lvm2 and cryptsetup at upstream level and add
>> support for statically linking the tools in the build-system.
>> The .la files are not helping packages not using libtool in any case,
>> for example, those using cmake as build-system.
>> And I've yet to see a real, in portage residing, example of where this
>> would really break anything and when I will, I'll gladly help
>> migrating it to the example mentioned above... Overall, corner cases
>> that can be easily worked around, yet punting the *harmful* .la files.
> That's rather shocking. All it would take is trying to statically build
> a package not using pkg-config that links against anything X11-related
> (since all of them have .pc files).
Those packages that have pkg-config file, like libX11, are meant to be
used through pkg-config, so the bug would be in the package not using
the .pc, not in the package lacking the .la
> It's probably more that "nobody" cares about static building than that
> there aren't packages that would break.
I'm looking forward in catching those packages trying to link statically
to a package providing valid pkg-config file, yet not using it...