SuSE 10.0 64 bit / weißes Rauschen / falsche Geschwindigkeit / keine I/O Devices - Probleme mit der Packman rpm-version, den sf.net quellen und dem cvs

  • Hallo!


    Abgewaschen ist, das ist nicht das Problem.
    wxGTK habe ich mit Yast rausgeschmissen und von wxwindows.org neu runtergeladen.
    Aber configure gibt mir jetzt das aus:
    checking for strcasecmp() in strings.h... no
    configure: error: No case-insensitive string comparison function found.
    Da bin ich doch etwas ratlos. Habt Ihr eine Idee?


    Viele Grüße
    Rüdiger

  • Hallo Markus,
    das mit devel habe ich mir auch gedacht. Bloß. wo kriege ich das her? Von der SuSE-DVD schon mal nicht, so wie ich das sehe.
    Zum Problem von #21: das tritt beim configure von wxgtk auf. Wie ich herausgegoogelt habe, ist das der erste Punkt, wo der Compiler wirklich in Aktion tritt. Also was ernsthaftes. Bis jetzt habe ich noch nichts produktives herausgefunden.


    Viele Grüße
    Rüdiger

  • Hallo Markus,
    Du hast vollkommen recht, und ich Kartoffeln auf den Augen. Es gibt sehr wohl ein wxGTK-devel auf der DVD. Das hat also erstmal das Problem gelöst. Configure kommt jetzt schon wesentlich weiter, bis zu:
    [m]checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables
    See `config.log' for more details.
    configure: error: /bin/sh './configure' failed for lib-src/soundtouch
    [/m]
    Werde ich mich also erstmal nach soundtouch umsehen. Obwohl es mich schon nervös macht, daß der C++-Compiler keine Executables schreiben können soll. Config.log sagt da auch nicht mehr, soweit ich sehe.
    Abwaschen muß ich auch schon wieder.


    Viele Grüße
    Rüdiger

  • Au Mann, schon wieder auf dem falschen Fuß erwischt. Das hätte ich gar nicht für möglich gehalten, daß der nicht installiert ist. Ich kompiliere ja nicht zum ersten Mal was. Aber so wars, configure läuft durch, jetzt wirds spannend. Aber, wie gesagt, erstmal muß ich abwaschen.


    Viele Grüße
    Rüdiger

  • Es tut mir leid, schon wieder nerven zu müssen. Make bringt einen Fehler, das ist ja ziemlich selten, wenn configure geht, tuts make eigentlich auch. Aber jetzt kriege ich eine Fehlermeldung, bei der mir nichts mehr einfällt:
    [m]usr/local/install/audacity/lib-src -lm -logg -Wl,-soname -Wl,libvorbis.so.0 -o .libs/libvorbis.so.0.3.0
    /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: /usr/local/install/audacity/lib-src/libogg.a(bitwise.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
    /usr/local/install/audacity/lib-src/libogg.a: could not read symbols: Bad value
    collect2: ld returned 1 exit status
    make[5]: *** [libvorbis.la] Fehler 1
    make[5]: Leaving directory `/usr/local/install/audacity/lib-src/libvorbis/lib'
    make[4]: *** [all-recursive] Fehler 1
    make[4]: Leaving directory `/usr/local/install/audacity/lib-src/libvorbis/lib'
    make[3]: *** [all-recursive] Fehler 1
    make[3]: Leaving directory `/usr/local/install/audacity/lib-src/libvorbis'
    make[2]: *** [all] Fehler 2
    make[2]: Leaving directory `/usr/local/install/audacity/lib-src/libvorbis'
    make[1]: *** [libvorbis-recursive] Fehler 2
    make[1]: Leaving directory `/usr/local/install/audacity/lib-src'
    make: *** [audacity] Fehler 2
    [/m]
    Die Empfehlung, mit -fPIC zu kompilieren, ist ja nett, aber wie? Das müsste ins Makefile, liege ich da richtig?


    Schon wieder viele Grüße
    Rüdiger

  • Das sollte eigentlich kein Hinderungsgrund sein (Steht übrigens auch in der Überschrift...). Leider muß ich erst X wieder zum Laufen bringen, irgendwas hat es mir zersemmelt. Ich schreibe, wenn ich was Neues habe.

  • Wenn Du den gesamten Thread liest (auch die erste Seite) wirst Du bemerken, dass ich mehrfach darauf hingewiesen habe, dass ich nicht glaube, dass Audacity momentan unter "echten" 64-bit kompilierbar ist (also mit INT- und Pointer-Größe 8-Byte usw.) Ich glaube, dass Axele (der Originalposter) das Programm in irgendeinem 32-bit-Kompatibilitätsmodus kompiliert hat (also praktisch, dass SUSE bei ihm automatisch erkannt hat, dass Audacity ein 32-bit-Programm ist, und das berücksichtigt hat). Das macht ja prinzipiell nichts, denn auch 32-bit-Programme laufen auf einem 64-bit-Rechner ja recht schnell. Da ich leider keine 64-bit-Maschine habe, kann ich diese Vermutung weder wiederlegen noch bestätigen. Ich lasse mich gern eines Besseren belehren, falls jemand hier Detailinfos hat, v.a. auch welche Programme bei SUSE64 überhaupt als 64-bit-Versionen mitgeliefert werden. Ich denke schon, dass der Kernel 64-bit ist, aber ob wirklich jedes einzelne Programm und jede Library, die mitgeliefert wird, als echte 64-bit kompiliert ist, bezweifle ich jetzt einfach mal...


    Gruß
    Markus

  • Das stimmt schon, deshalb kommen ja viele Libs in beiden Versionen. Das 64-Bit-rpm von Audacity, das es bei Packman gibt (genauer gesagt sind es mehrere, für die neueren SuSE-Versionen, ist allerdings ein "wirkliches" 64-Bit-Programm: ldd zeigt lauter Verweise auf libs in /usr/lib64.

  • Hallo!
    In der man page von gcc habe ich das gefunden:


    Das wäre wohl der gesuchte Schalter. Auf der anderen Seite: für den Quellcode ist es doch egal, wie groß z.B im Endeffekt ein Integer ist. Da kümmert sich doch der Compiler drum, wie nachher der Speicherbereich aussieht. Oder bin ich naiv? Wahrscheinlich...



    Viele Grüße
    Rüdiger

  • Quote from pol


    Auf der anderen Seite: für den Quellcode ist es doch egal, wie groß z.B im Endeffekt ein Integer ist. Da kümmert sich doch der Compiler drum, wie nachher der Speicherbereich aussieht. Oder bin ich naiv? Wahrscheinlich...


    Ob Du naiv bist, kann ich nicht beurteilen ;) Aber die Aussage ist definitiv falsch.

  • Doch doch, wenn ich mir so was denke, muß ich schon naiv sein.;-) Aber wo genau liegt mein Fehler? C ist nicht meine Sache, aber bei Delphi, womit ich arbeite, war es beim Übergang von 16 Bit (Delphi 1) auf 32 Bit (Delphi 2, glaube ich, ist schon lange her), daß man am Code nichts ändern mußte. Aber ist eben keine so systemnahe Sprache wie C.
    Ich werde auf jeden Fall weiter versuchen, aber nicht wenn das Wetter so schön ist. Momentan bin ich froh, daß X wieder läuft.
    Ich werde es auch mal auf meinem alten PC mit 32 Bit-System versuchen. Da müßte es ja eigentlich gehen...


    Viele Grüße
    Rüdiger

  • Bezüglich Deines Problems bei der Kompilierung wäre es natürlich gut, wenn sich der originale Poster (axele) nochmal melden würde. Eventuell kann er Dir ja helfen. Was ist eigentlich mit dem Packman-RPM? Funktioniert das? Eventuell müsste man die Packman-Leute mal anschreiben und fragen, was sie da gemacht haben... wäre natürlich toll, wenn Audacity nativ unter 64 bit laufen würde.


    Zu der Sache, dass 32-bit-Programme nicht "automatisch" unter 64-bit laufen: Es ist natürlich richtig, dass bei Berechnungen der größere Wertebereich nur bedingt eine Rolle spielt. D.h., wenn ich schreibe "x = y + 5", ist es in den meisten Fällen egal, welche Datentypen x und y hier haben. Schwierig wird es aber bei der Kommunikation mit der Außenwelt. Um mal bei Pascal zu bleiben: Sagen wir ein binäres Dateiformat (wie WAV) hat am Anfang einen Header, in dem die Anzahl der Kanäle, die Samplerate und die Anzahl der Samples in der Datei steht. Dann sieht das z. B. so aus:


    Code
    TYPE soundfile_header = RECORD
        num_channels: INTEGER;
        samplerate: INTEGER;
        num_samples: INTEGER;
    END;


    (Das ist jetzt natürlich hypothetisch, in Wirklichkeit sieht das WAV-Dateiformat ein bisschen anders aus...)


    Wenn Du nun mittels dieses RECORDs eine Datei auf einem System schreibst, wo der INTEGER 32 bit breit ist, dann braucht dieser Header insgesamt 12 Bytes. Versuchst Du nun dieselbe Datei auf einem 64-bit-System mittels dieses RECORDs einzulesen, wo der INTEGER 64 bit breit ist, liest die Routine insgesamt 24 Bytes, und dann geht das natürlich schief.


    Das gleiche Problem gibt es auch beim Schreiben von Daten an den Soundkartentreiber, das Mixergerät, beim Senden von Daten über das Netzwerk, eben überall da, wo "physikalisch" Daten an die Außenwelt transportiert werden.


    Das Ganze lässt sich natürlich lösen, aber nur mit gewissem Aufwand. Sofern die Sprache einen Typ wie "INT32" bereitstellt, von dem garantiert wird, dass er immer 32-bit breit ist, ist es natürlich einfach. Dann kann man den Record so definieren:


    Code
    TYPE soundfile_header = RECORD
        num_channels: INT32;
        samplerate: INT32;
        num_samples: INT32;
    END;


    Falls der Compiler das nicht bietet (meistens bietet er es nicht), dann muss man vor der Kompilation einen Check machen, wie breit die jeweiligen Datentypen jeweils sind und sich die einzelnen Typen selber definieren, z. B. mit Präprozessor-Statements. In C sieht das dann etwa so aus (wie gesagt, Code nur konzeptionell):


    Code
    #if COMPILING_ON_64_BIT_SYSTEM
    #define INT32 short int
    #else
    #define INT32 long int
    #endif


    Dann kann man im Code wieder den Typ INT32 benutzen.


    Das Ganze ist den Audacity-Entwicklern schon bekannt, und wir haben auch versucht, diesen Leitlinien bei der Entwicklung zu folgen. Da wir aber verschiedene Bibliotheken anbinden, und auch, weil wir natürlich keinen 64-bit-Rechner haben, können wir natürlich nicht garantieren, dass alles so funktioniert, wie es soll (und ich persönlich gehe davon aus, dass es ohne Änderungen nicht richtig funktioniert).



    Markus

  • Hallo Markus,


    Das hatte ich eigentlich auch mit reinschreiben wollen, es aber immer wieder vergessen: meine Annahme, daß es klappen müßte, bezieht sich nur auf das "Innenleben", wo Schnittstellen ins Spiel kommen, geht es natürlich nicht. Das müßte jetzt Sache des Linkers sein, der weiß, daß es sich um ein 64 Bit-System handelt, und gegen Libs in /usr/lib64 linken müßte. So reime ich mir das zusammen.
    Das Packman-RPM war eigentlich der Anfang meines Postens hier. Ließ sich wunderbar per Yast installieren, Yast hat dazu Portaudio v19 installiert. Erfolg: das weiße Rauschen bei der Wiedergabe. Wie Du schon geschrieben hast, ist diese Portaudio-Version schrottig, und es sollte sowieso eine spezielle Portaudio-Version fest eingebunden werden, und daher auch Axels Empfehlung, ich sollte es, wie er, mit der CVS-Version versuchen.
    Es wäre wirklich schön, wenn Axel hier nochmal vorbeischauen würde.


    Viele Grüße
    Rüdiger

  • Hallo Markus, Hallo Rüdiger,


    irgendwas haut mit der Benachrichtigung der Liste wohl nicht hin. habe von Euren Posts erst jetzt per Zufall erfahren.


    Zu meiner bequemlichen Verteidigung muss ich sagen, dass ich bei SuSE Systemen immer alles aus der Paketgruppe Entwicklung auf die Platte schiebe, damit mir wirklich nur noch Exoten einen make zerstümmeln können. Übrigens habe ich dem configure oder make keine Optionen zur 32bit Kompilierung gereicht. Das wäre damals nur mein letzter Versuch gewesen.



    /usr/local/install/audacity/lib-src/libogg.a(bitwise.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC


    Hier stimmt was mit dem ogg-.devel wohl nicht. Wenn Du mit ---with-lib-preference=system,local configured hast (denglish, sorry) dann fehlt der ogg-devel der SuSE und er versucht die per cvs gelieferte. Ich habe hier libogg-devel-1.1.2-7 installiert (SuSE) mit der ging es. Aber ich glaub, den Fehler hatte ich auch. Also installiere den bitte und danach noch einmal configure, vorher make clean.


    Um die 64 bit theorie noch einmal aufzugreifen: mein compiliertes audacity shared wie folgt:
    ldd audacity
    libvorbisenc.so.2 => /usr/lib64/libvorbisenc.so.2 (0x00002aaaaabc2000)
    libvorbisfile.so.3 => /usr/lib64/libvorbisfile.so.3 (0x00002aaaaaea0000)
    libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00002aaaaafa8000)
    libogg.so.0 => /usr/lib64/libogg.so.0 (0x00002aaaab0d3000)
    libmad.so.0 => /usr/lib64/libmad.so.0 (0x00002aaaab1d8000)
    libFLAC++.so.5 => /usr/lib64/libFLAC++.so.5 (0x00002aaaab2f8000)
    libFLAC.so.7 => /usr/lib64/libFLAC.so.7 (0x00002aaaab418000)
    libsndfile.so.1 => /usr/lib64/libsndfile.so.1 (0x00002aaaab558000)
    libid3tag.so.0 => /usr/lib64/libid3tag.so.0 (0x00002aaaab6aa000)
    libwx_gtk2u_xrc-2.6.so.0 => /usr/lib64/libwx_gtk2u_xrc-2.6.so.0 (0x00002aaaab7c4000)
    libwx_gtk2u_qa-2.6.so.0 => /usr/lib64/libwx_gtk2u_qa-2.6.so.0 (0x00002aaaab958000)
    libwx_gtk2u_html-2.6.so.0 => /usr/lib64/libwx_gtk2u_html-2.6.so.0 (0x00002aaaaba80000)
    libwx_gtk2u_adv-2.6.so.0 => /usr/lib64/libwx_gtk2u_adv-2.6.so.0 (0x00002aaaabc33000)
    libwx_gtk2u_core-2.6.so.0 => /usr/lib64/libwx_gtk2u_core-2.6.so.0 (0x00002aaaabdf9000)
    libwx_baseu_xml-2.6.so.0 => /usr/lib64/libwx_baseu_xml-2.6.so.0 (0x00002aaaac2a9000)
    libwx_baseu_net-2.6.so.0 => /usr/lib64/libwx_baseu_net-2.6.so.0 (0x00002aaaac3b2000)
    libwx_baseu-2.6.so.0 => /usr/lib64/libwx_baseu-2.6.so.0 (0x00002aaaac4e5000)
    libasound.so.2 => /usr/lib64/libasound.so.2 (0x00002aaaac730000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaac905000)
    libm.so.6 => /lib64/tls/libm.so.6 (0x00002aaaacb01000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaacc59000)
    libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002aaaacd66000)
    libc.so.6 => /lib64/tls/libc.so.6 (0x00002aaaace7b000)
    libz.so.1 => /lib64/libz.so.1 (0x00002aaaad0a7000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaad1bc000)
    libgtk-x11-2.0.so.0 => /opt/gnome/lib64/libgtk-x11-2.0.so.0 (0x00002aaaad2bf000)
    libgdk-x11-2.0.so.0 => /opt/gnome/lib64/libgdk-x11-2.0.so.0 (0x00002aaaad6f4000)
    libatk-1.0.so.0 => /opt/gnome/lib64/libatk-1.0.so.0 (0x00002aaaad888000)
    libgdk_pixbuf-2.0.so.0 => /opt/gnome/lib64/libgdk_pixbuf-2.0.so.0 (0x00002aaaad9a6000)
    libpangocairo-1.0.so.0 => /opt/gnome/lib64/libpangocairo-1.0.so.0 (0x00002aaaadabf000)
    libpango-1.0.so.0 => /opt/gnome/lib64/libpango-1.0.so.0 (0x00002aaaadbc6000)
    libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00002aaaadd04000)
    libgobject-2.0.so.0 => /opt/gnome/lib64/libgobject-2.0.so.0 (0x00002aaaade59000)
    libgmodule-2.0.so.0 => /opt/gnome/lib64/libgmodule-2.0.so.0 (0x00002aaaadf9a000)
    libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00002aaaae09d000)
    libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00002aaaae219000)
    libXrender.so.1 => /usr/X11R6/lib64/libXrender.so.1 (0x00002aaaae358000)
    libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x00002aaaae461000)
    libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x00002aaaae671000)
    libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002aaaae782000)
    libglitz.so.1 => /usr/lib64/libglitz.so.1 (0x00002aaaae8bb000)
    libgthread-2.0.so.0 => /opt/gnome/lib64/libgthread-2.0.so.0 (0x00002aaaae9e1000)
    libglib-2.0.so.0 => /opt/gnome/lib64/libglib-2.0.so.0 (0x00002aaaaeae5000)
    libXinerama.so.1 => /usr/X11R6/lib64/libXinerama.so.1 (0x00002aaaaec79000)
    libXxf86vm.so.1 => /usr/X11R6/lib64/libXxf86vm.so.1 (0x00002aaaaed7c000)
    libpng.so.3 => /usr/lib64/libpng.so.3 (0x00002aaaaee81000)
    libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002aaaaefba000)
    libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00002aaaaf0dc000)
    libmspack.so.0 => /usr/lib64/libmspack.so.0 (0x00002aaaaf234000)
    libSDL-1.2.so.0 => /usr/lib64/libSDL-1.2.so.0 (0x00002aaaaf341000)
    libexpat.so.0 => /usr/lib64/libexpat.so.0 (0x00002aaaaf4d8000)
    libresmgr.so.1 => /lib64/libresmgr.so.1 (0x00002aaaaf5fd000)
    /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
    libXrandr.so.2 => /usr/X11R6/lib64/libXrandr.so.2 (0x00002aaaaf701000)
    libXi.so.6 => /usr/X11R6/lib64/libXi.so.6 (0x00002aaaaf805000)
    libXcursor.so.1 => /usr/X11R6/lib64/libXcursor.so.1 (0x00002aaaaf90d000)
    libXfixes.so.3 => /usr/X11R6/lib64/libXfixes.so.3 (0x00002aaaafa17000)
    libpangoft2-1.0.so.0 => /opt/gnome/lib64/libpangoft2-1.0.so.0 (0x00002aaaafb1d000)
    libaa.so.1 => /usr/lib64/libaa.so.1 (0x00002aaaafc47000)
    libslang-utf8.so.1 => /usr/lib64/libslang-utf8.so.1 (0x00002aaaafd65000)
    libgpm.so.1 => /usr/lib64/libgpm.so.1 (0x00002aaaafefd000)
    libncurses.so.5 => /lib64/libncurses.so.5 (0x00002aaab0003000)


    Alles hübsch gegen die /usr/lib64/


    Übrigens, Markus: mir ist noch aufgefallen, dass wenn z.B. Konqueror (bei aktivierter Sound-"Vorschau") oder ein xmms auf das alsa device zugreift, ist es für audacity nicht mehr sichtbar, d.h. die EIngänge sind weg.


    Gruß Axel

  • Hallo Axel,


    Vielen Dank für den Hinweis. Das werde ich nochmal versuchen. Aber wie gesagt, das Wetter ist viel zu gut, um die Kiste anzuwerfen. Es reicht schon, wenn ich bei der Arbeit den ganzen Tag davor sitze und nur aus dem Fenster schauen kann.


    Viele Grüße
    Rüdiger

  • Hallo!


    So. Es läuft. Unglaublich. Einen ganz dicken Dank an alle und vor allem Axel für seinen goldenen Tip. Ich habe auch jetzt einfach alle devel-Pakete installiert, so dick sind die ja auch nicht. Es ist alles einwandfrei durchgelaufen, und auch das weiße Rauschen ist weg.


    Noch ein schönes Wochenende (trotz Regen), viele Grüße!


    Rüdiger