slacky.eu

Sto pacchettizzando openjdk usando, per ora lo slackbuild di alienbob.
Come specificato dal readme, openjdk 7 andrebbe compilato usando come compilatore "openjdk 7". In alternativa (dal momento che se sto compilando openjdk 7 si presume che openjdk 7 non ce l'ho ) si può usare la modalità "bootstrap", ovvero utilizzare gcc-java (che se non erro equivale ad una jdk 1.5).

Ora mi chiedo, ma indipendentemente dal modo in cui viene compilato, il risultato è lo stesso? oppure è oppportuno compilare usando gcc-java, installarlo e poi ri-compilarlo usando openjdk 7? che differenze si possono trovare?


Altra cosa.
Alien dice, nel readme, che la compilazione richiede
* apache-ant
* rhino
* xalan
* xerces
e che dopo la compilazione è possibile eliminarli tutti tranne rhino.
Però:
1) ho compilato senza xalan e non mi ha dato errore (il configure non mi dava problemi neanche senza xerces, ma non ho dato il make). Che differenze posso trovare?
2) apache-ant è richiesto da rhino. Come posso eliminarlo? o, anche per rhino, è necessario solo per compilarlo?

ZeroUno ha scritto:Ora mi chiedo, ma indipendentemente dal modo in cui viene compilato, il risultato è lo stesso? oppure è oppportuno compilare usando gcc-java, installarlo e poi ri-compilarlo usando openjdk 7? che differenze si possono trovare?

nessuna differenza.
partendo dal presupposto che java è un linguaggio pseudocompilato, ovvero la compilazione produce un bytecode che viene capito da tutte le jvm in circolazione non ci sono differenze.

tecnicamente puoi bootstrappare(io con la 6 una volta ho utilizzato la jdk della sun) con una qualunque jvm perchè il bootstrap se non erro non fa altro che generare i compilatori iniziali perchè comunque a parte hotspot(la virtual machine) e qualche altra cosetta tutto il resto è java quindi ti serve un ambiente 'iniziale'. il prodotto finale pero' è sempre lo stesso.

il fatto che ti 'consiglia' di usare una pari versione dipende dal fatto che ogni major release introduce alle volte dei costrutti del linguaggio che una versione precedente nn comprende (tipo la 7 introduce molti aspetti legati alla programmazione funzionale che la 5 per esempio nn riuscirebbe a compilare)

ZeroUno ha scritto:1) ho compilato senza xalan e non mi ha dato errore (il configure non mi dava problemi neanche senza xerces, ma non ho dato il make). Che differenze posso trovare?

queste librerie sono per il supporto all'xml, l'openjdk 6 le richiedeva, probabilmente ora nn servono piu'

ZeroUno ha scritto:2) apache-ant è richiesto da rhino. Come posso eliminarlo? o, anche per rhino, è necessario solo per compilarlo?

da quel che so io al limite dovrebbe essere il contrario, rhino è un motore javascript scritto in java (serve perchè le librerie grafiche java hanno un componente browser) che non ha dipendenze particolari (a parte ovviamente la jdk stessa). tra l'altro lo stesso alienbob mi pare che nn lo compili, ma scarichi il jar dal sito e lo impacchetti ad-hoc.

ultimissima cosa, tieni conto del fatto che se utilizzi gli script di alienbob(ma anche altre distro fanno cosi') non stai compilando la openjdk, passami il termine, ufficiale. ma una versione che si chiama iced-tea che oltre ad utilizzare gli autotools per la compilazione (la versione ufficiale si aggrappa al vecchio make) introduce il plugin da utilizzare nei browser.. quindi per qualunque info fai riferimento al sito del progetto

ZeroUno ha scritto:2) apache-ant è richiesto da rhino. Come posso eliminarlo? o, anche per rhino, è necessario solo per compilarlo?

da quel che so io al limite dovrebbe essere il contrario, rhino è un motore javascript scritto in java (serve perchè le librerie grafiche java hanno un componente browser) che non ha dipendenze particolari (a parte ovviamente la jdk stessa). tra l'altro lo stesso alienbob mi pare che nn lo compili, ma scarichi il jar dal sito e lo impacchetti ad-hoc.

