/dev/printer i

[Tomasz Wittner]

Dnia pon 12. kwietnia 2004 20:04, Jakub Bogusz napisał:
> Pakiety inne niż dev miały nie dostarczać /dev/*, m.in. ze względu na
> możliwość użycia devfs/udev (drugi powód to konieczność użycia
> fakeroota, ale już nieaktualny).
>
> Inna rzecz, że to /dev/printer w żadnym pakiecie nie będzie działać
> z devfs.
Czyli ew. do przeniesienia do /var/costam?

~/rpm/BUILD/lpr-0.72]$ grep -r "/dev/printer" *
common_source/pathnames.h:#define       _PATH_SOCKETNAME        "/dev/printer"

Druga sprawa - skrypty - obecnie:

%post
/sbin/chkconfig --add lpd
%preun
if [ "$1" = 0 ]; then
        /sbin/chkconfig --del lpd
fi

Czy z jakiegoś powodu "tylko tyle" - tzn. zamiast (+/-):

%post
/sbin/chkconfig --add %{name}
if [ -f /var/lock/subsys/%{name} ]; then
        /etc/rc.d/init.d/%{name} restart 1>&2
else
        echo "Run \"/etc/rc.d/init.d/%{name} start\" to start %{name} daemon."
fi
%preun
if [ "$1" = "0" ]; then
        if [ -f /var/lock/subsys/%{name} ]; then
                /etc/rc.d/init.d/%{name} stop 1>&2
        fi
        /sbin/chkconfig --del %{name}

?
> > 2. Program buduje się w taki sposób:
> > 1). cc -Wall -O2 -march=athlon -I../common_source -I/usr/include/bsd   -c
> > -o displayq.o displayq.c
> >
> > Jaka jest różnica między kompilowaniem za pomocą cc/gcc -march=athlon ...
> > a athlon-pld-linux-gcc -march=athlon ...
> > czy, też athlon-pld-linux-g++ a athlon-pld-linux-c++ czy też c++
> > $ ls -la /usr/bin/*[cg]++
> > -rwxr-xr-x    4 root     root        84844 2004-03-05
> > 05:37 /usr/bin/athlon-pld-linux-c++
> > -rwxr-xr-x    4 root     root        84844 2004-03-05
> > 05:37 /usr/bin/athlon-pld-linux-g++
> > -rwxr-xr-x    4 root     root        84844 2004-03-05 05:37 /usr/bin/c++
> > -rwxr-xr-x    4 root     root        84844 2004-03-05 05:37 /usr/bin/g++
>
>                 ^
>
> > Wygląda na to, że pliki są identyczne.
>
> To jest ten sam plik o różnych nazwach :)
> (aka hardlinki)
Coś podejrzewałem - miałem nadzieję, że mc jakoś je wyróżni, tak jak w 
przypadku dow. symbol. man ls wyjaśnił znaczenie "tej czwórki".

> Przy obecnym pakiecie gcc nie ma funkcjonalnie różnicy.
> Od strony rpm-a jest preferowane używanie %{__cc}, które można sobie
> przedefiniować; w przypadku zakodowanego na twardo "cc" lub "gcc" nie ma
> takiej możliwości.
>
> > 2). athlon-pld-linux-gcc -O2 -Wall -fPIC   -c -o md5.o md5.c
> > (XdeFactor-ng) czy nie powinno być jeszcze -march=athlon ?
>
> Powinno. To jest aktualne? Niedawno poprawiałem parę takich rzeczy w tym
> pakiecie, może nie wszystko wyłapałem.
./builder -a -ba -r  auto-ac-XdeFactor-ng-27022004-2 XdeFactor-ng.spec
# $Revision: 1.31 $, $Date: 2004/04/10 22:48:14 $
[...]
march jest tylko w testach configure - reszta wyglada tak:
athlon-pld-linux-gcc -O2 -Wall -fPIC   -c -o md5.o md5.c
lub tak:
gcc -O2 -Wall `pkg-config gtk+-2.0 --cflags glib-2.0` -fPIC -c 
createInvoicePS.c
IMHO - nie warto tego "pchać" do distro w obecnym stanie. Coś tam robiłem 
miesiąc temu, wyrzuciłem wymaganie odnośnie specjalnych uid/gid - spójrz na 
opcje przy %configure - zlikwidowałem logowanie do /var/log/xdefactor.log , 
ale dałem sobie z tym spokój - komu to potrzebne, niech zrobi "jak należy", 
ale nie pcha na buildery, póki nie będzie się nadawało.
> > Czy, w ogólności, jeżeli cokolwiek się buduje na builderze np. i386 który
> > ma procesor pentium, to czy kompilując i686-pld-linux-gcc albo gcc bez
> > -march=i386 zostanie wygenerowany "dobry" kod dla i386 ?
>
> Brak -march oznacza użycie i386 (AFAIK).
Czyli definiowanie march musi być, żeby pakiet np. i686.rpm nie był w 
rzeczywitości pakietem i386.rpm, z dokładnościa do tego, co napisałeś niżej.
> A czy kod będzie poprawny dla i386 to jeszcze zależy od użytych
> statycznych obiektów (crt*.o, libgcc.a, inne biblioteki statyczne).
-- 
Tomasz Wittner