SPECS: qt.spec (HEAD)

[Jakub Bogusz]

On Mon, Sep 01, 2003 at 01:45:13PM +0200, Piotr Szymański wrote:
> Hi
> Jakub Bogusz (Monday 01 of September 2003 12:45)
> > Do testów to tak mogło być, ale na produkcję libqt.so.3 oraz statyczne
> > wersje powinny być budowane i dostępne na ftp (przy czym lepiej jako
> > podpakiety, jeśli normalnie tylko libqt-mt jest używane).
> Ok, odwroce bcondy.

Można od razu przejść na nowe - będzie mniej roboty z odwracaniem.

> > Dlaczego? Bo nie można zakładać, że użytkownicy będą używali lub
> > kompilowali wyłącznie oprogramowanie z dystrybucji.
> Wolalbym wymusic zaprzestanie uzywania libqt-st.

Wydzielić libqt.so* do podpakietów qt-st nie wymaganych przez nic
z dystrybucji (i pilnować, żeby ich nikt nie dopisał do BR) - do
wymuszenia w ramach dystrybucji musi wystarczyć.
A poza dystrybucją nic się nie zrobi - dopiero jeżeli qt4 będzie tylko
mt, to st wyjdzie z użycia.


BTW - *.pc i *.la budują się źle (nawet z patchem 10):
W qt-mt.pc jest:
| Libs: -L/usr/lib -l/qt-mt.pc -L/usr/X11R6/lib [...]
                     ^^^^^^^^^ powinno być qt-mt

W libqt-mt.la jest:
| # /libqt-mt.la.la - a libtool library file

| old_library='/libqt-mt.la.a'
(z łatą 10, bez byłoby pewnie '/qt-mt.pc.a')

Patrząc na patcha - lname nie powinno być po prostu kopią fname, coś
jest źle obcinane.


A co do tego QString::arg(long long,...) - relocation error jest przy
próbie użycia uic z 3.2.x z zainstalowanym qt 3.1.x - uic używa tej
funkcji, a w 3.1.x nie było wersji z long long - no i nowe qt nie buduje
się w obecności starego.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/