Pagina 1 di 2

[testdisk.SlackBuild] Problemi nella pacchettizzazione!

Inviato: sab gen 20, 2007 12:43
da pumax
Ciao ragazzi... ieri avendo qualche minuto libero ho deciso di informarmi sulla pacchettizzazione tramite SlackBuild. Ho letto l'apposita sezione su S4d e provando con il pacchetto testdisk ho avuto qualche errore.

Prima di tutto vi incollo il testdisk.SlackBuild:

Codice: Seleziona tutto

#!/bin/sh

CWD=`pwd`
if ["$TMP" = ""]; then
TMP=/tmp/pkg
fi
PKG=$TMP/testdisk

NAME=testdisk
VERSION=6.5
ARCH=i486
BUILD=1

if [ ! -d $TMP ]; then
mkdir -p $PKG
fi

echo "+-----------------------------------+"
echo "|  Start SlackBuild $NAME-$VERSION  |"
echo "+-----------------------------------+"

cd $TMP
tar xjvf $CWD/$NAME-$VERSION.tar.bz2

cd $NAME-$VERSION
chown -R root.root .
find . -perm 775 -exec chmod 755 '{}' \;
find . -perm 664 -exec chmod 644 '{}' \;

CFLAGS="-O2 -march=i486 -mtune=i686" ./configure --prefix=/usr \
                                                 --disable-debug \
                                                 --sysconfdir=/etc \
                                                 --localstatedir=/var

make

make install DESTDIR=$PKG

mkdir -p $PKG/usr/doc/$NAME-$VERSION
cp -a \
AUTHORS COPYING ChangeLog INFO INSTALL NEWS README THANKS \
$PKG/usr/doc/$NAME-$VERSION

( cd $PKG
find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | \
xargs strip --strip-unneeded 2> /dev/null
find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | \
xargs strip --strip-unneeded 2> /dev/null
find . -type f -name "*.a" | xargs file | grep archive | cut -f 1 -d : | \
xargs strip --strip-unneeded 2> /dev/null
)

