Nekem nem volt ilyen probléma, bár én X alatt fordítottam, és nem távoli gépen.

Most neztem, local-ban is ez van ... Fura. Foleg, mert ha copy&paste amit scons csinal a parancssorba, akkor poccre megy, gcc, stb. Viszont az scons-al "csinaltatva" kinszenvedoen lassu es panaszkodik a DISPLAY-re. Pedig mar beleirtom SConstruct-ba is hasonlokat, hogy DISPLAY valtozot adja hozza, de igy is. Hmmm. Majd megprobalom strace-elni vagy nem tudom, hogy mi az ordogot csinalhat ... Meg amugy is fura, hogy a gcc ablakot nyitna

A GitHub-ról letöltött aktuális verzió nekem kb. fél perc alatt lefordul. De lehet, hogy azért, mert megelehetősen régi scons, Wine, és MinGW verziókat használtam. De nem volt DISPLAY hiba sem.

A Makefile hozzatetelem a szokas hatalma, scons-ot hiv amugy Viszont pl a make installer-re elvileg megcsinal mindent, az installer-t is. Igaz, hogy szerintem bele van drotozva a sajat eleresi utam a cuccra, szoval sok mindenre nem jo igy A MingW amugy az, amit meg te prezentaltal a 7z file-ban. Az scons az viszont nem, az, ami az Ubuntu 16.04-ben van. Azon gondolkodtam, hogy nem lehet megszabadulni a wine-tol? Tehat siman hivnam a i686-w64-mingw32-gcc/g++ -t (Ubuntu alatt csomagbol felteve hogy hijjak szegenyt) ami ugye nativ Linuxos ELF binaris, de windowsra fordit. Xep128-nal is igy csinalom. Persze attol meg fl/stb dolgokat ala kene pakolni ahhoz meg lusta voltam, kenyelmes volt a 7z-ed, ahogy van

Arra is gondoltam, hogy irok az egeszhez sajat Makefile-t inkabb scons helyett, mert ez utobbihoz kevesbe ertek. Na, de nem akarom en mindenaron megvaltani a vilagot persze ...

Masreszt, ha minden fix benne van (lasd commit log) akkor arra is gondoltam, hogy lassan lehetne egy verzioszamot novelni, mert igy eleg keverdesre adhat okot, hogy ez most melyik cuccos is konkretan ...

Szerintem is lehetne vegre 2.1

Ja, hat annyi modositas nincs benne :-/  2.0.9.2 -re gondoltam volna Na majd IstvanV eldonti Vegulis 2.1 egyszerubben megjegyezheto

Azon gondolkodtam, hogy nem lehet megszabadulni a wine-tol? Tehat siman hivnam a i686-w64-mingw32-gcc/g++ -t (Ubuntu alatt csomagbol felteve hogy hijjak szegenyt) ami ugye nativ Linuxos ELF binaris, de windowsra fordit.

Ez működhetne, csak át kell írni az SConstruct-ban a 'wine C:/MinGW/bin/g++.exe' és hasonló parancsokat. Természetesen kellenek hozzá a különböző függőségek is (PortAudio stb.), de ezeket talán fel lehetne használni a .7z csomagból, bár abban meglehetősen elavult verziók találhatók. De az FLTK-t valószínűleg újra kell fordítani, mert a C++ ABI változhatott néhány év alatt.

Lehetne még próbálkozni Win64 emulátor verzió fordításával is, ez valamivel gyorsabb lenne.

De az FLTK-t valószínűleg újra kell fordítani, mert a C++ ABI változhatott néhány év alatt.

Én csak az ep128emu kedvéért tartok fenn és ápolgatok egy fltk1-1.1.10 csomagot, melyet legszívesebben kihajítanék, szinte hülyére kellett foltozni, hogy leforduljon és használható legyen.
Az új fltk-1.3.3 meg alkalmatlan a mostani állapotú ep128 emuhoz, ehhez Istvánnak kellene átdolgoznia az emu forrását, amihez meg úgy vélem nincs sok kedve.

