Hallo, Am Sun, 19 Oct 2003, Manfred Tremmel schrieb:
Am Sonntag, 19. Oktober 2003 04:53 schrieb David Haller:
Am Thu, 16 Oct 2003, Rüdiger Meier schrieb:
linux: rpm -ql openssl |grep lib /usr/lib/libcrypto.so.0.9.7 /usr/lib/libssl.so.0.9.7
Oeh, ja, dat is normal. Das ist das "autoreqprov" von RPM. xine-ui verwendet offenbar irgendwas aus libcrypto/libssl, und da werden dann eben die Abhaengigkeiten eingetragen...
Jo.
Hm. Wer erstellt denn die xine-RPMs bei packman? Evtl. koennte man da
Meinereiner.
*g*
mal diese Abhaengigkeiten "per Hand" definieren... Bzw. ganz weglassen (ich weiss nicht, wozu xine die libcrypto/libssl braucht).
Für https Übertragungen zum Bleistift. Wenn ich das richtig im Kopf habe, liegt es an der libcurl, die wiederum verwendet wird, um unterschiedliche skins runterzuladen.
Ah.
Die eigentlichen Übertragungen von Videostreams macht ja die libxine, bzw. deren plugins. So gesehen denke ich, es wäre keine Katastrophe da mal mit --nodeps zu installieren (falls mich jemand darauf anspricht, ich leugne, das jemals gesagt zu haben).
Ein 'Autoreqprov: off' ist halt so ne Sache, wenn sich was ändert, kriegt man es kaum mit und bei irgend jemanden läufts dann nicht ...
Ack. Es gibt halt leider wohl keinen Weg, eine automatisch generierte Abhaengigkeit wieder rauszunehmen... Man koennte aber evtl. ein Makro definieren, dass die Abhaengigkeiten generiert und ausgibt... %define my_deps %(find $RPM_BUILD_ROOT -type f | \ /usr/lib/rpm/find-requires | grep -v 'libcrypto\|libssl' ) %define my_provides %(find $RPM_BUILD_ROOT -type f | /usr/lib/rpm/find-provides ) Requires: %{my_deps} Provides: %{my_provides} Autoreqprov: off Oder so aehnlich... Dummerweise braucht man da halt schon nen binary samt den libs... Und ob das funktioniert? Naja, je nachdem, wie du xine baeckst waere das sogar nen Test wert ;)
Eindeutig ja. Denn dann kann xine 3dnow, sse, sse2, mmx und sonstwas verwenden (wobei das eher die "untergelagerten" libs betrifft).
Tut es, wird aber immer mitcompiliert (sind alles Assembler-Routinen) und beim ersten Start geprüft, was am schnellsten läuft (die Werte kann man beim Start auf der Konsole mitlesen), selbst compilieren bringt in dem Bereich normalerweise nicht.
Achso. Jo, dann bringt ein selber kompilieren natuerlich nicht mehr. Hab ich das evtl. mit mplayer verwechselt, wo "normal" nicht die optimierten MMX/SSE/3dnow Assemblersachen einkompiliert werden? Oder war das irgendwas anderes... Apropos: weisst du was von nem Port der Sourcen von encore/src/intel_mmx/*.c von M$-inline MASM zu nasm/gas/gcc-inline-gas?
Generell gilt (auch unter Windows, nur dass man's da nicht kann ;) dass man in diesem Bereich (video) am besten selbst kompiliert. Und da ist ein "passendes" und nicht "kastriertes" src.rpm von packman mehr wert, als ein binary-rpm.
Naja, ehrlich gesagt glaube ich, dass die wenigsten User in der Lage sind, da erkennbar mehr rauszuholen. Wer glaubt mit nem simplen 'rpm --rebuild' irgend einen Vorbild rauszuholen (auch mit --target), der irrt.
Kommt auf das Paket an, bei xine offenbar nicht, s.o. :)
Wer natürlich absolute Ahnung vom gcc, seinen Optimierungen hat und die /usr/lib/rpm/rpmrc entsprechend aufgerüstet hat, mag in der Lage sein, noch 1 oder 2 Prozent rauszuschinden.
*lol* $ sh -x ~/bin/rpmbc x2divx.spec [..] + rpm -bc --target=athlon x2divx.spec + tee x2divx.spec.log Building target platforms: athlon Building for target athlon [..] $ grep athlon /etc/rpmrc optflags: athlon -O2 -march=athlon -mcpu=athlon -malign-functions=4 -fschedule-insns2 -mwide-multiply arch_canon: athlon: athlon 1 buildarchtranslate: athlon: i386 arch_compat: athlon: i686 arch_compat: i686: athlon i686 i586 buildarch_compat: athlon: i686 buildarch_compat: i686: athlon $ gcc --version pgcc-2.95.3 (das ist ein gcc-2.95.2 mit pgcc-patch + Athlon-patch -- und nein, ich hab nicht allzuviel Ahnung vom gcc ;)) *SCNR*
Aber genau die Prozessoren, die die entsprechenden Möglichkeiten bieten, die haben den minimalen Schub nicht nötig. Glaub mir, ich hab da schon einige Diskussionen auf der xine-developer Liste hinter mir, da gibts einige entwickler, die das für kompletten Schwachsinn halten, überhaupt CFLAGS mitzugeben, da xine im Makefile für die entsprechenden Bereiche lange ausgetüftelte und -getestete Optimierungsparameter enthält.
Bei mir hat das schon einiges gebracht und bringt auch einiges, v.a. wenn der Athlon vom Makefile nicht als i686 erkannt wird, und dann mit -march=i386 kompiliert wird usw... Und bei meinem Athlon 500 bringt das Optimieren fuer mmx/3dnow durchaus was (ein Film ruckelt, oder eben nicht ;). -dnh -- [OE] Zusätzlich muß man auf automatischen Zeilenumbruch sowie automatisch eingefügte Signaturen verzichten und bei Antworten auf qp-codierte Artikel das Quoting manuell nachbearbeiten. Da kann man seine Artikel auch gleich per telnet localhost 119 einliefern. [Marc Haber in dcsn]