gzip -9 $PKG/usr/man/*/*
gzip -9 $PKG/usr/info/*

chown -R root.root $PKG/usr/bin

mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc

cd $PKG
makepkg -l y -c n $TMP/$NAME-$VERSION-$ARCH-$BUILD.tgz

if [ "$1" = "--cleanup" ]; then
rm -rf $TMP/$NAME-$VERSION
rm -rf $PKG
fi



Ed infine ecco l'errore restituito:

hdaccess.c: In function `disk_get_geometry':
hdaccess.c:983: error: `u64' undeclared (first use in this function)
hdaccess.c:983: error: (Each undeclared identifier is reported only once
hdaccess.c:983: error: for each function it appears in.)
hdaccess.c: In function `file_read':
hdaccess.c:1292: warning: comparison between signed and unsigned
hdaccess.c: In function `file_write':
hdaccess.c:1356: warning: comparison between signed and unsigned
hdaccess.c: At top level:
hdaccess.c:1366: warning: unused parameter 'nom_buffer'
hdaccess.c: In function `file_test_availability':
hdaccess.c:1617: warning: passing arg 1 of `free' discards qualifiers from pointer target type
make[2]: *** [hdaccess.o] Error 1
make[2]: Leaving directory `/tmp/pkg/testdisk-6.5/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/pkg/testdisk-6.5'
make: *** [all] Error 2
Making install in src
make[1]: Entering directory `/tmp/pkg/testdisk-6.5/src'
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -march=i486 -mtune=i686 -Wall -MD -Wpointer-arith -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wshadow -Wwrite-strings -W -Wcast-align -Waggregate-return -Wbad-function-cast -Wcast-qual -Wundef -Wredundant-decls -Wsign-compare -Wnested-externs -Winline -Wdeclaration-after-statement -MT hdaccess.o -MD -MP -MF ".deps/hdaccess.Tpo" -c -o hdaccess.o hdaccess.c; \
then mv -f ".deps/hdaccess.Tpo" ".deps/hdaccess.Po"; else rm -f ".deps/hdaccess.Tpo"; exit 1; fi
hdaccess.c: In function `disk_get_geometry':
hdaccess.c:983: error: `u64' undeclared (first use in this function)
hdaccess.c:983: error: (Each undeclared identifier is reported only once
hdaccess.c:983: error: for each function it appears in.)
hdaccess.c: In function `file_read':
hdaccess.c:1292: warning: comparison between signed and unsigned
hdaccess.c: In function `file_write':
hdaccess.c:1356: warning: comparison between signed and unsigned
hdaccess.c: At top level:
hdaccess.c:1366: warning: unused parameter 'nom_buffer'
hdaccess.c: In function `file_test_availability':
hdaccess.c:1617: warning: passing arg 1 of `free' discards qualifiers from pointer target type
make[1]: *** [hdaccess.o] Error 1
make[1]: Leaving directory `/tmp/pkg/testdisk-6.5/src'
make: *** [install-recursive] Error 1
Usage: file [-bcikLhnNsvz] [-f namefile] [-F separator] [-m magicfiles] file...
file -C -m magicfiles


Naturalmente il processo va avanti, ma poi nel pacchetto chiaramente non ho nessun binario.

Se avete idee in proposito scrivete pure, grazie! :)

Cya!

P.S. Mi sembra di aver ricevuto anche un Warning per il CFLAGS -02, del tipo che non era supportato... :? Per quale motivo?

Inviato: sab gen 20, 2007 13:14
da gioco
Ho scaricato i sorgenti di testdisk 6.5. Io nel file src/hdaccess.c alla riga 983 non ho nessuna variabile u64, ma longsectors64. Il problema però potrebbe essere causato dalla macro BLKGETSIZE64, di cui non ho trovato la definizione nei sorgenti. Sei certo di non aver ricevuto warnings o errori dal configure? Ha tanto l'aria di essere causato da un tipo di dato non definito.

Inviato: sab gen 20, 2007 13:33
da gohanz
Quel tipo di errore BLKGETSIZE64 lo puoi risolvere usando gli header del kernel 2.6

Inviato: sab gen 20, 2007 13:58
da pumax
gioco ha scritto:Sei certo di non aver ricevuto warnings o errori dal configure? Ha tanto l'aria di essere causato da un tipo di dato non definito.

Ho ricontrollato e se non mi è sfuggito altro mi avvisa solo del fatto che non trova le librerie per reiserfs. :-k Può essere causato dal fatto che io abbia il supporto reiserfs built-in anzichè modulare? O devo scaricare librerie apposite?

@gohanz: Dunque devo aggiungere qualche opzione nel configure?

Per quanto riguarda la CFLAGS -02 da cosa può dipendere?

Cya e grazie per le risposte! ;)

Inviato: sab gen 20, 2007 14:00
da submax82
no devi installare le headers del 2.6

Inviato: sab gen 20, 2007 18:45
da pumax
submax82 ha scritto:no devi installare le headers del 2.6

Uso kernel vanilla, quindi già ci sono.

Inviato: sab gen 20, 2007 20:41
da gohanz
Sei hai solo fatto la compilazione classica del kernel, gli header sono quelli del 2.4.
Per usare quelli del 2.6 li devi copiare a manetta da /usr/src/linux-2.6.*/include/linux in /usr/include/linux2.6

Poi crei un link simbolico linux che punti alla directory degli header.

cd /usr/include
rm linux
ln -s linux2.6 linux

In questo modo poi ripristinare facilemnte i kernel-headers del 2.4 creando un nuovo simlink verso la directory contente gli header del 2.4

Inviato: dom gen 21, 2007 20:48
da pumax
gohanz ha scritto:Sei hai solo fatto la compilazione classica del kernel, gli header sono quelli del 2.4.
Per usare quelli del 2.6 li devi copiare a manetta da /usr/src/linux-2.6.*/include/linux in /usr/include/linux2.6

