• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst]boost und pkg-config

Hallo,

versuche gerade Ardour2 aus den Quellen zu kompilieren in Suse11RC1. Das geht mit scons normalerweise sehr gut, nur benutzt scons pkg-config um devel-Pakete zu finden und in /usr/lib/pkg-config steht kein .pc-file für boost. Boost wird von Ardour benötigt und ist auch korrekt und vollständig installiert (mit YAST).

Was kann ich tun?


sicher eine leicht abseitige Frage aber eine Rubrik "Paketmanagement und Software aus den Quelle übersetzten" gibt es ja nicht...
 

Appleonkel

Hacker
Hallo Hartmut,

welches .pc fehlt denn? boost.pc? Diese konnte ich auch nicht in boost-devel finden.
Gibt es einen bestimmten Grund (vst) warum du nicht das RPM von packman nimmst?
 
OP
Z

zettberlin

Newbie
Appleonkel schrieb:
Hallo Hartmut,

welches .pc fehlt denn? boost.pc? Diese konnte ich auch nicht in boost-devel finden.

Genau so siehts aus -- ob man boost.pc aus einem Paket aus fedora oder mandriva verwenden kann ?

Appleonkel schrieb:
Gibt es einen bestimmten Grund (vst) warum du nicht das RPM von packman nimmst?

VST bestimmt nicht :evil: :twisted:

aber das packman - Ardour verursacht bei mir etwa die doppelte Systemlast, die ich in 64Studio mit einem selbstgebauten Ardour habe. Das Resultat ist, dass ich Ardour mit meiner FireWire-Karte bei 96KHz Rate praktisch nicht benutzten kann. Mit JAD1.0 live geht es übrigens deutlich besser (wenn auch nicht so gut wie mit 64Studio).

Davon ganz abgesehen: in 64Studio und in den letzten 2 Ubuntus ist es absolut kein Problem, Ardour aus dem SVN zu bauen, würde mich wundern, wenn das egal wäre, dass Suse da schwächelt :wink: :wink:
 

Appleonkel

Hacker
zettberlin schrieb:
Genau so siehts aus -- ob man boost.pc aus einem Paket aus fedora oder mandriva verwenden kann ?
Kann man, man muss nur schauen ob die Pfade stimmen.

Du kannst natürlich auch das src.rpm von Packman nehmen
Code:
rpm -Uhv http://packman.links2linux.de/downloadsource/59271/ardour2-2.4.1-0.pm.1.src.rpm
Und das spec in /usr/src/packages/SPEC anpassen. Da müsste man auch sehen warum boost.pc nicht nötig ist. Packman müsste das Problem ja dann auch haben, vielleicht sagt oc2pus was dazu.

zettberlin schrieb:
Davon ganz abgesehen: in 64Studio und in den letzten 2 Ubuntus ist es absolut kein Problem, Ardour aus dem SVN zu bauen, würde mich wundern, wenn das egal wäre, dass Suse da schwächelt :wink: :wink:Davon ganz abgesehen: in 64Studio und in den letzten 2 Ubuntus ist es absolut kein Problem, Ardour aus dem SVN zu bauen, würde mich wundern, wenn das egal wäre, dass Suse da schwächelt :wink: :wink:
Da die boost.pc tatsächlich nicht in boost-devel ist, wäre es schön wenn du dazu einen Bugreport aufmachen würdest ;)

Appleonkel
 

oc2pus

Ultimate Guru
das boost in 11.0rc1 ist ein wenig "buggy", es gibt diverse Probleme insbesondere mit gcc43.

Es sind dazu einige nicht triviale Anpassungen erforderlich. Oder einfach warten auf die 11.0 stable. Die arour patches für gcc43 sind in meinem src.rpm drin.

Ein Problem ist unter anderem der "changes meaning error", den kann man z.Bsp so lösen:
sed -i -e 's|keywords<0>|boost::python::detail::keywords<0>|g' boost/python/detail/def_helper.hpp

aber das packman - Ardour verursacht bei mir etwa die doppelte Systemlast, die ich in 64Studio mit einem selbstgebauten Ardour habe. Das Resultat ist, dass ich Ardour mit meiner FireWire-Karte bei 96KHz Rate praktisch nicht benutzten kann. Mit JAD1.0 live geht es übrigens deutlich besser (wenn auch nicht so gut wie mit 64Studio).
Wenn du das nie meldest wird sich daran auch nie etwas ändern. Ich habe dir das auch in diversen anderen mails zu anderen Behauptungen von dir schon geschrieben. Aber meckern und lamentieren ist da ja wohl einfacher als konkrete Hinweise und Fehlermeldungen :mrgreen:
 
