compile problem - Githubissues

mrdudz commented 2 years ago

Ich habe grade mal das repo gecloned und versucht zu kompilieren. Als erstes stolpert es über:

In Datei, eingebunden von ././ui_cartridge_window.h:26,
                 von ../../src/cartridge_window.cpp:21:
../../src/widget_file_browse.h:29:18: schwerwiegender Fehler: quazip5/quazip.h: Datei oder Verzeichnis nicht gefunden
   29 |         #include "quazip5/quazip.h"
      |                  ^~~~~~~~~~~~~~~~~~
Kompilierung beendet.

offenbar heisst das paket hier auch anders, und zwar "QuaZip-Qt5". pkgconfig sagt dazu:

pkgconf --cflags quazip1-qt5
-I/usr/include/QuaZip-Qt5-1.2 -I/usr/include/QuaZip-Qt5-1.2/quazip -DQT_CORE_LIB -I/usr/include/qt5/QtCore -I/usr/include/qt5

edit: nachdem ich in src.pro die zeilen für den zip support auskommentiert habe kompiliert es durch:

equals(QT_MAJOR_VERSION, 5) {

#    DEFINES += ZIP_SUPPORT

    win32 {
        PKGCONFIG += quazip
    } else {
#        LIBS += -lquazip5
    }

    message("QT5 is active")
}

vllt wäre es sinnvoll das irgendwie optional zu machen, wenn das paket tatsächlich auf manchen systemen (hier gentoo) anders heisst

Zirias commented 1 year ago

Oh, das ist interessant, siehe https://github.com/ThKattanek/emu64/commit/785b176449de0610e2b2645343daa8347445c28b

Vielleicht sollte man generell auf PKGCONFIG gehen? @ThKattanek kannst du mal schauen, ob es funktioniert, wenn man quazip1-qt5 auch auf Linux als Paketnamen nutzt (statt direkt LIBS zu setzen)?

Zirias commented 1 year ago

Ok, sollte man nicht, auf Ubuntu tut das nicht. Sorry for the noise ....

mrdudz commented 1 year ago

Äh natürlich - man muss es halt installieren. Jedes Linux kann pkgconfig. Und jedes ernst zu nehmende Buildsystem benutzt das :)

Zirias commented 1 year ago

Sorry, aber DAS ist nicht das Problem hier. Das Problem hier ist, dass zumindest das Ubuntu-Paket libquazip5-dev offenbar gar kein .pc-file installiert, zumindest keines mit dem namen quazip oder quazip1-qt5.

Zirias commented 1 year ago

Ergänzend: Auf FreeBSD gibt es quazip1-qt5 (siehe verlinkter commit, das ist als patch schon länger im FreeBSD port drin), und auf deinem Gentoo offenbar auch, aber auf Ubuntu (und vermutlich anderern Linux dists?) wohl leider nicht -- damit weiß ich gerade nicht, wie man das Problem je portable lösen sollte...

mrdudz commented 1 year ago

Das klingt allerdings sehr seltsam

Zirias commented 1 year ago

Ja! Leider ...

FreeBSD kann ich im qmake .pro file checken, weil es halt ein anderes OS ist (bin hier aktiv, weil ich den FreeBSD port von emu64 maintaine) ... aber Linux ist halt Linux und wenn verschiedene Distributionen unterschiedliche Dinge in ihren Paketen ausliefern wird es eklig.

Da wäre es wohl nötig, verschiedene Ansätze, Quazip zu finden, durchzuprobieren. Ich weiß nicht ob qmake das überhaupt kann, könnte sein, dass man dieses issue nur lösen kann wenn man auf ein anderes Build-System (z.B. cmake) wechselt -> sehr viel Aufwand :(

mrdudz commented 1 year ago

neeee. Da ist einfach das Paket kaputt, imho. Wäre nicht das erste mal :)

Zirias commented 1 year ago

"Kaputt" ist Ansichtssache ... Bis vor kurzem kam OpenSSL in FreeBSD base ohne .pc files. Und das funktionierte gut, weil kaum ein Consumer von OpenSSL je erwartet hat, es mit pkg-config konfigurieren zu können ;)

Es gibt nunmal keinen verbindlichen Standard für C/C++ library pakete. pkg-config ist ein "quasi-standard", es wäre schön, wenn es immer funktionieren würde.

mrdudz commented 1 year ago

"Kaputt" ist Ansichtssache

daher "imho" :) In dem Fall liegt es einfach daran, dass dieses Paket ansich schon halbwegs exotisch ist, denke ich. Das wird halt von quasi nix benutzt, da fällt das nicht auf.

Zirias commented 1 year ago

Hm, da ist wohl was dran, auf https://www.freshports.org/archivers/quazip/ finde ich genau 8 FreeBSD ports (inkl. emu64), die Quazip nutzen.

