SOURCES: kdelibs-kill_la_loader.patch (NEW) - kill .la loader, use...

[Arkadiusz Miskiewicz]

On Sunday 17 December 2006 12:34, Paweł Sikora wrote:

> > (np. la w /usr/lib/kde3/ mogą spokojnie zostać).
>
> nie moga, prosty przyklad: /usr/lib64/kde3/kio_http.la
>
> # Libraries that this one depends upon.
> dependency_libs=' -L/usr/lib64 /usr/lib64/libgssapi.la
[...]
> wiesz ile paczek -devel rpm zaciagnie nie-deweloperowi przez te wpisy?

Można by globalnie rpmowi przetłumaczyć by tam nie zerkał i interesował się 
jedynie /lib{,64}/*.la oraz /usr/lib{,64}/*.la.

> zrobilem testy i widze, ze wywalenie plikow .la z paczek tez ma wady.

Co znaczy ,,wywalenie'' ? Przecież robimy mv *.la do -devel, a nie wywalamy 
(jak już loader z kdelibs będzie bez .la pracował).

> [1] w autotools-ach trzeba poprawiac detekcje kde ( do tej pory sprawdzaly
>     np. obecnosc *.h i kde*.la )

> [2] nie wszystkie komponenty kde sa w pelni zlinkowane i wywalenie ich *.la
>     ( w ktorych siedza zalezne biblioteki ) bedzie powodowac tony
>     nierozwiazanych symboli, co widac juz przy budowaniu kdebase.
Ułć. Niedobrze - to jest największy problem w takim przypadku.

> jesli natomiast pozostaniemy przy .la i nowym wynalazku rpm-a, to w
> zasadzie kazda aplikacja oparta o kdelibs bedzie musiala miec _noautoreq
> libtool(.*).
Nie każda tylko ta, która ma pliki *.la w pakietach innych niż -devel.

> w takiej sytuacji sklaniam sie ku wylaczeniu libtool(*) w rpm-ie.
Bez sensu. Już lepiej generować takich zależności globalnie jeśli 
podpaczka != -devel.

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/