Regole del forum
1) Specificare nome e versione del porting.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
aLvArO ha scritto:...
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:
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.
conraid ha scritto:...
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.
Ultima modifica di 414N il ven 12 dic 2008, 11:55, modificato 1 volta in totale.
414N ha scritto:...
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
Offtopic:impostare nome del pacchetto
Offtopic:impostare il sorgente
Offtopic:individuare l'architettura e conseguenze (vedi flag e lib)
Offtopic:estrazione dei sorgenti
Offtopic:compilazione (incluso anche la configurazione e patch)
Offtopic:strip dei binari
Offtopic:compressione delle pagine man
Offtopic:sistemazione delle pagine man e delle pagine doc nelle giuste directory per slackware
Offtopic:aggiunta delle informazioni (vedi file AUTHOR etc...)
Offtopic:copia dello slack-desc ed eventuale doinst.sh
Offtopic:creazione del pacchetto
Offtopic:finalizzazione (eliminare temporanei, spostare il pacchetto creato etc...
Offtopic: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
Offtopic:installazione di patch eventuali
Offtopic:esecuzione del configure o chi per lui
Offtopic:esecuzione del make o chi per lui
Offtopic:esecuzione del make install o chi per lui
Offtopic:e di più, se il pacchetto dei sorgenti viene riconosciuto costruito con gli GNU Autotools, allora il tutto si ridurrebbe ad un file contente
Offtopic:applicazione di eventuali patch
Offtopic:lista dei parametri per il configure
Offtopic:dove la lista potrebbe escludere i parametri classici del configure (vedi --profile,etc...).
Spina
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
#
# 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ì...)
Ultima modifica di gigiobagiano il ven 12 dic 2008, 12:47, modificato 1 volta in totale.
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
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
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
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
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...
riotten ha scritto: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?
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!?!
"Stat rosa pristina nomina, nomina nuda tenemus." [ Umberto Eco - Il nome della rosa]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
Vito ha scritto: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 ha scritto: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!
"Stat rosa pristina nomina, nomina nuda tenemus." [ Umberto Eco - Il nome della rosa]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
. Un giro sulle opzioni però fattelo uguale...almeno per quelle che conosci.