OP
Z

zettberlin

Newbie
Habe mich mal umgeschaut und gar merkwürdiges und grauenvolles festgestellt:

Es scheint gar kein .pc-file namens boost.pc zu geben. Weder im Fedorapaket, noch in der Ubuntu-Installation, auf der ich Ardour durchaus ohne weiteres Woche für Woche neu aus dem SVN übersetze.

Heißt das file vielleicht anders? Oder ist hier noch was ganz anderes am laufen?

Schätze auch, octopus weiß da Rat :)

Ansonsten:

Hat schon mal jemand Ardour2 erfolgreich auf Suse11 übersetzt?
 
OP
Z

zettberlin

Newbie
oc2pus schrieb:
Wenn du das nie meldest wird sich daran auch nie etwas ändern.
:
Habe es ja gerade gemeldet - für einen echten Bugreport weiss ich zu wenig über das Problem. Bugreports im Stil " bei mir läuft das nicht so gut" werden doch sowieso ignoriert...

oc2pus schrieb:
Ich habe dir das auch in diversen anderen mails zu anderen Behauptungen von dir schon geschrieben.

Von Dir haben ich noch nie eine Mail erhalten - hier liegt ein Missverständnis/Verwechslung vor. Es sein denn, Du würdest unter anderem Namen auch auf der UbuntuStudio-Liste schreiben :twisted: :twisted:
Ich nutze Suse jetzt seit 4 Tagen, dazwischen habe ich von einigen Tests mit JAD abgesehen, seit drei Jahren nur Ubuntu und 64Studio verwendet.

Auch stelle ich keine "Behauptungen" auf, sondern konstatiere sogenannte "Fakten". Die sehen so aus:

a.) In *allen* Debianoiden der letzten 12 Monate kann ich Ardour mit Paketen aus den einschlägigen Repos aus dem SVN kompilieren, in Suse11 nicht.

b.) In 64Studio habe ich in der Realität draussen mit meinem Laptop in 5-6 Stündigen Sessions mit Bands Musik aufgenommen. Via Firewire mit einer Presonus Firebox auf 4 Spuren gleichzeitig während bis zu 8 Spuren mitlaufen bei 96KHz Samplerate *ohne* *einen* Absturz. In Suse11 stürzt bei gleicher Last auf dem gleichen Rechner das Audiosystem alle 20-30 Minuten ab, In Ubuntu Studio alle 10 Minuten.


oc2pus schrieb:
Aber meckern und lamentieren ist da ja wohl einfacher als konkrete Hinweise und Fehlermeldungen :mrgreen:

Von meckern und lamentieren kann keine Rede sein, ich ARBEITE seit 3 Tagen an einem Problem, das andere Nutzer wahrscheinlich auch haben. Und ich hoffe, dass ich es auch für die anderen mit lösen kann. Die meisten reagieren auf Probleme aber nicht mit Arbeit, sondern indem sie es kommentarlos bleiben lassen und zu MSWin/Mac zurückkehren...


alles Gute...
 
Habe es ja gerade gemeldet - für einen echten Bugreport weiss ich zu wenig über das Problem. Bugreports im Stil " bei mir läuft das nicht so gut" werden doch sowieso ignoriert...