Nur ändert das halt leider auch nichts. Wenn sowohl der FreeBSD als auch der Gentoo port ein .pc file für quazip1-qt5 liefern dann vermute ich mal, dass das "richtig" ist (diese Ports sind ja immer so nahe wie möglich an "upstream"). Auf Ubuntu (und darauf läuft auch der neue CI build hier) gibt's das halt trotzdem nicht :(

Wie gesagt, die "übliche" Lösung in solchen Fällen ist ein Build-System, das verschiedene Möglichkeiten, die benötigte Lib zu finden, "durchprobiert". Ich weiß nicht, ob qmake sowas kann, ich fürchte nicht ....

mrdudz commented 1 year ago

Vllt einfach mal einen Bug melden? Ich kann mir nicht vorstellen, dass die das mit Absicht weg werfen, wenn es im upstream drin ist. Das wäre schon ziemlich gaga. Aber vllt ist es auch garnicht drin?

Zirias commented 1 year ago

Ja, wenn man es genau nimmt liegt der Fehler offenbar beim Ubuntu package.

Upstream (Template): https://github.com/stachenov/quazip/blob/master/quazip/quazip.pc.cmakein

Resultat auf FreeBSD:

$ cat /usr/local/libdata/pkgconfig/quazip1-qt5.pc
prefix=/usr/local
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include

Name: QuaZip-Qt5
Description: Minizip wrapper library for Qt 5.x
Version: 1.4
Libs: -lquazip1-qt5
Cflags: -I${includedir}/QuaZip-Qt5-1.4 -I${includedir}/QuaZip-Qt5-1.4/quazip
Requires: zlib, Qt5Core

Ubuntu package-list: https://packages.ubuntu.com/focal/amd64/libquazip5-dev/filelist

Ok, Schrott aus alten Flippern. Korrekt wäre jetzt, auch auf Linux pkg-config quazip1-qt5 zu verwenden. Geht aber erstmal nicht, weil dann der CI Build kaputt ist ...

Zirias commented 1 year ago

So. "Schön" ist es nicht, aber ich denke ich hab es gefixt ;)

ThKattanek commented 1 year ago

Under Kubuntu funktionierts, leider will er jetzt nicht mehr unter MXE builden.

fatal error: quazip.h: No such file or directory

Aber das schaue ich mir gleich mal an.

Zirias commented 1 year ago

Ah interessant. dein MXE Tree scheint eine uralte Version von quazip zu haben, das pkg-config File hieß soweit ich das nachvollziehen konnte bis vor 4 Jahren mal quazip (und seither quazip1-qt5). Vielleicht kann man das in MXE einfach mal upgraden? Dann würde der komplette Sonderfall für Windows vermutlich wegfallen.

Zirias commented 1 year ago

Alternativ: das #ifdef __WIN32 wieder rein und NUR auf Windows eben <quazip/quazip.h> includen statt <quazip.h>. Upgraden wäre aber vermutlich sinnvoller, denn wenn es jetzt jemand mit einem aktuellen MXE, MSYS2 oder Cygwin bauen will geht es vermutlich auch schon schief ....

ThKattanek commented 1 year ago

MXE hatte ich vor dem Release komplett neu geclont und neu gebuildet. Und ich sehe schon du hast ja schon Lösungsansätze. Aber ich schaue mal in MXE warum das jetzt schief geht.

Zirias commented 1 year ago

Bitte nochmal testen ... das ist jetzt ein WEITERER workaround der hoffentlich mit dem alten quazip.pc auch funktioniert.

Zirias commented 1 year ago

Hm. Ne, jetzt isses kaputt.

ThKattanek commented 1 year ago

Auch gerade gemerkt, selber Fehler.

ThKattanek commented 1 year ago

Parallel schon mal bei mir mit MXE getestet, läuft jetzt wieder.

Zirias commented 1 year ago

Jetzt tut's. Keine OS-Checks mehr, stattdessen "durchprobieren". quazip1-qt5 sollte da sein, dann passt alles. Wenn stattdessen quazip da ist, wird das genommen, da müssen aber die include-paths manuell gesetzt werden. Letzter Fallback (gar kein .pc File gefunden): Raten. Naja.

ThKattanek commented 1 year ago

MXE verwendet quazip.pc

Zirias commented 1 year ago

Ja. Und das stammt aus alten Quazip-Versionen und ist teilweise "kaputt" (setzt nicht die richtigen include-paths). Aber der neue Workaround scheint damit jetzt klarzukommen.

ThKattanek commented 1 year ago

Ja sieht erstmal sehr gut. Muss ich mal beobachten ob sich da bei MXE was ändert, und die irgendwann auf die neue Version umsteigen. Aber so, denke ich mal, kann man gut weiter arbeiten.

Zirias commented 1 year ago

Dürfte jetzt eigentlich kein Problem mehr sein, weil die neue Version zuerst probiert wird ;)

ThKattanek commented 1 year ago

Sehr schön. Na dann übernehme ich mal dein PR.

ThKattanek / emu64

compile problem #220