de ha sikerülne is valamit fordítani, nem tudnám futtatni.

Lgb se tudta, de aztán valahogy mégis összefaragták Tutussal

Ha forráskódból telepíted, akkor az jelenleg nem működik OpenGL nélkül, OpenGL/Mesa devel csomagok kellenek hozzá. De talán megoldható lesz, hogy OpenGL nélkül is lehessen fordítani.

Szerk.: patch OpenGL nélküli fordításhoz:
(Attachment Link)

Forrásból próbáltam, más lehetőségről nem tudtam, nem vagyok nagy linuxos
Köszi, kipróbálom majd.

Forrásból próbáltam, más lehetőségről nem tudtam, nem vagyok nagy linuxos

A Git forráskód most már fordítható GL/gl.h nélkül is. Természetesen így csak a szoftveres video mód támogatott, és az -opengl használata az emulátor indításakor hibát eredményez.

Valahogy csak lehet elvileg, mert tango nick nevű fórum felhasználó fordított nekem az előző változatból, íme:

A Mac fejlesztéshez nem értek , de ha valaki küld patchet vagy binárisokat, akkor azokat beépítem/feltöltöm.

En ugyan win-hez nem nagyon ertek, de nem lehet, hogy 32 bites windows-od van, es a 64 bitest (x64) toltotted le?

32 bitest itt nem is találok. Csak 64-es és 86-os van.

Az x86-os a 32 bites.

Köszi! Már csak azt nem értem, hogy lesz a 86-ból 32. Annyira nem régi a gépem, hogy 86-ban adták ki.

Itt egy újabb hibát vettem észre: a GTK-s file választó ablakok elrontják a billentyűzet bemenetet, de csak gyorsbillentyűvel megnyitva, egérrel menüből nem. A debugger vagy egyéb ablak megnyitása és bezárása után újra működik a billentyűzet.

Ez a GTK-s Fl_Native_File_Chooser (újabb) hibájának tűnik, a többi file választó ablaktól eltérően ez nem küld FL_UNFOCUS eseményt az emulátor ablaknak, így az nem tudhatja, hogy például screenshot mentése után az F12 már nincs lenyomva. Egy lehetséges javítás a billentyűzet állapotát törölni file választó ablak megjelenítése után, de az is lehet, hogy egyszerű (nem bugos) Fl_File_Chooser-t fogok helyette használni Linuxon.

Még egy Linux probléma, amit most vettem észre az előbbi hiba tesztelése közben: lenyomva tartott billentyűnél az ismétlés felváltva küld FL_KEYDOWN/FL_KEYUP eseményeket, Windowson viszont csak az FL_KEYDOWN ismétlődik, ami előnyösebb az emulátor számára. Bár az érintkezési hibás billentyűzet emulációja Linuxon akár "feature" is lehet. Nem tudom, ez az FLTK 1.1-ben is ilyen volt-e, mert nem emlékszem hogy régen ilyen probléma lett volna. Legalább most már tudom, miért akadozik a billentyűzet például a :FILE használatakor, már csak az a kérdés, hogyan lehetne javítani.

Az o utasítás hiánya milyen csomag hiányának köszönhető?

Az "o" helyén g++-nak kellene lennie, a CXX változó hibásan lehet beállítva.

A másik, letöltöttem a linux binariest, be van lőve az ep128emu-ra az executable, mégse tudom elindítani (command not found-ot kapok az ep128emu-ra)

Parancssorból indítva működik?

Köszi! Már csak azt nem értem, hogy lesz a 86-ból 32. Annyira nem régi a gépem, hogy 86-ban adták ki.

Az Intel 8086 processzor nevéből, amit aztán követett a 186,286,386,486... az erre épülő processzor architectúrát nevezik összefoglaló néven x86-nak. Bár 32 bitről csak a 386-ostól beszélhetünk

Az "o" helyén g++-nak kellene lennie, a CXX változó hibásan lehet beállítva.

Ez érdekes: (gúgli az ember barátja, na nem mindig ) Az nem lehet, hogy verziólemaradásom okozhat problémát ? Az FLTK 1.1.10-es pl
$ make -p -f /dev/null | grep CXX
make: *** No targets.  Stop.
LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
CXX = g++

Ha az aktuális könyvtárban megtalálhatók a binárisok, akkor a ./ep128emu működik? Linuxon a PATH gyakran nem tartalmazza az aktuális könyvtárat, ezért kell a "./".

jobb a helyzet, /lib64/libm.so.6 és /lib64/libc.so.6 hiányát jelzi 64bites verzióban, és 32 bitesen meg csak /lib/libm.so.6, amit ha jól értelmezek a gúgli segítségével glibc 2.15-nek kéne lennie a gépen, de nálam a 2.12 van fent, és úgy látom a repositorykon nincs is fent frissebb (Red Hat)
Az járható út, ha letöltök egy újabb verziót pl glibc-2.24.tar.gz , és megpróbálom azt beintegrálni?