troche zmieszany ..
Tomasz Kłoczko
kloczek w rudy.mif.pg.gda.pl
Sob, 26 Paź 2002, 00:23:41 CEST
jestem, bo właśnie wywszło że zrobiłem coś co wydawać by się mogło że
jest źle, a to coś i tak dział dobrze :_>
Ab owo ..
W kde{base,graphics}.spec wstawiłem:
%define no_install_post_chrpath 0
Makro które na to niby ma reagować wyglada tak:
#%no_install_post_chrpath 1
%__spec_install_post_chrpath {%{!?debug: \
%{!?no_install_post_chrpath: \
%{?verbose:set -x;} \
echo "Remove RPATH from executable binaries and shared object files."; \
filelist=`find $RPM_BUILD_ROOT -type f ! -regex ".*ld-[0-9.]*so.*"`; \
elfexelist=`echo $filelist | xargs -r file | \
awk '/ELF.*executable/ {print $1}' | cut -d: -f1`; \
elfsharedlist=`echo $filelist | xargs -r file | \
awk '/LF.*shared object/ {print $1}' | cut -d: -f1`; \
if [ -n "$elfexelist$elfsharedlist" ]; then \
chrpath -d $elfexelist $elfsharedlist; \
fi; } \
} }
!?no_install_post_chrpat jeżeli no_install_post_chrpath=0 powinno być
1 czyli że niby chrpath ma się wykonać.
Dotąd byłem przekonany, że %{?<foo>:<bar>} czy %{!?<foo>:<bar>} reaguje na
wartość <foo> a nie na to czy <foo> jest zdefiniowane czy nie bo wychodzi
na to że to właśnie tak działa :>
Sam nie wiem czy to jest błąd czy ficzer. W końcu w bcond to masowo
wykorzystujemy ale wszędzie było to używane z myślą nie o tym czy jest to
zdefiniwane czy nei tylko czy takze ma konktretna wartość i przyu braku
brane było jako wartość "0".
Jeszcze nie wszystkie potrzebne pakiety dostały wyłacznie chrpath i chyba
spróbuję to tym razem ustawioć na .. 1 żeby się pzrekonać jak to jest :_>
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*
Więcej informacji o liście dyskusyjnej pld-devel-pl