Si, per compilarlo intendevo "creare il pacchetto". Per creare il pacchetto rhino (come anche xerces) è necessario preventivamente installare apache-ant. rhino scrive il file usr/lib64/ant/lib/rhino.jar
se elimino apache-ant il file rimane (e relativo link in usr/share/java), quindi posso eliminare apache-ant al termine della compilazione di openjdk?

ultimissima cosa, tieni conto del fatto che se utilizzi gli script di alienbob(ma anche altre distro fanno cosi') non stai compilando la openjdk, passami il termine, ufficiale. ma una versione che si chiama iced-tea che oltre ad utilizzare gli autotools per la compilazione (la versione ufficiale si aggrappa al vecchio make) introduce il plugin da utilizzare nei browser.. quindi per qualunque info fai riferimento al sito del progetto

si, certo. Se non erro compilandolo con icetea si ottiene un pacchetto più simile possibile a quello di oracle jdk.
Per il plugin del browser mi sembra di capire che vada compilato successivamente con icetea-web (e un altro slackbuild):

Suns's binary distribution of Java (taken over by Oracle) contains a Java web
plugin for mozilla-compatible browsers. This plugin was not open sourced,
so OpenJDK needs a different solution in order to provide a web plugin for Java.
To this purpose, you have to (build and) install the "icedtea-web" package.
First compile and install OpenJDK (you need the openjdk package for this, not
the JRE), then compile icedtea-web. The SlackBuild script plus sources are
in a separate directory. Note that the icedtea-web plugin is not as mature
as the plugin which is shipped with Oracle's binaries.

ZeroUno ha scritto:Si, per compilarlo intendevo "creare il pacchetto". Per creare il pacchetto rhino (come anche xerces) è necessario preventivamente installare apache-ant. rhino scrive il file usr/lib64/ant/lib/rhino.jar
se elimino apache-ant il file rimane (e relativo link in usr/share/java), quindi posso eliminare apache-ant al termine della compilazione di openjdk?

si, anche se io farei il contrario, ovvero mettere il jar fisico nelle share di java e link alla directory ant. in fin dei conti 'legare' rhino ad ant 'serve' solo per utilizzare negli script ant il linguaggio javascript (o comunque i tool messi a disposizione da rhino).

per quanto riguarda il plugin è corretto, tra l'altro la trovo una 'soluzione' migliore rispetto al vecchio bundle che si utilizzava perchè per esempio io che utilizzo java su di un server, del plugin web mi importa poco.

Non riesco a capire, nello sb di alien, questa riga:

la directory jre/lib contiene
fontconfig.Fedora.properties.src
fontconfig.SuSE.properties.src
fontconfig.Ubuntu.properties.src
fontconfig.properties.src

La riga citata equivale a scrivere (elimino i path per comodità):

Secondo te è corretto avere un file di nome
fontconfig..properties.src
in quella directory?
o lo scopo doveva essere sovrascrivere fontconfig.properties.src con quello di Ubuntu ?
in tal caso la riga sarebbe dovuta essere

quei file servono, come avrai capito, ad indicare i font da utilizzare.
cosi' come sono pacchettizzati non funzionano, ma sono da considerare una traccia per distribuzione.
infatti per poter overridare i font è necessario che il file si chiami
quindi senza il .src finale.
percio' di solito in base alla distribuzione si fa ad installazione completata per esempio:
oppure
percio' credo che alienbob si sia sbagliato e che il risultato che volesse ottenere fosse quello di sovrascrivere il file di default con quello di Ubuntu.

EDIT: io li metterei tutti quanti

Il bello è che dalla versione 7 quei file sono diventati praticamente inutili, dato che ora usano fontconfig su Linux...

Altro errore nello slackbuild:
( cd $PKG2/usr/lib${LIBDIRSUFFIX}/java
ln -sf jre jre${VERSION}
) || exit 1

in openjre andrebbe a creare il link
/usr/lib/java/jre1.7.0_5 -> jre
mentre nella jre 1.6 di slackware 13.37 è presente /usr/lib/jre1.6.0_27 -> java
e se nella intestazione mi ci scrivi:
# Symlinks are present in Slackware historically:
allora quello devi creare.

Anche se a mio parere (almeno in jdk) andrebbe installato java in /usr/lib/jdk1.7.0_5 e creato il link java -> jdk1.7.0_5 come è anche in firefox, così posso far coesistere due installazioni di java.
edit: anzi, in /usr/lib/java1.7.0_5 indipendentemente che sia jdk o jre (infatti quest'ultima è in ogni caso sotto $JAVA_HOME/jre)

Eric dice che questa storia del link non è un bug
ma sinceramente non vedo perchè un software dovrebbe cercare la jre dentro
$JAVA_HOME/jre7u5_b21 invece che $JAVA_HOME/jre
Non sono un esperto e quindi accetto qualsiasi smentita, ma che io sappia tutto quello che non è jre/* fa parte di jdk
Che poi perchè un software dovrebbe andarla a cercare PROPRIO in jre7u5_b21 non saprei (nei file di configurazione io ho sempre messo JAVA_HOME == directory precedente alla directory jre, e sinceramente - ma non ho provato - ho anche qualche dubbio che funzioni un software se metto JAVA_HOME=/usr/lib/java/jre/ )

mi state facendo venire un dubbio amletico e una considerazione che non avevo mai fatto in tanti anni che sviluppo in java

che io sappia la variabile JAVA_HOME perlopiu' viene usata per impostare il path dei binari (vedasi i file che stanno sotto /etc/profile.d) e alle volte il classpath.
tutti gli altri casi in cui l'ho vista utilizzata è negli script di avvio che pero' la usano come prefisso del binario tipo
in modo che gli si possa indicare agilmente una jre/jdk differente(da notare che il binario java che sta sia nella jdk che nella jre è identico).

tra l'altro nei sistemi con cui ho a che fare molto spesso viene installata la sola jre visto che la jdk nn serve.

onestamente a memoria non mi viene in mente nessuno script che vada a pescare l'eseguibile sotto JAVA_HOME/jre/bin...ma sicuramente ho la memoria corta

di sicuro c'e' che volendo la jdk si puo' installare nella home e impostando le variabili di ambiente corrette non si nota alcuna differenza, quindi proprio di bug nn si tratta secondo me, ma piu' una questione di gusti o.. come dice alienbob gli sarà capitato uno script che c'aveva st'esigenza particolare.

ZeroUno ha scritto:Come specificato dal readme, openjdk 7 andrebbe compilato usando come compilatore "openjdk 7". In alternativa (dal momento che se sto compilando openjdk 7 si presume che openjdk 7 non ce l'ho ) si può usare la modalità "bootstrap", ovvero utilizzare gcc-java (che se non erro equivale ad una jdk 1.5).

Ora mi chiedo, ma indipendentemente dal modo in cui viene compilato, il risultato è lo stesso? oppure è oppportuno compilare usando gcc-java, installarlo e poi ri-compilarlo usando openjdk 7? che differenze si possono trovare?

Occhio che gcc-java (o gcj) implementa solo Java 1.2 con qualche cosina di Java 1.4 (il supporto alla keyword assert e le inner classes).
Non ho mai provato a compilare un JDK, ma presumo che il bootstrap serva solo a compilare i binari fondamentali (java, javac ecc.) e non tutte le classi del JDK, anche perché sarebbe impossibile.

ZeroUno ha scritto:1) ho compilato senza xalan e non mi ha dato errore (il configure non mi dava problemi neanche senza xerces, ma non ho dato il make). Che differenze posso trovare?

Magari ti mancano dei pezzi di supporto a xml nella jdk bootstrap che hai compilato.

ZeroUno ha scritto:2) apache-ant è richiesto da rhino. Come posso eliminarlo? o, anche per rhino, è necessario solo per compilarlo?

ant lo potresti anche tenere, tanto se installerai altri software java sarà probabilmente richiesto

Da quello che sono riuscito a capire, la versione compilata con bootstrap compila - è vero - solo i binari principali (java, javac ecc.) ma poi usa questi per compilare la versione completa.
Infatti nella directory di icedtea ci si ritrova con openjdk.build-boot e openjdk.build in cui quest'ultima è stata compilata utilizzando la prima.
Che differenze possano esserci compilandone una senza bootstrap non saprei.
Alienbob dice che una volta compilato openjdk con bootstrap andrebbe ri-compilato senza bootstrap. Secondo me no.
Anzi, paradossalmente, da come sono riuscito a ricostruire le cose, quando compilerò openjdk 1.7.0_6 senza bootstrap, ovvero a partire da openjdk 1.7.0_5 allora si, dovrò poi ricompilarlo un'altra volta (o anche in questo caso dovrò compilare con bootstrap anche se a partire da 1.7.0_5?)

Comunque ho appena ricompilato senza bootstrap ed ho visto che l'elenco dei file è identico!


Per quanto riguarda xerces e xalan, noto che sul blog alien non le cita.


edit:
ecco la diff dei due alberi (1=bootstrapped 2=normale)

per quanto riguarda il discorso del bootstrap io sono pro-alienbob nel senso che in linea teorica io posso compilare per esempio gcc 4.7 utilizzando gcc 4.3, pero' l'eseguibile risultante potrebbe non essere ottimizzato come se invece utilizzassi gcc 4.7 per compilare se stesso.. per via di tutte le ottimizzazioni fatte durante il ciclo di aggiornamento di un software.

quindi secondo me una volta creata la 'prima' openjdk andrebbe ricompilata anche perchè con tutto l'impegno messo, gcc-java non è paragonabile come qualità del bytecode generato ad una jdk standard.

ZeroUno ha scritto:Da quello che sono riuscito a capire, la versione compilata con bootstrap compila - è vero - solo i binari principali (java, javac ecc.) ma poi usa questi per compilare la versione completa.
Infatti nella directory di icedtea ci si ritrova con openjdk.build-boot e openjdk.build in cui quest'ultima è stata compilata utilizzando la prima.
Che differenze possano esserci compilandone una senza bootstrap non saprei.
Alienbob dice che una volta compilato openjdk con bootstrap andrebbe ri-compilato senza bootstrap. Secondo me no.
Anzi, paradossalmente, da come sono riuscito a ricostruire le cose, quando compilerò openjdk 1.7.0_6 senza bootstrap, ovvero a partire da openjdk 1.7.0_5 allora si, dovrò poi ricompilarlo un'altra volta (o anche in questo caso dovrò compilare con bootstrap anche se a partire da 1.7.0_5?)

Il bootstrap (nel caso di un compilatore) serve quando il compilatore è scritto nel linguaggio che deve compilare.
Dato che per compilare un compilatore Java scritto in Java (come javac) hai bisogno di un compilatore pre-esistente in grado di compilare correttamente l'intero linguaggio o un suo sottinsieme, ecco che ti serve effettuare il bootstrap.
Ricompilare il compilatore con sé stesso una volta effettuato il bootstrap è un ottimo metodo di testing per il compilatore e, in più, potrebbe introdurre ottimizzazioni dovute alle novità della nuova versione del compilatore e del linguaggio.
Per le versioni successive di JDK7 non ti servirà la fase di bootstrap perché avrai già a disposizione un compilatore idoneo al linguaggio (ovvero Java 1.7).
Quando si passerà a Java 1.8 (tra un annetto circa) allora dovrai effettuare nuovamente un bootstrap.

ZeroUno ha scritto:Per quanto riguarda xerces e xalan, noto che sul blog alien non le cita.

quindi mi confermi che non servono!??!
mi si avvicina il week-end e avendo piu' tempo a disposizione e le ferie ancora lontane vorrei provare a fare i pacchetti per slacky