Deutsches Lilypond Forum (Archiv)
Allgemein => Hilfe beim Einstieg in Lilypond => Thema gestartet von: eluze am Samstag, 13. Juli 2013, 11:59
-
ich habe mehrere LilyPond-versionen installiert (unter Windows) und zwar im ordner
c:\Program Files (x86)\
diese heissen lilypond, lilypond2.12.3, lilypond2.13.2 usw. in lilypond ist die jeweils neuste version
der aufruf älterer versionen erfolgt über "c:\program files (x86)\lilypond2.12.3\usr\bin\lilypond.exe"
das programm lymv.bat erleichtert diese eingabe und führt lilypond mit allen vorhandenen versionen aus, die der spezifikation entsprechen.
lymv "c:\program files (x86^)" lilypond 2.17 test.ly
hoffe, das ist nützlich
Eluze
-
Ich benutze seit rund 30 Jahren nur Linux, eine BAT-Datei würde mir nichts nutzen. Dennoch interessiert mich das Thema. Zum Verständnis sei vorangestellt:
/ (slash) ist in Linux das, was bei M$ der back-slash \ ist.
In Linux befinden sich die Libraries in
/usr/local/lilypond/usr/lib
und die Binaries, guile, lilypond, lilypond-book .... und viele mehr in
/usr/local/lilypond/usr/bin/.
Beim Aufruf von lilypond wird ein Shell-Script mit dem Namen lilypond im Verzeichnis /usr/local/bin/lilypond
aufgerufen (ich glaube das Shellscript wird bei der Installation erstellt - oder habe ich da was selbst verändert?) und es werden diese oben aufgelisteten Pfade gesetzt und die Compilation ausgeführt. Das Shellscript:
#!/bin/sh
me=`basename $0`
export LD_LIBRARY_PATH="/usr/local/lilypond/usr/lib"
exec "/usr/local/lilypond/usr/bin/$me" "$@"
Es ist erkennbar, dass dort für den Aufruf einer ganz bestimmten Version die Pfade zu dieser Version unterscheidbar sein müssen.
Man müsste also für verschiedene Versionen diese Verzeichnisse unterscheidbar halten, was in der Standardinstallation (zumindest in Linux) nicht vorgesehen ist. Eine meines Erachtens gute Möglichkeit wäre den Teil des Pfades /usr/local/lilypond mit der Version zu erweitern, z. B zu /usr/local/lilypond/2.16.2/ oder /usr/local/lilypond-2.16.2 schon bei der Installation ändern. Der Aufruf der gewünschten Version von lilypond kann man einfach das jetzt vorhanden Shellscript z. B. in der oben vorgeschlagenen Form
#!/bin/sh
me=`basename $0`
export LD_LIBRARY_PATH="/usr/local/lilypond/2.16.2/usr/lib"
exec "/usr/local/lilypond/2.16.2/usr/bin/$me" "$@"
würde die Version 2.16.2 aufgerufen.
Man könnte zum Testen der Idee versuchen, die Verzeichnisstruktur von Hand solcherart zu ändern, also die Verzeichnisse mit der Version von Hand zu erstellen und dann das Aufrufscript zu ändern. (Das werde ich in den nächsten Tagen mal ausprobieren, muss aber zuerst Anderes fertigstellen. Ich bin aber nicht böse, wenn ein Anderer schneller ist und das vor mir ausprobiert! Wäre dann schön über das Ergebnis und die möglichen Probleme/Fehler zu hören.)
Wenn mehrere Versionen (unterscheidbar) installiert sind, kann man ein Shellscript erstellen, das eben nach Wunsch eine bestimmte oder auch mehrere Versionen aufruft. (Etwa so wie vermutlich Eluze das unter M$ mit seinem batch file macht. Shellscripte sind unter Linux das, was batchfiles unter M$ sind. Beides sind lediglich scripte, also Listen von Befehlen, die nacheinander abgearbeitet werden.)
Soll eine Versionsunterscheidung schon bei der Installation erfolgen, müsste man dazu vermutlich viele Installations-Shell-Scripte, eventuell auch noch make und make install durchdacht ändern, denn - wie sonst? - erfolgt die Installation oder die Compilation unter Linux über Shell-Scripte. Diese Änderung ist sicher möglich, aber ziemlich viel Aufwand bis man das Gesamtsystem von Scripten bug-free hat. Vielleicht können die Experten mit Überblick über den Installationsprozess den Installationsablauf dahin gehend ändern?
Grüße
-
ergänzend dazu sei noch erwähnt wie es unter windows läuft:
defaultmässig wird LilyPond im ordner c:\Program Files (x86)\LilyPond installiert (bei älteren versionen c:\Program Files\. dieser ordner kann jedoch beliebig anders heissen, also z.b. mit der angehängten version-nummer: LilyPond2.17.22 oder "LilyPond 2.17.22" (mit leerzeichen) - alle zu LilyPond gehörenden dateien/programme sind dort enthalten!
LilyPond kreiert dabei einen eintrag im registry, der ermöglicht einfach nur lilypond zu schreiben, um die kompilation anzukicken.
man kann also bei der installation den default beibehalten und jeweils vorher die aktuelle version umbenennen.
ich kann mir nur schwer vorstellen, dass das unter linux oder anderen betriebssystemen so viel komplizierter sein soll!
Eluze
-
Vorsicht: Hab's gerade ausprobiert, gibt noch ein Problem mit der Fehlermeldung
exec: /usr/local/lilypond/usr2.17.21/bin/lilypond2.17.21: not found Es stimmt wohl noch was mit den Pfden nicht ganz!!
Eluze:
... defaultmässig wird LilyPond im ordner c:\Program Files (x86)\LilyPond installiert (bei älteren versionen c:\Program Files\. dieser ordner kann jedoch beliebig anders heissen, also z.b. mit der angehängten version-nummer: LilyPond2.17.22 oder "LilyPond 2.17.22" (mit leerzeichen) - alle zu LilyPond gehörenden dateien/programme sind dort enthalten ...!
So wie Du schreibst, benennst Du ja offenbar die Verzeichnisse von Hand um, ich dachte das passiert bei M$ schon bei der Installation - war wohl falsch gedacht. Schwierig ist wohl nur diese "Versionierung" schon bei der Installation wegen der erforderlichen Änderung im Installationsprozess. (Ich habe ja vermutet, dass das bei M$ erfolgt.)
Du hast praktisch ja das gleiche Umbenennungsschema verweendet, wie ich das vorgeschlagen habe. Allerdings erkenne ich, dass eines der vorgeschlagenen Schemata Probleme machen könnte, nämlich das:
/usr/local/lilypond/2.16.2/Das funktioniert wohl nicht, weil lilypond ja in das Verzeichnis lilypond installiert wird und so wie ich bemerkt habe wird bei der Installation geprüft, ob lilypond schon installiert ist und im positiven Fall erfolgt eine Auffoerderung zur Deinstallation - vermutlich wird dabei geprüft, ob ein Verzeichnis
/usr/local/lilypond/ vorhanden ist. (Probiert habe ich's nicht.)
So sehr viel unterschiedlich ist das bei Linux nicht. Das Verzeichnis /usr/local/lilypond/ kann man natürlich auch unter Linux vor der Installation einer neuen Version zu beispielsweise /usr/local/lilypond2.16.2/ umbenennen. Unter Linux kann man das von der Zeileneingabe so machen:
desktop:~$ sudo mv /usr/local/lilypond/ /usr/local/lilypond2.16.2/Das kann man natürlich auch im Dateibrowser machen. In beiden Fällen sind Administrationsrechte erforderlich. Im Fall der Umbenennung ist die Originaldatie unter dem alten Namen natürlich nicht mehr verfügbar.
Danach muss man noch das alte Lilypond-Aufrufshellscript /usr/local/bin/lilypond zum neuen lilypond-Aufrufshellscript /usr/local/bin/lilypond2.16.2 umbennen und versionieren, also ändern von
#!/bin/sh
me=`basename $0`
export LD_LIBRARY_PATH="/usr/local/lilypond/usr/lib"
exec "/usr/local/lilypond/usr/bin/$me" "$@"
zu
#!/bin/sh
me=`basename $0`
export LD_LIBRARY_PATH="/usr/local/lilypond2.16.2/usr/lib"
exec "/usr/local/lilypond2.16.2/usr/bin/$me" "$@"
Das kann man mit einem einfachen ASCII-Texteditor (keinen Editor zum Briefe schreiben!) vornehmen (z.B. nedit, nano, gedit, pluma. Hardcore-Linuxer nehmen vi, vim oder vim-gnome). Z. B.:
desktop:~$ sudo gedit /usr/local/bin/lilypond
Nach dem Editieren speichern unter lilypond2.16.2 und die datei ausführbar für alle oder den User machen. Z. B.
desktop:~$ sudo chmod a+x /usr/local/bin/lilypond2.16.2
Danch sollte man Version 2.16.2 mittels lilypond2.16.2 aufrufen können.
Eleganter wäre es allerdings das Script so zu erweitern, dass die gewünschte Version als zweiter Parameter zusätzlich zum Namen der ly-Datei beim Aufruf übergeben werden kann. Dann würde die Umbennenung des Aufrufscripts natürlich entfallen können.
Grüße
-
Hm, ich glaub, ich schau mir das nachher auch mal an, vielleicht nehm ich mir auch Zeit und schreib da was einfach zu handhabendes. Bin auch Linux-User (oder laut bblochl „Hardcore-Linuxer“), frage mich aber zwei Sachen: was sind denn vim-gnome und die Option -r bei mv? Letztere konnte ich in der man-page nicht finden …
Edit: mir ist grad noch ein Problem zumindest bei Ubuntu (und debian?) eingefallen: Das Paket frescobaldi hängt ab vom Paket lilypond, d. h. wenn man Frescobaldi installiert, ist automatisch auch ein LilyPond aus den Paketquellen dabei, was einem dazwischenfunkt. Oder kann man apt-get o. ä. beibringen, dass man frescobaldi, nicht aber lilypond installieren will? Oder müsste man dann Frescobaldi auch von Hand installieren?
-
Habe gerade eine Unstimmigkeit entdeckt, die in der internen Verzeichnisstruktur liegt.
Es funktioniert, wenn man usr/local/binlilypond2.16.2 umschriebt:
#!/bin/sh
me=`basename $0`
me="lilypond"
export LD_LIBRARY_PATH="/usr/local/lilypond/usr/lib"
exec "/usr/local/lilypond/usr/bin/$me" "$@"
Das liegt daran, dass me=`basename $0` als Ergebnis lilypond2.16.2 liefertund dann exec zu
/usr/local/lilypond/usr2.17.21/bin/lilypond2.17.21wird (wobei mit $@" noch der Dateiname angehängt wird).
Lilypond heißt aber im Verzeichnis
/usr/local/lilypond2.17.21/usr/bin/einfach lilypond und nicht lilypond2.17.21. Das geht dann schief. "Schuld" daran ist, dass der Verzeichnispfad falsch zusammengesetzt wird. Im Verzeichnis
/usr/local/bin/lilypond
steht der Pfad
/usr/local/bin/lilypond
Bei
/usr/local/bin/lilypond2.16.2
steht aber
/usr/local/bin/lilypond2.16.2
Wenn der Texteintrag von dort in den Pfad übernommen wird, wird also versucht lilypond mittels lilypond2.16.2 statt richtig einfach als lilypond aufzurufen.
Warum der Pfad
/usr/local/bin/lilypond
in einem Verzeichnis
/usr/local/bin/lilypond
gleichen namens steht und übernommen wird, der also eigentlich schon bekannt ist, weiß ich nicht. (Das nennt man wohl Tautologie?) Linuxspezialisten oder besser die lilypond-Spezialisten könne das vielleicht erklären?? Steckt dahinter vielleicht die Idee für einen versionsdefinierten Aufruf?
Aber zunächst funktioniert das immerhin!
Grüße
-
So wie Du schreibst, benennst Du ja offenbar die Verzeichnisse von Hand um, ich dachte das passiert bei M$ schon bei der Installation - war wohl falsch gedacht. Schwierig ist wohl nur diese "Versionierung" schon bei der Installation wegen der erforderlichen Änderung im Installationsprozess. (Ich habe ja vermutet, dass das bei M$ erfolgt.)
das ist einerlei - bei der installation kommt ein prompt, wo du entscheidest, wohin installiert wird. der befehl 'lilypond' verweist dann auf den entsprechenden pfad (der an die path variable angefügt wird - vorsicht wenn die path variable allzu lange wird!)
ich habe mich dafür entschieden, mit lilypond die zuletzt heruntergeladene version anzusprechen und die anderen versionen mit lymv … 2.17 …
aufzurufen. (dabei kann ich den 2. paramter recht frei gestalten oder sogar leerlassen (mit "", wie das bei positionellen parametern üblich ist)
das hilft mir v.a. bei der suche nach dem ersten auftauchen eines fehlers.
sonst verwende ich gerne die neuste version.
es ist natürlich auch möglich alle lilypond-versionen auf einen externen datenträger zu verlegen - mein lymv-programm funktioniert damit genauso gut.
Eluze
-
Zitate von fugenkomponist:
was sind denn vim-gnome ...
Vi IMproved - enhanced vi editor - with GNOME2 GUI
Vim is an almost compatible version of the UNIX editor Vi.
Many new features have been added: multi level undo, syntax
highlighting, command line history, on-line help, filename
completion, block operations, folding, Unicode support, etc.
This package contains a version of vim compiled with a GNOME2 GUI
and support for scripting with Lua, Perl, Python, Ruby, and Tcl.
... und die Option -r bei mv? Letztere konnte ich in der man-page nicht finden …
Gibt's auch nicht, ist ein Fehler. Ich habe nämlich zum Testen nicht mv verwendet, sondern cp um mir das Original zu erhalten und -r ist dann natürlich für rekursives kopieren erforderlich. mv wäre natürlich erforderlich um frei für die Neuinstallation zu machen (vermute ich mal). Werde das korrigieren.
Edit: mir ist grad noch ein Problem zumindest bei Ubuntu (und debian?) eingefallen: Das Paket frescobaldi hängt ab vom Paket lilypond, d. h. wenn man Frescobaldi installiert, ist automatisch auch ein LilyPond aus den Paketquellen dabei, was einem dazwischenfunkt. Oder kann man apt-get o. ä. beibringen, dass man frescobaldi, nicht aber lilypond installieren will? Oder müsste man dann Frescobaldi auch von Hand installieren?
Ich verwende Frescobaldi nicht und kann deshalb dazu nicht viel sagen. Historisch war lilyKDE ein Kate-Plugin für KDE3, Frescobaldi ein Kate-Plugin für KDE4, daran kann's aber wohl nicht liegen? (Kate verwende ich sehr gerne!) Man kann die Paketquellen überlisten, aber man begibt sich dann in die Versionsabhängigkeitshölle! Ich habe es mal vor mehreren Jahren unter Debian für Lazarus gemacht, als dieser nicht weiter unterstützt wurde. Am Anfang lief das noch gut, aber je weiter sich die Pakete auseinanderentwickelten ... endete mit Neuinstallation. Aber das war ein bisschen anders, weil ich ja alte Pakete halten wollte.
Ich habe gerade nachgeschaut, die meisten Paketquellen arbeiten ja noch mit lilypond 2.14.2. Ich könnte mir gut vorstellen, dass so wie hier für Probleme ein ähnliches Problem verschiedener lilypond-Versionen "mit überkreuzten Pfaden" verschiedener Versionen eine Rolle spielen könnte?
Man müsste rausfinden, wie man den lilypond-Aufruf von Frescobaldi ändern kann und diesen dann auf die neue lilypond-Version setzen. Das müsste man bei jedem Update von Fresobaldi vermutlich wiederholen, nachdem lilypond und Frescobaldi über die Paketlisten verknüpft sind.
Ich habe mir gerade mal die Feature-List von Frescobaldi angescchaut:
Use multiple versions of LilyPond, automatically selects the correct version
Da miuss es also was geben.
Grüße
-
Frescobaldi fugenkomponist:
Das Naheliegende fällt mir erst jetzt ein, hast Du schon mal versucht Frescobaldi aus den Quellen zu installierren? Dann nimmt doch vermutlich Frescobaldi die lilypond-Version die Du installiert hast, unabhängig von den Paketverknüfungen des Linux-Brands das Du benutzt. Updaten musst Du dann allerdings selsbt, genau so wie Lilypond, wenn Du eine andere Version als die der Paketliste installierst.
Grüße
-
Zitat von Eluze Heute um 14:03:28
das ist einerlei - bei der installation kommt ein prompt, wo du entscheidest, wohin installiert wird. der befehl 'lilypond' verweist dann auf den entsprechenden pfad (der an die path variable angefügt wird - vorsicht wenn die path variable allzu lange wird!)
Eluze
Beim besten Willen kann ich mich nciht aran erinnern ob ich nach einem Installationsort gefragt werde. Aber ich werde lilypond nach dem Aufräumen nach den Versionierungsversuchen neu installieren - dann werde ich darauf achten.
Grüße
-
Hmja, Frescobaldi auch von Hand installieren wär ne Idee, da hätt ich vielleicht auch mal drauf kommen sollen …
Man wird nicht wirklich gefragt, kann aber mit der Option --prefix den Pfad ändern.
-
Man wird nicht wirklich gefragt, kann aber mit der Option --prefix den Pfad ändern.
--prefix hilft nicht, weil damit eben nur ein prefix angegeben werden kann, aber die Default-Dateinamen der nicht verändert werden können.
Wenn ich also als prefix beispielsweise ../configure --prefix = $HOME/lilypond-version eingebe (version ist dann die jeweilige Version), dann wird lilypond nach PREFIX/bin/lilypond und `PREFIX/lib/lilypond installiert, aber lilypond muss weiterhin als lilypond aufgerufen werden. (Natürlich muss dazu PATH erweitert werden.) Mein erster Versuch bei einer "Normalinstallation" lilypond in /usr/local/bin in lilypond-version umzubenennen funktionierte nicht - will es aber noch mal versuchen.
Man könnte sich natürlich ein shell-script schreiben für jede Version mit dem jeweiligen Pfad zu der Version PREFIX/bin/lilypond/lilypond für den Programmaufruf schreiben. Ob lilypond dann funktioniert müsste man testen - sollte eigentlich funktionieren, solange lilypond intern nur relative Pfade benutzt, was ich aber nicht weiß und auch nicht verändern kann.
Grüße
-
Installation von der Source lilypond 2.16.2 64bit unter Linux gibt Fehler:
...
cd ./out && /home/ich/lilypond-2.16.2/build/scripts/build/out/run-and-check "/home/ich/lilypond-2.16.2/build/out/bin/lilypond --verbose /home/ich/lilypond-2.16.2/ly/generate-documentation" "generate-documentation.log"
Please check the logfile generate-documentation.log for errors
make[1]: *** [out/internals.texi] Error 1
make[1]: Leaving directory `/home/ich/lilypond-2.16.2/build/Documentation'
make: *** [all] Error 2
Der Logfile generate-documentation.log wird auch nicht erstellt.
Hat das bei Irgendeinem richtig installiert?
Wo gibt es die Sourcen für altere Versionen und 2.17.X? Kann nur binaries mit shellscript finden?
-
Hallo bblochl,
...
cd ./out && /home/ich/lilypond-2.16.2/build/scripts/build/out/run-and-check "/home/ich/lilypond-2.16.2/build/out/bin/lilypond --verbose /home/ich/lilypond-2.16.2/ly/generate-documentation" "generate-documentation.log"
Please check the logfile generate-documentation.log for errors
make[1]: *** [out/internals.texi] Error 1
make[1]: Leaving directory `/home/ich/lilypond-2.16.2/build/Documentation'
make: *** [all] Error 2
Das sieht so aus, als hättest Du versucht LilyPond selbst zu kompilieren.
Hast Du Dich an die Instruktionen hier (http://lilypond.org/doc/v2.17/Documentation/contributor-big-page#compiling) gehalten?
Hat das bei Irgendeinem richtig installiert?
Wenn ich mich an die oben verlinkten Instruktionen halte funktioniert 'make'
Allerdings mußt Du noch kyrillische fonts installieren.
Siehe auch hier (https://liarchiv.joonet.de/index.php?topic=1258.msg6928#msg6928) (->Beobachtungen)
Ein Gedanke. Wenn Du sowieso selbst kompilierst, warum dann nicht gleich die jeweils neueste, noch nicht veröffentlichte Version? (Zumindest zusätzlich)
D.h. git repository, Infos dazu ebenfalls im Contributors Guide.
Wo gibt es die Sourcen für altere Versionen und 2.17.X?
http://download.linuxaudio.org/lilypond/binaries/linux-64/ (http://download.linuxaudio.org/lilypond/binaries/linux-64/)
bzw
http://download.linuxaudio.org/lilypond/sources/ (http://download.linuxaudio.org/lilypond/sources/)
Kann nur binaries mit shellscript finden?
Weiß ich nicht. Hab' ich nie probiert.
Wenn ich mal mehr Zeit habe schreibe ich auch mal wie ich mehrere Versionen gleichzeitig handhabe.
Ich mach das allerdings komplett manuel, da ich nicht so viele brauche wie Eluze als bug-squad-Mitglied.
(Ich habe nur die letzten stable, die neuste, released devel und die selbst kompilierte von 'master'.
Wenn ich doch eine zusätzliche brauche lade ich die source runter und kompiliere selbst oder benutze den jeweiligen installer)
HTH,
Harm
-
Mein erster Versuch bei einer "Normalinstallation" lilypond in /usr/local/bin in lilypond-version umzubenennen funktionierte nicht - will es aber noch mal versuchen.
Ja, solche Experimente habe ich auch gemacht - hat aber alles nicht geklappt. Die erste installierte Version fordert einen unveränderten Lilypond-Ordner.
Ich bin immer wieder auf die Lösung, die du schon genannt hast, zurückgekommen:
- usr/local/bin/lilypond beliebig umbenennen
- die nächste Version installieren
- usr/local/bin/lilypond zu usr/local/bin/lilypond-2-x-y umbenennen
- usr/local/bin/lilypond zurückbenennen
Gruß
-
Das sieht so aus, als hättest Du versucht LilyPond selbst zu kompilieren.
Hast Du Dich an die Instruktionen hier gehalten?
Ja, das ist ja ohnehin Standard und in INSTALL.txt jeder lilypond Version steht das noch mal. ./configure sollte eigentlich fehlende Pakete melden (tut das auch bei der 32-Bit Version auf einem 32-Bit-Rechner). Bei der 64-Bit-Version meldet er keine fehlenden Pakte, aber dafür meldet make 2 Fehler. Ich habe mal die Pakete upgedatet und danach ist die Fehlermeldung von make spezifisccher:
make[1]: Entering directory `/home/ich/Lilypond-64-2.16.2/build/python'
make[1]: *** No rule to make target `/home/ich/lilypond-2.16.2/python/midi.c', needed by `out/midi.lo'. Stop.
make[1]: Leaving directory `/home/ich/Lilypond-64-2.16.2/build/python'
make: *** [all] Error 2
Offenbar fehlt was im Unterverzeichnis python? Ich habe mal nachgeschaut, midi.c oder sonst was mit midi kommt nicht vor. Deshalb erneut die Frage: Konnte irgendjemand die 64-Bit-Version fehlerfrei compilieren. Wenn nicht sollte man vielleicht einen Bug-Report schreiben. Davor will ich aber sicherstellen, dass das Problem nicht doch bei mir liegt.
Weiß ich nicht. Hab' ich nie probiert.
... oder benutze den jeweiligen installer)
Der Installer ist ja lediglich ein kleines Shell-Script mit angehängtem (meist gezipptem) lilypond-Binaries die dann richtig auf die Verzeichnisse verteilt werden. Daran kann man aber gar nichts ändern.
Ein Gedanke. Wenn Du sowieso selbst kompilierst, warum dann nicht gleich die jeweils neueste, noch nicht veröffentlichte Version? (Zumindest zusätzlich)
D.h. git repository, Infos dazu ebenfalls im Contributors Guide.
Genau diese Idee war der Anlass nach Versionsabhängiger Installation zu suchen.
Die Methode von trulli ist wohl am Einfachsten:
- usr/local/bin/lilypond beliebig umbenennen
- die nächste Version installieren
- usr/local/bin/lilypond zu usr/local/bin/lilypond-2-x-y umbenennen
- usr/local/bin/lilypond zurückbenennen
Danke für die Hilfe, für die Links und Grüße
-
- usr/local/bin/lilypond beliebig umbenennen
- die nächste Version installieren
- usr/local/bin/lilypond zu usr/local/bin/lilypond-2-x-y umbenennen
- usr/local/bin/lilypond zurückbenennen
Hat allerdings einen Nachteil:
Greift auf /usr/local/lib zu, die nicht unterschiedlich sein kann, weil das Verzeichnis eben nur einmal da ist. Wenn sich bei den Libraries etwas ändert, Pakete entfernt werden, andere Versionen benutzt werden oder Ähnliches, kann es zu Problemen kommen.
Grüße
-
Hallo bblochl,
Offenbar fehlt was im Unterverzeichnis python? Ich habe mal nachgeschaut, midi.c oder sonst was mit midi kommt nicht vor. Deshalb erneut die Frage: Konnte irgendjemand die 64-Bit-Version fehlerfrei compilieren. Wenn nicht sollte man vielleicht einen Bug-Report schreiben. Davor will ich aber sicherstellen, dass das Problem nicht doch bei mir liegt.
Ich hatte 2.16.2 via installer installiert.
Aber um hier zu testen habe ich die source von
http://lilypond.org/source.html (http://lilypond.org/source.html)
runtergeladen und in meinen Ordner "lilypondH" verschoben und dort entpackt.
Dann habe ich nacheinander folgende Befehle ins Terminal eingegeben.
Den Terminal-output, auch die banalen Sachen, poste ich jeweils dahinter (bis auf den von 'make', das wäre ein bißchen viel. :) )
Die banalen Sachen könnte ich mir natürlich auch sparen, aber als ich ein Anfänger war, wäre ich froh gewesen, wenn mir auch die einfachsten Sachen erklärt bzw gezeigt woreden wären.
a)
cd lilypondH/lilypond-2.16.2/
ich@kasten:~/lilypondH/lilypond-2.16.2$
b)
sh autogen.sh --noconfigureprocessing .
Running autoconf ...
Skipping configure process.
ich@kasten:~/lilypondH/lilypond-2.16.2$
c)
mkdir -p build/ich@kasten:~/lilypondH/lilypond-2.16.2$
d)
cd build/ich@kasten:~/lilypondH/lilypond-2.16.2/build$
e)
../configurechecking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking Package... LILYPOND
checking builddir... /home/ich/lilypondH/lilypond-2.16.2/build
checking for stepmake... ../stepmake (${datarootdir}/stepmake not found)
checking for gmake... no
checking for make... make
checking for find... find
checking for tar... tar
checking for bash... /bin/bash
checking for python... python
checking python version... 2.6.5
checking for python... /usr/bin/python
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether compiler understands -pipe... yes
checking for IEEE-conformance compiler flags... none
checking for fc-list... fc-list
checking New Century Schoolbook PFB files... /usr/share/fonts/type1/gsfonts/c059013l.pfb /usr/share/fonts/type1/gsfonts/c059033l.pfb /usr/share/fonts/type1/gsfonts/c059036l.pfb /usr/share/fonts/type1/gsfonts/c059016l.pfb
checking for python... /usr/bin/python
checking /usr/bin/python version... 2.6.5
checking for /usr/bin/python... /usr/bin/python
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking gcc version... 4.4.3
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking g++ version... 4.4.3
checking options for known g++ bugs... none
checking whether explicit instantiation is needed... no
checking for stl.data () method... yes
checking for ar... ar
checking for ranlib... ranlib
checking for dlopen in -ldl... yes
checking for dlopen... yes
checking for bison... bison -y
checking for bison... bison
checking bison version... 2.4.1
checking for flex... flex
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking FlexLexer.h usability... yes
checking FlexLexer.h presence... yes
checking for FlexLexer.h... yes
checking for yyFlexLexer.yy_current_buffer... no
checking FlexLexer.h location... /usr/include/FlexLexer.h
checking language... English
checking for gettext in -lintl... no
checking for gettext... yes
checking for msgfmt... msgfmt
checking for mf-nowin... mf-nowin
checking for mpost... mpost
checking for working metafont mode... ljfour
checking for kpsewhich... kpsewhich
checking for guile-config... guile-config
checking guile-config version... 1.8.7
checking guile compile flags... -pthread
checking guile link flags... -pthread -lguile -lltdl -Wl,-Bsymbolic-functions -lgmp -lcrypt -lm -lltdl
checking libguile.h usability... yes
checking libguile.h presence... yes
checking for libguile.h... yes
checking for scm_boot_guile in -lguile... yes
checking for scm_boot_guile... yes
checking for scm_t_hash_fold_fn... no
checking for scm_t_hash_handle_fn... no
checking for scm_t_subr... no
checking for usable C++ demangler... yes
checking GUILE rational bugfix... ok
checking for python-config... python-config
checking Python.h usability... yes
checking Python.h presence... yes
checking for Python.h... yes
checking for gs... gs
checking for gs... /usr/bin/gs
checking /usr/bin/gs version... 8.71
checking for fontforge... fontforge
checking for fontforge... /usr/local/bin/fontforge
checking /usr/local/bin/fontforge version... 20110222
checking for t1asm... t1asm
checking for t1asm... /usr/bin/t1asm
checking assert.h usability... yes
checking assert.h presence... yes
checking for assert.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking libio.h usability... yes
checking libio.h presence... yes
checking for libio.h... yes
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking for sys/stat.h... (cached) yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking fpu_control.h usability... yes
checking fpu_control.h presence... yes
checking for fpu_control.h... yes
checking sstream usability... yes
checking sstream presence... yes
checking for sstream... yes
checking whether stat file-mode macros are broken... no
checking for working memcmp... yes
checking for vprintf... yes
checking for _doprnt... no
checking for chroot... yes
checking for fopencookie... yes
checking for gettext... (cached) yes
checking for isinf... yes
checking for memmem... yes
checking for snprintf... yes
checking for vsnprintf... yes
checking for pkg-config... pkg-config
checking pkg-config version... 0.22
checking whether to enable dynamic relocation... no
checking for rpath linkage... no
checking for pangoft2 >= 1.6.0... yes
checking PANGO_FT2_CFLAGS... -pthread -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
checking PANGO_FT2_LIBS... -pthread -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0
checking pango/pangoft2.h usability... yes
checking pango/pangoft2.h presence... yes
checking for pango/pangoft2.h... yes
checking for pango_ft2_font_map_create_context... yes
checking for fontconfig >= 2.4.0... yes
checking FONTCONFIG_CFLAGS...
checking FONTCONFIG_LIBS... -lfontconfig
checking for freetype2 >= 2.1.10... yes
checking FREETYPE2_CFLAGS... -I/usr/include/freetype2
checking FREETYPE2_LIBS... -lfreetype
checking for some flavor of Windows... no
checking for -windres... no
checking for windres... no
checking for guile... guile
checking for guile... /usr/bin/guile
checking for perl... perl
checking for perl... /usr/bin/perl
checking for makeinfo... makeinfo
checking makeinfo version... 4.13
checking for texi2html... texi2html
checking texi2html version... 1.82
checking for dblatex... dblatex
checking dblatex version... 0.2.12
checking for pdflatex... pdflatex
checking for pngtopnm... pngtopnm
checking for convert... convert
checking for zip... zip
checking for rsync... rsync
configure: creating ./config.status
config.status: creating config.make
config.status: creating config.hh
Type:
make all to build LilyPond
make install to install LilyPond
make help to see all possible targets
Edit local.make for local Makefile overrides.
ich@kasten:~/lilypondH/lilypond-2.16.2/build$
f)
make
Funktioniert.
HTH,
Harm
-
Danke, ich hab's genau so gemacht, allerdings mit der 64-Bit-Version!!. Bisher hat sich keiner gemeldet, der die 64-Bit-Version compiliert hat oder das versucht hat.
Die "normale" Version von http://lilypond.org/source.html (http://lilypond.org/source.html) ist ja wohl die 32-Bit-Version. Die habe ich bereits früher fehlerfrei compilieren können. (Ich versuch's morgen noch mal.)
Ich stelle nur fest, die 64-Bit-Version compiliert nicht fehlerfrei. Wenn es keinen interessiert, kann man das ja auf sich beruhen lassen, ich verwende eben dann die 32-Bit-Version.
Grüße
-
Hallo blochl,
ich hatte vergessen zu schreiben, daß ich unter
Linux Ubuntu 10.04 in der 64-bit-Version arbeite.
Ich bin dann davon ausgegangen, daß eine Kompilation der source von
http://lilypond.org/source.html (http://lilypond.org/source.html)
die 64-bit-Variante erzeugt.
War das ein Irrtum?
Bedenke: Ich bin ein LilyPond-Fachidiot, von Linux selbst habe ich bei weitem geringere Kenntnisse.
Gruß,
Harm
-
Ich bin dann davon ausgegangen, daß http://lilypond.org/source.html (http://lilypond.org/source.html) eine Kompilation der source von
http://lilypond.org/source.html (http://lilypond.org/source.html)
die 64-bit-Variante erzeugt.
Das kann nicht sein, weil die source von dem angegebenen Link ja nach dem Vermerk für alle Maschinen geeignet ist. Zwar laufen 32-Bit Versionen auf 64-Bit-Maschinen. (Dafür sorgt irgendeine Library, die (heute) bei den meisten Linux-Versionen schon installiert ist. Beim Übergang von 32 zu 64 Bit musste man die bei manchen Linux-Versionen mal erst nachladen.) Und nach meiner (nicht allzu großen) Kenntnis kann man nicht einfach 32-Code mit einem 64-Bit-Compiler kompilieren, weil für 64 Bit 64-Bit Libraries erforderlich sind und genutzt werden. Umgekehrt, ein 64-Bit-Code kann auch nicht mit einem 32-Bit-Compiler compiliert werden. (Vermutlich gibt es aber dafür Compiler-Optionen. Mit einfach configure/make/make install geht das jedenfalls nicht.)
Ich war nur mal neugierig ob die 64-bit-Version schneller läuft (wohl kaum, außer wegen schnellerer 64-Bit-Prozessoren) oder ob sonst irgendwelche Unterschiede erkennbar sind. Nicht zu vergessen, ich wollte mehrere Versionen habe und sah mit ./configure --prefix=..... eventuell eine Möglichkeit verscheidenen Versionen getrennt halten zu können.
Grüße
-
Das Problem hat sich insofern aufgelöst, als die 64-Bit und der x86-Source nicht mehr verfügbar ist.
Grüße
Nachtrag:
Stimmt gar nicht, unter http://download.linuxaudio.org/lilypond/sources/ (http://download.linuxaudio.org/lilypond/sources/) sind alle Sourcen verfügbar, nur von http://www.lilypond.org/download.de.html (http://www.lilypond.org/download.de.html) sind die 64-Bit- und die x86-Version weg.
-
Siehe Fortsetzung https://liarchiv.joonet.de/index.php?topic=1509.msg8396#msg8396
-
Vorausgeschickt sei, dass ein Bug wegen Versionswechsel (Update) der guile Version in praktisch allen Linux-Versionen aktuell zu Problemen bei der Compilation führte, weshalb der Thread und die Compilation wegen der Fehlersuche sehr kompliziert wirkt.
In Absprache mit harm6, der auch an den Experimenten zur Fehlersuche bei der Compilation beteiligt war (danke!) und nachedem das Thema sehr Linux-spezifisch geworden war, habe ich das Thema in "https://liarchiv.joonet.de/index.php?topic=1509.0 (http://"https://liarchiv.joonet.de/index.php?topic=1509.0)
mit
https://liarchiv.joonet.de/index.php?topic=1509.msg8396#msg8396 (https://liarchiv.joonet.de/index.php?topic=1509.msg8396#msg8396)
fortgesetzt.
Aus meiner Sicht ist das Thema in der Weiterführung nur noch für Linux-User interessant. Ich will aber darauf verweisen, dass harm6 erklärt hat, wie Windows-Nutzer mehrere lilypond-Versionen verfügbar halten können (https://liarchiv.joonet.de/index.php?topic=1499.msg8325#msg8325 (https://liarchiv.joonet.de/index.php?topic=1499.msg8325#msg8325)).
Wer sich aber wundert, dass das Thema (der Thread) so abrupt beendet wurde, kann bei Interesse bei https://liarchiv.joonet.de/index.php?topic=1509.msg8396#msg8396 (https://liarchiv.joonet.de/index.php?topic=1509.msg8396#msg8396) weiterlesen.
Grüße
-
Mit dem Problem "mehrere Versionen ... " haben sich schon ander eNutzer beschäftigt.
Ich stieß eher zufällig unter "Frescobaldi 2 installieren" darauf:
[url]https://liarchiv.joonet.de/index.php?topic=1131.msg6224#msg6224[url]
Das Thema Frescobaldi läßt natürlich nicht darauf schließen, dass es hier um die lilypond-Installation geht. Ich wusste bisher nicht, dass --prefix auch für die Installation mit der Shell funktioniert! Das erleichtert ja sehr Vieles!
Eines allerdings stimmt in dem blog nicht:
Mit synaptic werden keine Quellen installiert oder aus der Quelle installiert, sondern auch nur Binaries.
Grüße