mehrer versionen installieren und aufrufen

[bblochl]

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.

Code: [Auswählen]

./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

Code: [Auswählen]

make 2 Fehler. Ich habe mal die Pakete upgedatet und danach ist die Fehlermeldung von make spezifisccher:

Code: [Auswählen]

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:

Code: [Auswählen]

- 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

[bblochl]

Code: [Auswählen]

- 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

[harm6]

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
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)

Code: [Auswählen]

cd lilypondH/lilypond-2.16.2/


Code: [Auswählen]

ich@kasten:~/lilypondH/lilypond-2.16.2$


b)

Code: [Auswählen]

sh autogen.sh --noconfigure

Code: [Auswählen]

processing .
Running autoconf ...
Skipping configure process.
ich@kasten:~/lilypondH/lilypond-2.16.2$

c)

Code: [Auswählen]

mkdir -p build/

Code: [Auswählen]

ich@kasten:~/lilypondH/lilypond-2.16.2$
d)

Code: [Auswählen]

cd build/

Code: [Auswählen]

ich@kasten:~/lilypondH/lilypond-2.16.2/build$
e)

Code: [Auswählen]

../configure

Code: [Auswählen]

checking 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)

Code: [Auswählen]

make

Funktioniert.


HTH,
  Harm

[bblochl]

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 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

[harm6]

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
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

[bblochl]

Ich bin dann davon ausgegangen, daß http://lilypond.org/source.html eine Kompilation der source von
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

Code: [Auswählen]

./configure --prefix=..... eventuell eine Möglichkeit verscheidenen Versionen getrennt halten zu können.

Grüße

[bblochl]

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/ sind alle Sourcen verfügbar, nur von http://www.lilypond.org/download.de.html sind die 64-Bit- und die x86-Version weg.

[bblochl]

Siehe Fortsetzung https://liarchiv.joonet.de/index.php?topic=1509.msg8396#msg8396

[bblochl]

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
mit
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).

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 weiterlesen.

Grüße 

[bblochl]

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