Klar, damit kann ein Entwickler oder Paketebauer auch wenig anfangen - um ein Problem einzugrenzen, müssen Fehlermeldungen her, wie sie z.B. in der Konsole erscheinen. Starte Ardour doch mal via Kommandozeile (evtl. mit einer Textumleitung, die den Verlauf mitloggt), im Zweifelsfalle kann auch ein Start von Ardour via 'strace' bzw. dessen Ausgabe Aufschluss über die Fehlerursache liefern (auch wenn Du beides nicht deuten kannst, einem Entwickler ist daran gelegen, möglichst genaue Informationen zu erhalten, sonst verkommt das bughunting zu 'ner Quizsendung - und dafür fehlt einfach die Zeit).

Ich komme mit dem Ardour aus dem Packman-Repository sehr gut klar, allerdings (noch) auf SuSE 10.3.

@oc2pus: Vorauseilendes Abwatschen kommt echt nicht gut. Das ist wirklich etwas anmaßend, was Du hier ablieferst...
 

oc2pus

Ultimate Guru
zettberlin schrieb:
...Das geht mit scons normalerweise sehr gut, nur benutzt scons pkg-config um devel-Pakete zu finden und in /usr/lib/pkg-config steht kein .pc-file für boost. Boost wird von Ardour benötigt und ist auch korrekt und vollständig installiert (mit YAST)....

es wird kein boost.pc benutzt, das scons sucht explizit nach einem Header:

Code:
# boost (we don't link against boost, just use some header files)

libraries['boost'] = LibraryInfo ()
prep_libcheck(env, libraries['boost'])
libraries['boost'].Append(CPPPATH="/usr/local/include", LIBPATH="/usr/local/lib")
conf = Configure (libraries['boost'])
if conf.CheckHeader ('boost/shared_ptr.hpp', language='CXX') == False:
        print "Boost header files do not appear to be installed."
        sys.exit (1)
    
libraries['boost'] = conf.Finish ()

und dort ist auch der Fehler: es sucht in /usr/local/include ... und dann später beim linken in /usr/local/lib

also ein beherztes:
Code:
sed -i -e 's|/usr/local|/usr|g' SConstruct
und schon geht es weiter, wobei bei 64bit der lib-path /usr/lib64 statt /usr/lib zu verwenden ist.
 

oc2pus

Ultimate Guru
zettberlin schrieb:
oc2pus schrieb:
Ich habe dir das auch in diversen anderen mails zu anderen Behauptungen von dir schon geschrieben.

Von Dir haben ich noch nie eine Mail erhalten - hier liegt ein Missverständnis/Verwechslung vor. Es sein denn, Du würdest unter anderem Namen auch auf der UbuntuStudio-Liste schreiben :twisted: :twisted:
Ich nutze Suse jetzt seit 4 Tagen, dazwischen habe ich von einigen Tests mit JAD abgesehen, seit drei Jahren nur Ubuntu und 64Studio verwendet.
...

jepp, sorry habe dich mit jemandem (ählicher Nick) verwechselt.
/me was wearing brown paper bag ...
 
OP
Z

zettberlin

Newbie
gropiuskalle schrieb:
Klar, damit kann ein Entwickler oder Paketebauer auch wenig anfangen - um ein Problem einzugrenzen, müssen Fehlermeldungen her, wie sie z.B. in der Konsole erscheinen.

Ich lasse Ardour eigentlich immer aus einer Konsole laufen, um zu wissen, was passiert. Dort sagt Ardour aber lediglich, dass es abgebrochen hat, wenn es abstürzt, ohne Hinweis, was es gerade gemacht hat.


gropiuskalle schrieb:
Starte Ardour doch mal via Kommandozeile (evtl. mit einer Textumleitung, die den Verlauf mitloggt), im Zweifelsfalle kann auch ein Start von Ardour via 'strace' bzw. dessen Ausgabe Aufschluss über die Fehlerursache liefern

Das ist leider sinnlos, weil ardour praktisch unbenutzbar langsam wird, wenn es via strace gestartet wird. Ist eben Echtzeitsoftware - keine simple Datenbank, bei der man auch mal 1-2 Sekunden warten kann, bis eine Antwort kommt :twisted:

gropiuskalle schrieb:
(auch wenn Du beides nicht deuten kannst, einem Entwickler ist daran gelegen, möglichst genaue Informationen zu erhalten, sonst verkommt das bughunting zu 'ner Quizsendung - und dafür fehlt einfach die Zeit).

Die strace-Datei ist etwa 5MB gross, wenn Ardour seine Session geladen hat, das Problem würde dann normalerweise nach 20-30 Minuten Betrieb auftauchen... Wenn Strace läuft, ist aber ein Betrieb kaum möglich, nach dem Klick auf Play warte ich ca. 3-4 Minuten - dann breche ich ab, weil nichts passiert...

Die letzte Nachricht im sctrace-File ist übrigens etwas im Zusammenhang mit dem Laden des Sessionfiles - zum Thema Klick auf Play steht da nichts mer drin...

gropiuskalle schrieb:
Ich komme mit dem Ardour aus dem Packman-Repository sehr gut klar, allerdings (noch) auf SuSE 10.3..

Bei 96KHz auf einem Mittelklasse-Rechner via Firewire? Wie ist es denn bei Dir mit der Systemlast, die Ardour im Betrieb verursacht?



Aber zurück zum eigentlichen Thema:

Gibt es denn eine Möglichkeit, selbst ein .pc-File zu erzeugen. Und/Oder kann mir einer von euch sein boost.pc schicken, damit ich es spasseshalber mal ausprobieren kann? Mit etwas Glück dürfte sich das File in Suse10.3 nicht sooo stark von einem für das boost in Suse11 unterscheiden - vielleicht klappt das ja - dann hätten ALLE erst mal einen workaround. :wink:
 

oc2pus

Ultimate Guru
zettberlin schrieb:
...Aber zurück zum eigentlichen Thema:

Gibt es denn eine Möglichkeit, selbst ein .pc-File zu erzeugen. Und/Oder kann mir einer von euch sein boost.pc schicken, damit ich es spasseshalber mal ausprobieren kann? Mit etwas Glück dürfte sich das File in Suse10.3 nicht sooo stark von einem für das boost in Suse11 unterscheiden - vielleicht klappt das ja - dann hätten ALLE erst mal einen workaround. :wink:

siehe mein posting oben (hat sich gerade überschnitten .. man braucht KEIN pc-file für boost bei ardour.
 

Appleonkel

Hacker
oc2pus schrieb:
es wird kein boost.pc benutzt, das scons sucht explizit nach einem Header
...
und dort ist auch der Fehler: es sucht in /usr/local/include ... und dann später beim linken in /usr/local/lib

also ein beherztes:
Code:
sed -i -e 's|/usr/local|/usr|g' SConstruct
und schon geht es weiter, wobei bei 64bit der lib-path /usr/lib64 statt /usr/lib zu verwenden ist.

Demzufolge ist es ein Bug in Ardour? Sollte scons --PREFIX=/usr nicht den richtigen Pfad setzen?
 

oc2pus

Ultimate Guru
Appleonkel schrieb:
Demzufolge ist es ein Bug in Ardour? Sollte scons --PREFIX=/usr nicht den richtigen Pfad setzen?

beim 11.0er build VOR RC1 ging das, bei 11.0rc1 brauche ich das sed zusätzlich....
ich denke erst mal abwarten auf die 11.0 final, dann entscheiden.

normalerweise sollte das scons bei ardour 2.4.1 so tun:
Code:
export PREFIX=%{_prefix}
scons \
	PREFIX=%{_prefix} \
	SYSLIBS=1 \
	SURFACES=1 \
	FFT_ANALYSIS=1 \
	LIBLO=1 \
	NLS=1 \
	TRANZPORT=1 \
%if %has_vst
	VST=1
%endif
 
OP
Z

zettberlin

Newbie
Code:
sed -i -e 's|/usr/local|/usr|g' SConstruct
und schon geht es weiter, wobei bei 64bit der lib-path /usr/lib64 statt /usr/lib zu verwenden ist.[/quote]


HA!

Der Fehler taucht in SConstruct zwei mal auf, einmal in Zeile 937 für boost und dann noch mal kurz vorher für FLAC.

beide Stellen von /usr/local auf /usr geändert und jetzt läuft das Ding :) :)

Danke für die Tipps :)

