Beiträge von cx01

    Gut zu hören :)


    Ich würde auch Lösung 2 bevorzugen, da es ja wahrscheinlich auch der eigentlichen Intention von Purebasic entspricht, dass diese zlib benutzt wird.


    Warum die Datei falsch benannt ist, weiß ich nicht. Ich könnte mir vorstellen, dass ältere Purebasic-Versionen dem Linker explizit mitgeteilt haben diese "falsch benannte" ZLib zu benutzen und es im neuesten Purebasic vergessen wurde. Kann aber auch irgendeine andere mysteriöse Ursache dahinterstecken...

    Hm, als erstes könntest du mal probieren, wenn du die "zlib.a" im Purebasic Verzeichnis nimmst und kopierst in eine "libz.a". Ich weiß nicht, wieso der Name dort falschrum ist, aber vlt wird sie deswegen vom Linker gar nicht wahrgenommen.


    Falls das nichts bringt, könntest du in der Tat auch noch in "/usr/lib/x86_64-linux-gnu" die .a-Datei vom neueren System kopieren. Die Gefahr von Fehlern ist hier eher gering, da statische Libs (.a-Endung) ja nur beim Kompilieren verwendet werden. Es sollte also nicht zu einem unbenutzbarem System führen.

    Also ich könnte mir vorstellen, dass beim Linken irgendwie zwei verschiedene "libz" verwendet werden; eventuell benutzt er zuerst eine libz.a, findet dort aber das "inflateValidate"-Symbol nicht, und zeigt deshalb den Fehler mit der libz.so, in der er das Symbol gefunden hat.


    Um das rauszufinden, müsstest du mal in alle folgenden Ordner gehen:


    Code
    /home/jogo/purebasic/purelibraries/linux/libraries
    /usr/lib/gcc/x86_64-linux-gnu/5
    /usr/lib/x86_64-linux-gnu
    /usr/lib
    /lib/x86_64-linux-gnu
    /lib/


    Und jeweils schauen, ob es dort "libz.a" oder "libz.so" gibt (oder eventuell mit einer Zahl am Ende des Dateinamens).


    Und dann für jede Datei folgenden Befehl ausführen:


    Code
    $ strings DATEINAME | grep inflateValidate | wc -l


    Der Befehl schaut, ob in der Datei die "inflateValidate"-Funktion vorhanden ist. Er sollte also bei allen Dateien eine Zahl größer 0 ausgeben.

    HM, der Linker-Aufruf sieht korrekt aus. Er übergibt das Flag "-lz", welches die libz einbindet. Ich hatte wegen des Fehlers "DSO aus der Kommandozeile fehlt" vermutet, dass diese Flag fehlt.


    Kommt denn mit dem Kommandozeilenaufruf exakt derselbe Fehler wie vorher?

    Hm, geht denn der normale Aufruf vom pbcompiler in der Kommandozeile? Also einfach nur "./pbcompiler /home/jogo/pureprojekte/0_testkram/bild_bauen_speichern.pb"?


    Wobei es vermutlich insgesamt wirklich ratsam ist, einfach auf ein neueres Linux Mint upzugraden.

    Also mir kam da noch eine Idee ;-)


    Es wäre vielleicht hilfreich, rauszufinden, welche Argumente genau an den Linker "ld" übergeben werden. Eventuell hilft das beim Eingrenzen des Fehlers. Dazu müsstest du den Command-Line-Compiler von Purebasic benutzen.


    Ich weiß nicht, ob der anzeigt, welche Argumente er an "ld" übergibt, aber falls nicht, könnte man es mit folgendem Befehl versuchen:


    Code
    strace -s 400 -Tfe execve ./pbcompiler testprogramm.pb


    Hierfür als "testprogramm.pb" einfach ein simples Programm nehmen, welches die libpng benutzt. Der ganze Befehl muss wahrscheinlich als root ausgeführt werden. In der Ausgabe sieht man dann alle ausgeführten Subprozesse, und hoffentlich auch den Linker-Aufruf.


    Die gesuchte Zeile dürfte ungefähr so anfangen:

    Code
    [pid   164] execve("/usr/bin/ld", ["/usr/bin/ld", ......

    mir ist grad aufgefallen, das libz.so.1 nicht vom Typ "Verknüpfung mit..." war, sondern genau wie die libz.so.1.2.11 als "gemeinsame Bibliothek" in "/lib/x86_64-linux-gnu/" stand.


    Das habe ich dann angepasst. Die libz.so.1 war nun (wie auch die andere zuvor) eine "Verknüpfung mit libz.so.1.2.11"

    Hm, die Tatsache, dass das zu einer anderen Linker-Fehlermeldung führt, deutet daraufhin, dass vielleicht doch die .so und nicht die .a-Datei benutzt wird.




    Habe ein bißchen gegoogelt und es klingt so, als käme dieser Fehler, wenn dem Linker nicht explizit mitgeteilt wird, gegen die libz.so zu linken. Aber wenn das so wäre, dürfte Purebasic ja auch auf dem neueren System nicht funktionieren. Also ich bin hier mit meinem Verständnis auch am Ende..


    Das einzige, was ich mir noch vorstellen könnte, wäre, wenn es mit dem modifizierten LD_LIBRARY_PATH zusammenhängt. Oder hast du den LD_LIBRARY_PATH wieder zurückgesetzt?

    Also ich denke, dass das Problem an der Zlib liegt, da die fehlende Funktion "inflateValidate" aus Zlib stammt. Dass die Zlib dann von der libpng aufgerufen wird, ist eher nebensächlich.


    Im Gegensatz zum Problem mit dem IDE-Start geht es hier halt um die statische Zlib (.a Endung) und nicht die dynamische (.so).


    Daher wäre die Frage: Gibt es im Ordner "/home/jogo/purebasic/purelibraries/linux/libraries/" eine libz.a? Falls es die nicht gibt, benutzt er vermutlich die libz.a in /lib/x86_64-linux-gnu. Und ich vermute mal du hast nur die .so von der neueren Zlib kopiert, aber nicht die .a oder?

    Zlib ist zuständig für Kompression und dürfte von sehr vielen Anwendungen benutzt werden.


    Jetzt wo ich nochmal nachgedacht habe, ist es doch nicht exakt dasselbe Problem wie mit der IDE: Denn im Falle der IDE ging es ja um eine Shared-Library (also .so Dateiendung) und hier geht es anscheinend um die statische Library (.a Endung). Also Purebasic linked die Anwendung vermutlich statisch gegen Zlib. Von daher würde das Kopieren der Shared-Library gar nichts bringen.


    In dem anderen Thread hattest du erwähnt, dass Purebasic eine eigene "zlib.a" mitliefert. Ich nehme mal an, dass diese dann auch beim Linken verwendet wird. Von daher könnte es sich doch um einen Fehler seitens Purebasic handeln. Du hattest dort auch erwähnt, dass du die zlib.a von Purebasic 5.71 in den neuen Ordner kopiert hast; hast du das mittlerweile rückgängig gemacht?

    Es klingt danach, als würde die Funktion 'inflateValidate' in deiner zlib-Version fehlen. Erst ab Ubuntu 18.04 ist sie wohl vorhanden.


    Der Workaround, den du für den IDE-Start benutzt, bringt hier vermutlich nichts, da der Fehler ja erst beim Kompilieren auftritt. Und der Compiler (bzw. Linker) weiß ja nichts von deiner speziellen zlib-Version und nutzt daher die im globalen Lib-Ordner installierte.


    Ich wüsste jetzt auch keine elegante Lösung hierfür. Eventuell wirst du doch eine neuere zlib-Version global installieren müssen; das birgt halt das Risiko, dass das System danach nicht mehr läuft...

    Ja, HeidiSQL läuft unter Windows und kann sich zu jedem MySQL/MariaDB-Server verbinden, egal unter welchem Betriebssystem dieser läuft.


    Unter Linux läuft HeidiSQL meines Wissens nicht, allerhöchstens mit WINE.

    Auf dem Server läuft auch MariaDB? Dann kannst du dich eventuell mit dem Programm HeidiSQL direkt in die Datenbank auf dem Server einloggen.


    Du müsstest dann nur die lokalen Datenbankinhalte als .SQL-Datei exportieren, und kannst dann in HeidiSQL einfach im Menü auf "Datei"->"SQL-Datei laden" gehen und die Datei dort zum Importieren auswählen.

    am Anfang der Zeile fehlte der Befehl "export" (ist wohl beim kopieren passiert - kein Thema, war schnell entdeckt)

    Das war Absicht :) In Bash bedeutet ein Befehl der Form "A=5 ls" soviel wie "Setze die Umgebungs-Variable A auf 5 und starte dann ls".


    Daher müsste in deinem Skript theoretisch auch folgendes gehen:


    Code
    LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/jogo/zlib/lib/x86_64-linux-gnu ~/purebasic/compilers/purebasic_neu


    Würde im Endeffekt aber vom Verhalten keinerlei Unterschied machen.

    Der Fehlermeldung im ersten Beitrag nach zu urteilen, denke ich, dass der Loader nach der Datei "libz.so.1" sucht und die ist halt ein Symlink auf "libz.so.1.2.8". Wenn du also nur die "1.2.11" reinkopierst, ohne den Symlink anzupassen, wird sich vermutlich nichts ändern.


    Das dann bei jedem purebasic-Aufruf die Umgebungsvariable neu gesetzt wird, ist ok?

    Im Shell-Script wird die Umgebungsvariable nur temporär gesetzt für diesen einen Aufruf; hat also keinerlei weitere Auswirkungen.

    Das könnte gehen, aber dann nutzen halt alle Programme auf dem Rechner diese neue zlib. Könnte also theoretisch zu Problemen kommen. Und nach einem Update müsstest du die Dateien evtl. wieder ersetzen.


    Existieren die Dateien wirklich nicht im /lib Ordner? Das würde mich wundern.


    Eine Alternative wäre es vlt., einfach die "purebasic"-Executable umzubenennen in "purebasic_original" und an deren Stelle ein einfaches Shellscript zu packen mit folgendem Inhalt:


    Bash
    #!/bin/sh
    LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/DEIN_USER/neue_zlib/lib/x86_64-linux-gnu ./purebasic_original

    Du kannst direkt die DEB-Datei vom Ubuntu Server laden: http://archive.ubuntu.com/ubun…1.dfsg-0ubuntu2_amd64.deb


    Diese dann entpacken "dpkg -x zlib1g_1.2.11.dfsg-0ubuntu2_amd64.deb neue_zlib" (neue_zlib ist der Ordnername, wohin entpackt wird)


    (Wohin du entpackst, ist eigentlich egal, allerdings würde ich es nicht in einen Systemordner wie "/lib" entpacken, da du dann ja eventuell Systemdateien ersetzt. Entpacken in den Purebasic-Ordner wäre aber möglich.)


    In der Konsole, von der du Purebasic startest, müsstest du dann vorher diese neue Library in LD_LIBRARY_PATH aufnehmen: "export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/DEIN_USER/neue_zlib/lib/x86_64-linux-gnu"


    Hier musst du DEIN_USER durch deinen Accountnamen tauschen (Oder falls du es nicht im Home-Ordner entpackt hast, entsprechend den Pfad anpassen).


    Danach müsstest du in derselben Konsole Purebasic starten können.

    Die Fehlermeldung deutet darauf hin, dass zlib in der Version 1.2.9 benötigt wird, aber Ubuntu 16.04 hat anscheinend nur Version 1.2.8. Das müsste in Synaptic auch nachprüfbar sein, welche Version genau installiert ist.


    Eine denkbare Lösung könnte darin bestehen, eine neuere Version von zlib zu besorgen bzw. zu kompilieren und diese dann (beim Starten von Purebasic) in die Umgebungsvariable LD_LIBRARY_PATH aufzunehmen, sodass sie gegenüber der veralteten Library bevorzugt wird.

    MP4 und MKV sind Containerformate, also sie definieren nur, wie die Video-/Audiodaten zusammen in eine Datei gepackt werden. Sie haben mit der Qualität erstmal nix zu tun.


    H264, AV1 und VP9 sind Videocodecs; sie bestimmen also die Videoqualität. AV01 dürfte der interne Formatname von AV1 sein. Von den drei Formaten sollte AV1 normalerweise die beste Qualität liefern.


    Allerdings spielt auch die Bitrate des Videos eine Rolle, also wieviel MBit pro Sekunde das Video einnehmen darf. Eine höhere Bitrate erhöht ebenfalls die Qualität.



    Ich vermute mal, dass Youtube bewusst bei AV1 die Bitrate soweit verringert, dass die Qualität ungefähr auf dem Niveau von H264 liegt. Warum allerdings bei manchen Videos die AV1-Datei größer ist (und damit auch die Bitrate höher), ist eine gute Frage.

    Falls du der Sache auf den Grund gehen möchtest, könntest du in Firefox die Entwicklertools öffnen (dazu die Taste F12 drücken). Dort dann oben auf das "Network"-Tab gehen. Wenn du jetzt eine Seite öffnest, zeigt er jede einzelne HTTP-Anfrage an. Ganz rechts werden Balken angezeigt, die die Ladedauer symbolisieren. Die "nicht-endende" Anfrage müsste daran erkennbar sein, dass sie einen ganz langen Balken hat.