C librcs.h not found

Van egy C forrásom, amit le szeretnék fordítani, de hiányolja a librcs.h fájlt, amit nem tudok normálisan beszerezni.

Magát a librcs.h fájlt sikerült megtalálnom, de önmagában ez a fájl még kevés neki. Bár a #include <librcs.h> sorokat #inlcude "librcs.h" formára cserélve hiba nélkül lefordul a kód, de összelinkelni már nem tudja. Gondolom, a librcs.h-hoz tartozna valami body is, amit már nem tudtam megszerezni.

Mindezt 12-es debian alatt fordítanám.

Van rá esélyem, hogy megszerezzem a librcs modult, vagy hogy valahogyan helyettesítsem?

Hozzászólások

Szerkesztve: 2025. 08. 09., szo – 08:13

Bár a #include sorokat #inlcude "librcs.h" formára cserélve hiba nélkül lefordul a kód

Ez csak annyit csinál, hogy mely könyvtárakban keresse. Előbbi csak a rendszer include könyvtárat nézi.

Gondolom, a librcs.h-hoz tartozna valami body is, amit már nem tudtam megszerezni.

Úgy van. A header csak a prototípusokat tartalmazza, linkeléshez kell(ene) az implementáció is, .a vagy .so formában, amit a "-lrcs" kapcsoló hatására for hozzáfordítani (ha ezt nem adod meg, nem is fogja keresni a librcs.a / librcs.so fájlt).

Mindezt 12-es debian alatt fordítanám.

Gondolom a hivatalos csomagok között kerested és nem találtad. Esetleg keress "ITP"-vel / "RFP"-vel kezdődő debian bugot (ezek nem bugok, hanem kérelmek, hogy felvegyenek valamit a debian csomagok közé). Ha ott megtalálod, akkor meg lesz a forrás URL-je.

Van rá esélyem, hogy megszerezzem a librcs modult, vagy hogy valahogyan helyettesítsem?

Elég általános ez a mozaikszó, úgyhogy - hacsak nincs piszok nagy mázlid - nem valószínű. Én a helyedben valamelyik jellemző függvénynevére keresnék github-on, gitlab-on, stb., hátha valaki felrakta a projektjébe a binárist is (nem jellemző, de nem is példa nélküli). Persze kérdés, hogy mennyire lesz megbízható egy ilyen módon beszerzett függvénykönyvtár.

Helyettesítés kapcsán: mit csinálna? .rc konfigurációs fájlokat dolgoz fel? Vagy üzenetküldő gatewayhez API?

Köszi, jó ötlet, hogy keressek rá a header-ben definiált függvényekre. Párra megpróbáltam, de sajnos 0 találattal. Az rcs_ előtag elhagyása sem sokat segített.

Magát a librcs.h fájlt itt találtam meg. Fura, hogy implementáció nélkül.

Amúgy ez egy COMX-35 emulátor forráskódja. Kikerestem a c fájlokból, hogy milyen librcs.h-ban definiált neveket használ.

rcs_Event
rcs_GC
rcs_openGC
rcs_copyArea
rcs_closeGC
rcs_hideWindow
rcs_drawFilledBox
rcs_drawString
rcs_pollEvent
rcs_showWindow
rcs_openDisplay
rcs_createWindow
rcs_setWindowName
rcs_moveWindow
rcs_createPixmap
rcs_drawPixmap
rcs_namedForeground
rcs_closePixmap
rcs_closeWindow
rcs_closeDisplay
rcs_initWin32
rcs_Display*
rcs_Pixmap
rcs_Window
rcs_foreground
rcs_drawPoint

Bár pontosan ilyen műveleteket nem találtam máshol, talán valamilyen grafikus modulra át lehetne írni.

Bár pontosan ilyen műveleteket nem találtam máshol, talán valamilyen grafikus modulra át lehetne írni.

