porting di slack a 64 bit

[targzeta]

...
p.s. potrei usare il config del mio attuale kernel slack?

In generale no, come ben sai, a seconda di come sono impostati i flag, nel menù del kernel possono o meno comparire altre opzioni. Per esempio, le famiglie del processore tra le quali posso scegliere io sono:

Codice: Seleziona tutto

Opteron/Athlon64/Hammer/K8
Intel P4 / older Netburst based Xeon
Core 2/newer Xeon
Generic-x86-64

che non sono certo quelle che puoi scegliere su slackware. Però potresti usarlo come punto di partenza lanciando un:

Codice: Seleziona tutto

make oldconfig

ed incrociando le dita . Un giro sulle opzioni però fattelo uguale...almeno per quelle che conosci.

In bocca al lupo,
Spina

[danix]

stavo provando a cercare una iso della slamd64 ma non ne ho trovate... nei mirror segnalati sul sito ufficiale c'è solo il directory tree...

mi passate qualche script per scaricare tutto il necessario...


Grazie mille

[aLvArO]

Grazie delle informazioni.
Comunque un make oldconfig e successivo controllo era scontato, lo faccio sempre anche su slack quando cambio kernel.
Danix forse ho capito male.
ma che link intendi? http://mirrors-sanfrancisco.hostgis.com ... .1-dvd.iso
io ho provato il primo che mi è capitato e funziona.

[danix]

grazie alvaro, non avevo visto tutti i mirror, ho provato uno inglese e non aveva le iso...

metto in download, così la provo e appena esce la 12.2 vediamo cosa fare del discorso repository...

[aLvArO]

Onestamente mi attira di più la bluewhite64.
appena esce la 12.2 un pensierino glielo faccio.

[414N]

...
Cosa serve per farlo?
Visto che ci sono le linee guida, tra cui usare requirebuilder, possiamo inserirci di mettere un ARCH per x86_64 obbligatoriamente, ma serve altro?

Oltre alle opzioni per il compilatore, andrebbero parametrizzate anche le directory di destinazione per le librerie. Nelle le distro a 64bit andrebbero messe sotto '/lib64' o '/usr/lib64'.

Ovviamente ci sarebbero delle eccezioni, dei casi particolari, ma in generale molti pacchetti non presenti sulle distribuzioni potrebbero tranquillamente essere compilati. Il punto è che se non si incontrano dei problemi è impossibile risolverli, finché si rimane sul vago tutto va bene, però se vogliamo, e ripeto, se vogliamo (non è mica detto che bisogna farlo per forza), le cose si potrebbero fare.

Spina

Mi associo. Sladrazzo (per lo più da slackbuilds.org)/creo slackbuild per Slamd64 che uso regolarmente e la stragrande maggioranza delle volte si tratta solo di aggiungere o impostare ARCH a x86_64, i CFLAGS a "-O2 -fPIC" (anche se spesso uso i mei flag personalizzati) e la libdir a /usr/"$LIBSUFFIX" (ovviamente impostando la variabile LIBSUFFIX nell'if/switch riguardante le CFLAGS in base all'ARCH).
Devo però dire che Slamd64 ha una "bazza" in più rispetto a Slackware: i pkghelpers. Sono degli script (che si potrebbero installare tranquillamente anche su una Slackware) che tolgono l'onere di dover aggiungere agli Slackbuilds ogni volta le parti riguardanti la modifica dei permessi, lo strip dei binari, l'impostazione di LIBSUFFIX e delle altre varie variabili temporanee etc.
Se guardate nella directory source/ della slamd64, noterete che molti Slackbuild si chiamano PHBuild, proprio perché sfruttano questo sistema.

[targzeta]

...
Devo però dire che Slamd64 ha una "bazza" in più rispetto a Slackware: i pkghelpers. Sono degli script (che si potrebbero installare tranquillamente anche su una Slackware) che tolgono l'onere di dover aggiungere agli Slackbuilds ogni volta le parti riguardanti la modifica dei permessi, lo strip dei binari, l'impostazione di LIBSUFFIX e delle altre varie variabili temporanee etc.
Se guardate nella directory source/ della slamd64, noterete che molti Slackbuild si chiamano PHBuild, proprio perché sfruttano questo sistema...

Offtopic: Lo sai che non avevo mai associato PH a PackageHelpers , e mi sono sempre chiesto che significasse, nonstante avevo notato l'uso di questo "tool".
L'idea di usare PH non dispiace, infatti sono convinto che ci sia troppa ridondanza negli SlackBuild. Se ci pensate un attimo gli SlackBuild possono essere divisi in fasi

