Ricompilare slackware....

[conraid]

Sì era quello che intendevo per "macello". Il fatto di voler ottimizzare e poi trovarsi con pezzi non ottimizzati!

e va beh, ma in questo caso uno inizia con le glibc, il kernel, guarda quali librerie usa maggiormente, e poi va si seguito... ma serve? io i pacchetti slackware, a parte casi in cui necessito di versioni o configurazioni diverse, non li ricompilo

[lennynero]

Sì era quello che intendevo per "macello". Il fatto di voler ottimizzare e poi trovarsi con pezzi non ottimizzati!

e va beh, ma in questo caso uno inizia con le glibc, il kernel, guarda quali librerie usa maggiormente, e poi va si seguito... ma serve? io i pacchetti slackware, a parte casi in cui necessito di versioni o configurazioni diverse, non li ricompilo

Io qui non sto chiedendo se serve, sto chiedendo se esiste un ordine.

[conraid]

Sì era quello che intendevo per "macello". Il fatto di voler ottimizzare e poi trovarsi con pezzi non ottimizzati!

e va beh, ma in questo caso uno inizia con le glibc, il kernel, guarda quali librerie usa maggiormente, e poi va si seguito... ma serve? io i pacchetti slackware, a parte casi in cui necessito di versioni o configurazioni diverse, non li ricompilo

Io qui non sto chiedendo se serve, sto chiedendo se esiste un ordine.

Sì sì, ho capito, stavo facendo un discorso generale.
Anche se in realtà avevo capito che ti interessasse in primis i 64 bit

L'ordine preciso non te lo so dire

[lennynero]

ho risolto il problema degli headers con --build-sysroot ma ora il problema che mi si presenta durante la compilazione di gcc è il seguente:

Codice: Seleziona tutto

/ccompiler/athlon64/bin/x86_64-pc-linux-gnu-ld: skipping incompatible //usr/lib/libc.so when searching for -lc
/ccompiler/athlon64/bin/x86_64-pc-linux-gnu-ld: skipping incompatible //usr/lib/libc.a when searching for -lc
/ccompiler/athlon64/bin/x86_64-pc-linux-gnu-ld: skipping incompatible //usr/lib/libc.so when searching for -lc
/ccompiler/athlon64/bin/x86_64-pc-linux-gnu-ld: skipping incompatible //usr/lib/libc.a when searching for -lc
/ccompiler/athlon64/bin/x86_64-pc-linux-gnu-ld: cannot find -lc
collect2: ld returned 1 exit status
make[3]: *** [libgcc_s.so] Error 1
make[2]: *** [stmp-multilib] Error 2
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2

lo script che uso per creare il toolchain è il seguente:

Codice: Seleziona tutto

!/bin/sh

start=`date`

bversion=2.17.50.0.17
gmpversion=4.2.4
mpfrversion=2.3.2
gversion=4.2.3
libversion=2.7
target=x86_64-pc-linux-gnu
#target=athlon64-slackware-linux

rootpath=$(pwd)
athlon64=$rootpath/athlon64

rm -r build
mkdir $rootpath/build
rm -r $athlon64
mkdir $athlon64

cd $rootpath/src
rm -r binutils-$bversion gmp-$gmpversion mpfr-$mpfrversion gcc-$gversion glibc-$libversion linuxthreads linuxthreads_db
tar -xvf gcc-$gversion.tar.bz2
tar -xvf gmp-$gmpversion.tar.bz2
tar -xvf mpfr-$mpfrversion.tar.bz2
tar -xvf binutils-$bversion.tar.bz2
tar -xvf glibc-$libversion.tar.bz2
tar -xvf glibc-ports-$libversion.tar.bz2
tar -xvf glibc-linuxthreads-2.5.tar.bz2

#cd /usr/src/linux
#make headers_install INSTALL_HDR_PATH=$athlon64/sysroot/usr/
#cp /usr/include/*.h $athlon64/sysroot/usr/include/

cd $rootpath/build
mkdir binutils-$bversion gmp-$gmpversion mpfr-$mpfrversion gcc-$gversion glibc-$libversion

cd binutils-$bversion
$rootpath/src/binutils-$bversion/configure --prefix=$athlon64 \
   --with-build-sysroot=/ \
   --with-sysroot=$athlon64/sysroot \
        --target=$target
make all && make install

cd ../gmp-$gmpversion
$rootpath/src/gmp-$gmpversion/configure --disable-shared --prefix=$athlon64
make all && make install

cd ../mpfr-$mpfrversion
$rootpath/src/mpfr-$mpfrversion/configure --disable-shared --prefix=$athlon64 \
        --with-gmp=$athlon64
make all && make install

cd ../gcc-$gversion
# Create an incoming directory structure for glibc to be built into:
mkdir -p $athlon64/glibc/lib
mkdir -p $athlon64/glibc/sbin
mkdir -p $athlon64/glibc/usr/bin
mkdir -p $athlon64/glibc/usr/lib
mkdir -p $athlon64/glibc/usr/sbin
mkdir -p $athlon64/glibc/usr/include
mkdir -p $athlon64/glibc/usr/doc
mkdir -p $athlon64/glibc/usr/man
mkdir -p $athlon64/glibc/usr/share
mkdir -p $athlon64/glibc/var/db/nscd
mkdir -p $athlon64/glibc/var/run/nscd

export PATH=$athlon64/bin:$PATH
$rootpath/src/gcc-$gversion/configure --prefix=$athlon64 \
        --with-gmp=$athlon64 \
        --with-mpfr=$athlon64 \
   --with-build-sysroot=/ \
        --target=$target \
        --with-as=$athlon64/bin/$target-as \
        --with-ld=$athlon64/bin/$target-ld \
   --with-sysroot=$athlon64/sysroot
make all && make install

end=`date`
echo -e "$start\n$end"

[lennynero]

Ho abbandonato l'idea di costruirmi una toolchain per compilarmi la slack x athlon64, ora sto provando a ricompilarmi la slack 12.2 per pentium-m; il tanto agognato ordine lo deduco eseguendo pedissequamente gli slackbuilds di PAT(come da sourceroot a ap d ecc...) ovviamente i suddetti slackbuild li modifico opportunamente cambiando l'arch da i486 a pentium-m e passando delle cflags per pentium-m. Il mio environment: mi trovo su una slack 12.1 sul mio notebbok con intel centrino. Iniziano i problemi: il parametro --build che viene passato alla maggior parte del sorgenti è impostato a i486-slackware-linux, io vorrei potergli dire pentium-m-slackware-linux; da quanto ho capito quella dir viene creata dallo slackbuild di binutils, quindi suppongo che non è possibile da slack 12.1 compilarsi la slack 12.2 senza un chroot o addirittura un upgrade dei pacchetti che vengono creati man mano. Vi chiedo: qualcuno ha mai provato a fare una cosa del genere? se per esempio volessi fare un upgrade man mano dovrei compilarmi prima binutils e poi il resto, o ci sono altri pacchetti che hanno la priorità? ma perchè PAT non ha creato uno script che facesse tutto questo lavoro? magari li ha ma non li rende noti per una questione di protezionismo...mha.

ps Mi permetto di dire, analizzando i source, che gli slackbuild a volte si chiamano con nomi strani tipo app.build o addirittura SlackBuild..., a2ps non esegue nessun makepkg, loadlin non ha lo slackbuild, ma per entrambi esistono i rispettivi pacchetti, un pò di confusione, insomma PJV è bravo, ma non ha la classe di PJV