Werde das Problem auch mal bei ardour.org darlegen...
 

mattmarr

Member
Hallo!

Auch ich habe das Problem mit dem Kompilieren des Paketes.

Leider hat die besagte änderung von zettberlin bei mir nichts gebracht.
zettberlin schrieb:
beide Stellen von /usr/local auf /usr geändert und jetzt läuft das Ding

Es erscheint immer noch die Meldung:

Code:
...
Checking for C header file fftw3.h... yes
Checking for usb_interrupt_write() in C library usb... no
Checking for C header file linux/input.h... yes
Checking for FLAC__seekable_stream_decoder_init() in C++ library FLAC... no
Checking for C++ header file boost/shared_ptr.hpp... no
Boost header files do not appear to be installed.
matze@home2:~/Desktop/ardour-2.4.1>

Ich muss mir das Paket selbst Kompilieren, da mein AMD Athlon 1,2 MHz kein SSE mag. Als Kompliere ich mit der Option FPU_OPTIMIZATION=0.
Habe bisher auch noch kein RPM ausfindig machen können das bei mir funktioniert unter OpenSuSE 10.3.

Für jeglichen Tipp wie ich das Programm doch Kompiliert bzw. irgendwo ein RPM herbekomme bin ich sehr dankbar.


Gruß
Matthias
 
Oben