Az emulátor támogatja az FLTK 1.3-at, az itt található régi Windowsos fordító csomagban is már 1.3.2 verzió van. Az UHU-n valószínűleg más okozhatja a problémát.

Megpróbáltam lefordítani FLTK 1.3.3-al is, ami szintén működik néhány LIBS módosítás után, de ezekre nem lenne szükség fltk-config használatakor (azaz ha az FLTK telepítve lenne, és nem csak lefordítva és az emulátor forrásához másolva).

Valami gáz lehet az fltk csomagunkkal, mert az fltk-1.3.2, vagy az fltk-1.3.3 csomagunk használatával is szinte azonnal leáll a fordítás.

compile...
+ scons
scons: Reading SConscript files ...
Checking for C++ library jpeg... no
Checking for C++ library png... no
Checking for C++ library z... no
 *** error: libjpeg, libpng, or zlib is not found
Error: HIBA a(z) compile fazisban.


 Az fltk csomagok ezekkel a fordítási opciókkal készültek:
 --enable-threads \
 --enable-xft \
 --enable-shared \
 --enable-cairo \
 --enable-gl

Az fltk1 meg ezzel:

 --enable-threads \
 --enable-xinerama \
 --enable-xft \
 --enable-xdbe \
 --enable-largefile \
 --enable-localpng

Minden fltk verziónál fel vannak telepítve a jpeg, png, zlib cuccok, az fltk1 -el megleli, az fltk csomagokkal meg nem.

A sconstruct fájlban az fltk1 esetén az fltkconfig = 'fltk1-config, mert az van a /usr/bin alatt, a többi esetben persze marad az fltk-config.
Azért lett átnevezve, hogy ne legyen fájlütközés az fltk1 és fltk csomagok közt. Az fltk1 -nél külön fltk1 mappába lettek telepítve a libek és fejlécek, szintén a fájlütközéseket elkerülendő. Érdekes, hogy a nem szabványos elhelyezésűnél semmi gond nincs, és a nem megerőszakolt magasabb verziójúaknál meg nem akarja az igazságot az ep128emu, míg más fltk-t használó programoklhoz meg jó az fltk csomag.

Szóval lesz itt gondom, kár, hogy a pythonhoz (scons) tök vagyok a C-hez hasonlóan, csak a Z80 assembler megyeget, meg a bash.

Átnéztem az fltk csomagunk fájljait, szinte tök azonos az ARCH-Linuxéval, a helyei is azonosak.
https://www.archlinux.org/packages/extra/i686/fltk/

Szóval egyelőre nem értem a helyzetet.

Köszönöm István, belekukkantottam a logba, segített is!

Ez volt a logban:

/usr/bin/ld: cannot find -lXft
/usr/bin/ld: cannot find -lfontconfig
/usr/bin/ld: cannot find -lXinerama
collect2: error: ld returned 1 exit status

Megadtam neki a chrootba telepítendő csomagok listájába a hiányoltakat (fontconfig-dev, libxft-dev, libxinerama-dev), és most már gond nélkül lefordult és elkészült a csomag a leendő disztrónkoz. fltk-1.3.3. Egyébként Itt vannak az általunk (általam is) ápolt tárolóink, most a dev tárolóhoz csináltam meg épp, mely ugyi még csak virtuális, gyakorlatban nem kipróbálható,  de megcsinálom már a létező UHU-3 alá is, majd beszámolok.
Ha jó, akkor száműzhetők az fltk1 csomagok az UHU változatokból.
Persze még előtte lehet, hogy átállok a github forrására, hisz jobb, ha a forrásba már be vannak emelve a legújabb foltok és nem helyben kell barkácsolni.
Csak ki tudja, hogy melyik a stabilabban megmaradó forrás? A forráskovács, vagy a github?


De jól félrevezetett az előző hibaüzenet.
Miért is nem a logban levőket közölte?