Poi crei un link simbolico linux che punti alla directory degli header.

cd /usr/include
rm linux
ln -s linux2.6 linux

In questo modo poi ripristinare facilemnte i kernel-headers del 2.4 creando un nuovo simlink verso la directory contente gli header del 2.4

Capisco, provo così allora. Poi faccio sapere! ;) Grazie mille per ora.

P.S. Se volessi lasciare quelli del 2.6.19.1 avrò problemi con altre compilazioni?

Inviato: dom gen 21, 2007 21:02
da pumax
Perfetto!!! :hello1:
Con gli header del 2.6 ha compilato tutto, tranne qualche warning che c'è stato per variabili non definite, ecc ecc... Insomma, le solite cose. :)

L'unica cosa che non ho capito bene di tutta questa storia è l'implementazione del doinst.sh... Ovvero, perchè a volte è presente e a volte no... E come lo si deve implementare.
Grazie ancora per la disponibilità! :)
Cya

EDIT/
Ho dato di nuovo un'occhiata alla documentazione e da quello che ho capito il doinst.sh lo crea automaticamente il comando makepkg per via dei link simbolici se ce n'è bisogno? E' così?

EDIT2/
Svelato anche l'arcano del -O2 grazie a temuccio che me lo ha fatto notare! :) Avevo scritto zero al posto della O grande... -.-" E dire che lo pure sapevo! LOL!

Inviato: lun gen 22, 2007 9:02
da absinthe
pumax ha scritto:Ho dato di nuovo un'occhiata alla documentazione e da quello che ho capito il doinst.sh lo crea automaticamente il comando makepkg per via dei link simbolici se ce n'è bisogno? E' così?

doinst.sh è uno script che serve per compiere operazioni post installazione. lo crei tu! se necessario vengono creati i link simbolici con i comandi specifici!.
tieni conto che per convenzione, removepkg fa una scansione di tutti i comandi inseriti in doinst.sh e compresi tra le parentesi (di solito sono link simbolici appunto) e elimina i risultati di tali comandi una volta rimosso il pacchetto

M

Inviato: lun gen 22, 2007 13:08
da pumax
Da S4D (Par. 12.2.14):

L’opzione -l y (dove -l significa linkadd e y abbrevia ovviamente «yes») cancella i link simbolici alle librerie. Se infatti esistono dei link simbolici, essi vengono convertiti in uno script generato automaticamente (/install/doinst.sh) che li ricostruisce nel momento dell’installazione del pacchetto.


:?: :?: :?: :?:

Inviato: lun gen 22, 2007 13:18
da gohanz
Vuol dire che i link simbolici creati dal make, vengono convertiti da makepkg, nello script doinst.sh. Che si posizionerà automaticamente nell directory /install del pacchetto .tgz creato.

Basta che guardi all'interno di una directory di compilazione dopo il make e senza aver dato il make install, per vedere che, le librerie in genere, hanno una serie di link simbolici che puntano al binario!

Inviato: mar gen 23, 2007 18:27
da pumax
gohanz ha scritto:Vuol dire che i link simbolici creati dal make, vengono convertiti da makepkg, nello script doinst.sh. Che si posizionerà automaticamente nell directory /install del pacchetto .tgz creato.

Basta che guardi all'interno di una directory di compilazione dopo il make e senza aver dato il make install, per vedere che, le librerie in genere, hanno una serie di link simbolici che puntano al binario!

Per quello dicevo... è creato automaticamente, no?

Inviato: mar gen 23, 2007 18:35
da gohanz
Sono creati in automatico solo i link simbolici, tutti gli altri comandi che si vogliono inserire, devono essere scritti a mano!

Inviato: mar gen 23, 2007 22:14
da pumax
gohanz ha scritto:Sono creati in automatico solo i link simbolici, tutti gli altri comandi che si vogliono inserire, devono essere scritti a mano!

Si si, quello l'avevo intuito. Io dicevo proprio lo script "fisico", perchè con la risposta di absinthe ho avuto dubbi che non fosse così.