PLD CVS: SPECS kloczek

[Tomasz Kłoczko]

On Sun, 6 Jun 1999, Martin Dalecki wrote:
[..]
> Mogę się wypowiedzieć tylko na temat separowania debug-info do
> oddzielnych plików.
> Z tego co wiem to po prostu taka możliwość nie istnieje w binutils i
> koniec.
> Pomysł ten też nie jest tak cacy jak by się mogło wydawać bo powstaje
> problem gwarancji zgodności pomiędzy biblioteką a jej symbolami. Radzę
> spytać się kolegów piszących oprogramowanie pod Win jak fajnie to tam
> działa.

Tutaj byłoby to o tyle łatwiejsze, że soft byłby rozprowadzany w
pakietach. Przez to już utrymanie integralności liba i debug ingfo do
niego byłoby zapewn o jakiś rząd wielkości łatwiejsze.

IMHO jednak po mimo wszystko powinniśmy mieć jednak debyug info w libach
statycznych. Niektóre biblioteki kompilują się pieruńsko długo. tak
wystarczyłoby doinstalować odpowiednie static i przekompilować podejrzany
program. Wszystko tu się dość szybkko nadal zmienia. Niektóre liby są
nadal w trakcie permanentnych zmian i pewności nie można mieć czy właśnie
coś nie tak jest w programie jakie się pisze czy testuje (wyszła nowa
wersja) czy w libie który ten program używa. Do libów z taką etykietką
constantly in progres można zaliczyć choćby glibc czy wiekszość libów
X toolkitów (w zasadzie chyba nawet wszystkie, a wiadomo że lada moment
wejdzie XFree 4.0 gdzie zmiany bedą conajmnije poważne czyli nawet lib Xt 
może byc z błedami).

To jest jeden argument za podejścieme zwiazanym z pakowaniem debug info w
static pakiety. Drugi jest taki, że jeżeli nawet tego mało kto będzie
używał to koszt jest włąśnie IMHO nieporównywal;nie niski w przypadku
kilku pakietów static jakie trzeba mieć żeby przekompilować dowolny inny
pakiet (glibc-static, zlib-static, bzip2-static, gdbm-static i chyba
ncurses-static) co obciąża dodatkowo taki devel system jakimiś dodatkow 10
do 20MB zajętości. Podkreślić trzeba, że jest to dość nietypowa stacja
do develepmentu. Założyć mogę chyba tu, że będzie to dość podobne do tego
co mam u siebie obecnie gdzie mam zainstalowanych ponad 700 pakietów i
dołożenie owych 10-20MB to jest kropla w rozmiarach tego co i tak już taki
system zajmuje.

IMHO decydujący jest tu rachunek kosztów i zysków. Kosztem jest owe
10-20MB dodatkowej zajętości systemu. Zyskiem szybkość pozyskania zasobów
z pełnym debug info bez konieczności rekompilacji wszystkich podejrzanyc
komponentów.

W kwesti powyższego w dyskusji bezpośredniej udało mi się przekonać Wojtka
i Artura o tym że to warto, a kwestia tylko na końcu dyskusji była taka,
że ja byłem za tym żeby w konkretnych pakietach generujących liby
statyczne wymusić na stałe dodawanie -g do np. CFLAGS, a Wojtej i po
części Artur byli za tym żeby globalnie dodać w rpmrc -g. To drugie
podejście nie miało by wpływu na objętość i zawartość pakietów z innymi
binariami niż liby statyczne (przeważnie wszystko i tak jest linkowane z
-s i dodatkowo liby shared są stripowane) co moim zdaniem było już za
dużym kosztem gdyż jak pokazują wyniki testów jakie wykonał Artur
kompilacja każdego pakietu wydłuży się przez to w okolicach 5% do najwyżej
10%.

Wiem dlaczego Wojtek jest za takim podejściem .. chodzi o to żeby można
było się łatwo pozbyć debug info w static libach, a IMHO nie należy
właśnie do takiej sytuacji doprowadzać na stałe umieszczając -g
bezpośrednio w konkretnych specach.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*