• impostare nome del pacchetto
• impostare il sorgente
• individuare l'architettura e conseguenze (vedi flag e lib)
• estrazione dei sorgenti
• compilazione (incluso anche la configurazione e patch)
• strip dei binari
• compressione delle pagine man
• sistemazione delle pagine man e delle pagine doc nelle giuste directory per slackware
• aggiunta delle informazioni (vedi file AUTHOR etc...)
• copia dello slack-desc ed eventuale doinst.sh
• creazione del pacchetto
• finalizzazione (eliminare temporanei, spostare il pacchetto creato etc...

Bene, a parte la fase di compilazione del binario tutto il resto può essere automatizzato IMHO, in pratica lo slackbuild potrebbe ridursi ad un file contenente

• installazione di patch eventuali
• esecuzione del configure o chi per lui
• esecuzione del make o chi per lui
• esecuzione del make install o chi per lui

e di più, se il pacchetto dei sorgenti viene riconosciuto costruito con gli GNU Autotools, allora il tutto si ridurrebbe ad un file contente

• applicazione di eventuali patch
• lista dei parametri per il configure

dove la lista potrebbe escludere i parametri classici del configure (vedi --profile,etc...).

Spina

[gigiobagiano]

@Spina controlla anche tu qui trovi il file di configurazione del kernel huge.s (bw64 12.1) troverai l'informazione che ti dicevo:

Codice: Seleziona tutto

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y


Cioè supporta di default le applicazioni a 32 bit. Nel forum non si capisce mai il tono con cui si dicono le cose, non volevo nè offenderti nè fare il saccente , scusami se ho dato quest'impressione (dal tuo messaggio mi è sembrato così...)

[targzeta]

Nono, non ti preoccupare assolutamente gigiobagiano, non sei sembrato né l'uno né l'altro. Sono sicuro che tu abbia ragione, forse il post che ho linkato io si riferiva a versioni vecchie della bluewhite, come ho detto non usandola non sono sicuro di quello che dico in merito, erano solo ricordi di discussioni. Come puoi notare c'è una discrepanza tra quello che hai scritto tu ora e quello che ho linkato io. Nel mio link si dice che la bluewhite non ha abilitato di default l'emulazione per gli eseguibili a 32bit, mentre tu hai dimostrato il contrario, quindi delle due l'una

• il mio post si riferiva a versioni precedenti della bluewhite
• l'autore si era confuso

però penso che sia più la prima che la seconda. Tu che dici? Da quando usi la bluewhite (se la usi) è sempre stata abilitata l'emulazione per il codice a 32bit?
E ancora, visto che l'emulazione è abilitata, perchè si dice che la bluewhite64 è a 64bit pura mentre la Slamd64 no?

Spina

[targzeta]

Faccio un aggiunta. Seguendo il link che hai postato, ho scoperto che solo il kernel genric della bluewhite64 v.11 non ha l'emulazione inpostata, laddove tutti gli huge della 12 e 12.1 invece ce l'hanno. Può essere quindi che l'autore del thread si riferisse a quel kernel.
La domanda però rimane, come mai si dice che la Bluewhite64 è una distro pura a 64bit mentre la Slamd64 no?

Spina

[gigiobagiano]

Ho usato bluewhite per un buon periodo, poi sono troppo pigro con gli aggiornamenti e ho messo su una gentoo sempre amd64. ...Mi hai preceduto, in effetti nella 11 non mi sembrava ci fosse ed era necessaria una ricompilazione...
Guarda sono abbastanza ignorante in materia di "purezza" ma credo che si riferisca all'uso differente del link *lib, una punta a quelle a 32 mentre l'altra a quelle a 64, ma ripeto sono solo mie supposizioni. Slamd64 è strana in questo, perchè tra tutte le distro che ho provato (gentoo, mandriva, ubuntu, debian,fedora e qualche altra) è l'unica che usa lib->lib32...mah... stringi stringi la differenza pare più formale che altro, forse è più comodo per l'installazione di pacchetti a 32bit, visto che praticamente non serve modificare lo SB...

[AleLinuxBSD]

uso slamd64 12.0 in testuale, per cui ti posso dire che è tale e quale alla Slackware x86, l'unico "difetto" è che devi ricompilarti da solo i pacchetti

Perché non esiste un repository con binari precompilati?

[Vito]

Ho letto solo adesso la discussione...ma alla fin fine i vantagi di passare ad una distribuzione a 64bit come Slamd64 o BlueWhite64 sono evidenti!?!?Conviene!?!

[danix]

Ho letto solo adesso la discussione...ma alla fin fine i vantagi di passare ad una distribuzione a 64bit come Slamd64 o BlueWhite64 sono evidenti!?!?Conviene!?!

In poche parole se non hai problemi a crearti i pacchetti di cui hai bisogno e che non trovi SI!! Io mi sto trovando egregiamente...

[Vito]

Ho letto solo adesso la discussione...ma alla fin fine i vantagi di passare ad una distribuzione a 64bit come Slamd64 o BlueWhite64 sono evidenti!?!?Conviene!?!

In poche parole se non hai problemi a crearti i pacchetti di cui hai bisogno e che non trovi SI!! Io mi sto trovando egregiamente...

È quello il problema...chi ha il tempo di compilare i pacchetti!