Nekem ezek a nevek gyanúsan X11-re utalnak. Az előtagot leszámítva szinte egy az egyben ilyen nevűek az Xlib függvényei és struktúrái (de azért nem teljesen, csak majdnem). Pl:
- rcs_Event -> XEvent
- rcs_openDisplay -> XOpenDisplay
- rcs_createWindow -> XCreateWindow
- rcs_showWindow -> XMapWindow
- rcs_hideWindow -> XUnmapWindow
- rcs_openGC -> XCreateGC
- rcs_createPixmap -> XCreatePixmap
- rcs_copyArea -> XCopyArea
- rcs_drawString -> XDrawString
- rcs_drawPoint -> XDrawPoint
- ...stb.

A legárulkodóbb a Display / Window / Pixmap / GC négyes, egyértelműen connection alapú API és sehol máshol nem láttam még Pixmap-et, csak X11 alatt (mindenhol máshol jellemzően Bitmap-nek hívják akkor is, ha igazából nem bit, hanem pixel buffer, vagy esetleg framebuffer-nek, surface-nek, de semmiképp sem Pixmap-nek). És GC-t sem láttam még sehol máshol (legalábbis Graphics Context értelemben nem használják máshol, általában Garbage Collectort szokás érteni ezen rövidítés alatt).

Remélem ez segít.

Honnan van az a C forrás amit le szeretnél fordítani, mi az?

Tehát nem egyszerű ...

Sikerült telepítenem a linRcs.so.1 fájlt, amit persze libRcs.so néven keresett a linker, de egy symlink segített.

Aztán az is kiderült, hogy a Makefile-ban a -lRcs opciót a .o fájlok után kell megadni, ellentétben azzal, ahogy abban volt. Így már a sok-sok képernyőnyi "undefined reference" helyett már csak 6-8 sor "undefined reference" üzenetem maradt. Például a "keyboardValue", ami úgy tűnik tényleg nincs benne a libRcs.so fájlban. Legalábbis a
    nm -D /usr/lib/libRcs.so | grep keyboardValue

parancs kimenete üres.

Hát, lehet, hogy ez meg fogja haladni az én képességeimet...

a -lRcs opciót a .o fájlok után kell megadni, ellentétben azzal, ahogy abban volt.

Hű, akkor nagyon nem mai darab lehet. A gcc-ben valamikor 10 évvel ezelőtt volt az a változás, hogy a libeket a parancssor végére kell rakni.

Hát, lehet, hogy ez meg fogja haladni az én képességeimet...

Még mindig megpróbálhatod Xlib-re átírni, ha más nem. Sok sikert!

Na, látod, én pont az ilyen megaszopások elkerülése végett használok Arch-ot. Azzal bármi lefordul, eleve, ami nincs a hivatalos tárolóban, az ott van az AUR-ban, és minden lib elérhető, a legfrissebb verzióban, vagy más néven, nem kell ezzel szenvedni, hogy már a függőséget is kézzel forgasd, mert nincs meg máshol vagy csak elavult verzióban. Nem kell arra sem figyelni, hogy külön a -dev végű csomagokat is leszedd, mert a forráskódot tartalmazza a normál csomag, szóval pacman -S rcs és kész.

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nincs benne, mert a hivatalos tárolóban van benne. Ebben minden benne van, ami rcs, lib, dev, elf, kutyapöcse. Kompletten.

Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Hasznos, ha az ember kialussza magát. A hibaüzenet ugyanis nem az volt a legvégén, hogy undefined, hanem hogy multiple. És néhány static és extern beillesztésével, valamint a gcc g++-ra való módosításával végre sikerült lefordítani az emulátor!

De mivel régi, nagyon aprócska.

Van rá valamilyen módszer, hogy Wayland alatt 2-szer, 3-szor nagyobb pixelekkel futtassak egy ablakot? A gpt-vel a magnus-ig jutottunk, de nem sikerül elérnem, hogy nagyítson bármit is. Olyan lenne a jó, amivel úgy lehet indítani, hogy rögtön nagyobb pixeleket használ.