1 |
On 09/13/2011 12:00 AM, Donnie Berkholz wrote: |
2 |
> On 21:57 Mon 12 Sep , Michał Górny wrote: |
3 |
>> Right now, autotools-utils.eclass punts .la files only with |
4 |
>> USE=-static-libs. We'd like to broaden the range of it and strip .la |
5 |
>> files when they are not necessary for static linkage as well. |
6 |
>> |
7 |
>> The following patch introduces an initial support for that. It assumes |
8 |
>> that the .la file can be removed if the library is mentioned in any of |
9 |
>> pkg-config files installed by the package, or if doesn't specify any |
10 |
>> dependency libs nor linker flags. |
11 |
> |
12 |
> If I understand correctly, this will break for any packages that don't |
13 |
> use pkg-config to link. The maintainers will manually need to add |
14 |
> pkg-config calls to the ebuilds of anything that could statically link |
15 |
> against a library using only libtool and not pkg-config. Is that |
16 |
> accurate? |
17 |
|
18 |
Yes, seems accurate. |
19 |
|
20 |
I can think of 'export PKG_CONFIG="$($(tc-getPKG_CONFIG) --static)' or |
21 |
something like 'export FOO_LIBS="$($(tc-getPKG_CONFIG) --libs --static |
22 |
foo)"' to accomplish getting static flags from an ebuild using |
23 |
toolchain-funcs.eclass if required. |
24 |
|
25 |
Or they do it like lvm2 and cryptsetup at upstream level and add |
26 |
support for statically linking the tools in the build-system. |
27 |
|
28 |
The .la files are not helping packages not using libtool in any case, |
29 |
for example, those using cmake as build-system. |
30 |
|
31 |
And I've yet to see a real, in portage residing, example of where this |
32 |
would really break anything and when I will, I'll gladly help migrating |
33 |
it to the example mentioned above... Overall, corner cases that can be |
34 |
easily worked around, yet punting the *harmful* .la files. |
35 |
|
36 |
- Samuli |