Borland C++ builder-ben (win) írt forrásból Linux program - hogyan?

Fejlesztés

Adott egy win programozó ismerősöm, most kezdett el írni valamit windowsra Borland C++ vel, szeretné Linux-ra is lefordítani a forrást. Mivel ajánlott? Működőképes lesz? A Kylix jó, vagy gondok vannak vele (hallottam ezt-azt)?

Van-e más KÉNYELMES fejlesztőeszköz C++ hez win (vagy Linux) alatt, amivel könnyen crossplatform (minimum win és linux) lesz egy alkalmazás?

  • 5666 megtekintés

wxwindows-t (wxwidgets-et) én is használtam korábban, de borzasztó körülményes megoldások vannak benne.
Ha egy jobban átgondolt cuccot szeretnél: Ultimate++
Link: http://upp.sourceforge.net/

Ez egy komplett IDE debuggerrel, felület-készítővel, stb.
Tartalmaz egy saját platform-független osztálykönyvtárat (GUI, szálkezelés, TCP, XML, adatbázis-kezelés, formázott dokumentumkezelés, PDF-generálás, stb.).
A BLITZ technológiának köszönhetően pedig hihetetlenül gyorsan fordít.

( szdl | 2006. 02. 20., h – 17:54 )

Köszönöm az ötleteket, megnézem, de elsősorban a kérdésem első fele érdekel, tehát (mivel az illető ragaszkodik a megszokásaihoz) a már (Borland-os) megírt forrást hogyan lehet a legegyszerűbben lefordítani Linux-ra, hogy abból teljesértékű (grafikus) Linux alkalmazás legyen?

Elvileg próbálta úgy írni, hogy ne legyen teljesen windows függő, és szerintem nem is szemellenzős, csak nincs ideje most újat tanulni és érdekli a lehetőség, hogy mennyire portolható egy win-nek szánt C++ forrás más platformra, tehát mennyire egyszerű "átdobni" máshová, hogy ne kelljen teljesen átírni elölről.

"Ha cross programot akartok fejleszteni (elölről) lehet, hogy érdemes lenne megnézni a C#(mono) + GTK-t"

Ha már elölről megy, nem jobb simán Java-ban?
Az azért inkább crossplatform, mint a .Net.

Ez a mono mennyire kiforrott Linux-ra? Semmi tapasztalatom.

Mi az, hogy "mono + GTK"? Ez azt jelenti, hogy egy ilyen .net(mono) program windows alatt is gtk lib-et igényel?

Erre en ket lehetoseget latok.:
1. Ha preciz megoldas kell neki, akkor nemi plusz munkaval portolja az alkalmazast QT-re. Ha nem barkacsolva irja meg, hanem "el a QT lehetosegeivel" (ez egy eleg tag fogalom, de programozok tudjak mire gondolok) akkor az igy kapott alkalmazas kompatibilis lesz vindoz, mac osx, es szinte az osszes *nix platformon. Ami mellette szol, hogy elegge kiforrott, jol atgondolt rendszer, villamgyorsan lehet UI-t tervezni vele, konnyen lehet BC++ -bol portolni ra, mivel a bc++/kylix alatt is valojaban a QT duborog. :) (Abban az idoben epitette ra a borland amikor a Kylix megjelent, lenyegebben pont a QT biztositja a crossplatform kornyezetet neki is.) Elvileg teljesitmenyben is jelentkezni fognak az elonyei.

A licensze QPL/GPL. Ha GPL progirol van szo, akkor fonyeremeny, ha viszont zart forraskodon szeretne publikalni, akkor kemeny vamot szed erte a ceg. Ugy par ezer dollar kornyeken, attol fugg, hogy hany platformot erint. ;-( http://www.trolltech.com

2. Ha villamgyors megoldas kell, akkor leforditja vindozra, majd feltelepiti a wine-t (vindoz emulator) es ratelepiti a wine-ra a progijat, majd elvileg kulcsra kesz. Utobbi idoben elegge feljottek ezek a win klonok es emulatorok, ma mar szinte barmilyen vines alkalmazast kepesek megbizhatoan futtatni. Ha esetleg nem indulna el wine felett elsore, akkor a wine-t debug modba futtatja es kiirja, hogy hol nem illeszkedik az alkalmazas, majd javitja azokat a reszeket.

A hatranya, hogy ha ez a progi egy lelegeztetogeopet vezerel, akkor en kerulnem ezt a megoldast. A masik, hogy nemi teljesitmeny vesztesegre szamitani kell (alt. 5-10%). Persze ez sem torvenyszeru, mert pl a Max Payne kb. masfelszer gyorsabban fut vele az en gepemen mint vindoz alatt eredetileg. Arrol nem beszelve, hogy az xp felett a max payne korrektul fagy minden uj palyanal.

Polesz kollegat nem szeretnem megserteni, de a wxWindow nem egy szerencses konstrukcio (bar, szigoruan IMHO), sokat kell workaroundolni es csak a baj van vele. ;-(

Sok sikert. ;-)

PS: fltk-t es a lazarus-t esetleg megnezhetnetek. En nem probaltam meg oket, de "allitolag" igeretesnek tunnek. Azt nem tudom, h a lazarus csak delphi klon-e, vagy BC++ is talan?

---------------------
Ригидус а бетегадьбол

Hát igen, engem is az ára tartott vissza a Qt-től.
Egy kereskedelmi alkalmazás fejlesztéséhez kellett valami. wxWidgets-el kínlódtam egy darabig, amikor megtaláltam az Ultimate++-t. Tényleg elképesztően hatékony! Szerintem a Qt-nál is produktívabb vele az ember, Java/Swing-ről nem is beszélve. Ráadásul totál stabil kiforrott cucc és BSD a licensze. Tökéletesen alkalmas jó minőségű kereskedelmi aklalmazások fejlesztésére is, bár egyelőre csak Win és Linux/FreeBSD platformokon.
Annyi vele a baj, hogy még semelyik nagy cég nem kapta fel. Eredetileg cseh programozók kezdték el fejleszteni szép csendben minden csinnadratta nélkül.
Azért is reklámozom itt, hátha akad még valaki, aki tudna valahogy közreműködni. Leginkább doksikra és a nyomtatás linuxos portolására lenne szükség.
Az egész cucc egyébként úgy van kialakítva, hogy a library nagyon könnyen és gyorsan módosítható. Nem kell mindent újrabuildelni és telepíteni. Adja magát, hogy az ember belekeveredjen a fejlesztésbe :)

"2. Ha villamgyors megoldas kell, akkor leforditja vindozra, majd feltelepiti a wine-t (vindoz emulator) es ratelepiti a wine-ra a progijat, majd elvileg kulcsra kesz. Utobbi idoben elegge feljottek ezek a win klonok es emulatorok, ma mar szinte barmilyen vines alkalmazast kepesek megbizhatoan futtatni."

Az szerintem kudarc lenne, ha a wine-ban való futtatás maradna. Csak legvégső esetben. Elég változó a tapasztalatom wine-nal, ha az ember peches, akkor szerintem nem javasolt. Mindenesetre ez is ki lesz próbálva.

( golgota | 2006. 02. 20., h – 19:58 )

Ugye wines grafikus progit azert nem lehet csak ugy konvertalni a linuxra, mert az egyik a windowsos guit/widget keszletet hasznalja, az X pedig az Xlib-et alapb=l, amire aztan epul a rengeteg widget library, mint pl: Xt (libxt-dev), Xaw(libXaw-dev), motif(valamelyik lesstiff vagy openmotif), aztan a GTK meg a QT. Eloszor is a wines kodot nagyon ugy kell megirnia, hogy teljesen elkulonuljon az UI meg a business logic. Ha ez hokes, akkor mar csak ki kell valasztania, hogy melyik widgetset-re akarja protolni. A legcelszerubb valami olyanra, amire van winfosos verzio. Utana meg egy kis programozgatas es teszteles win alatt a megfelelo widgetsettel, es ha minden tutira mukodik, mehet at a linuxra. Onnan mar csak par ugras, hogy atirja a rendszerhivasokat, es egyebb linux specko dolgokat. Vagy van olyan okos es mar alapban is szetszedte kulon c es h allomanyokra.
Ha jot akar, akkor persze mindezek elott, mielott nekul rogton kodolni nezzen at egy par olyan nagyon kicsi programot, ami win es x alatt is fut. Jo kiindulas lehet mondjuk egy analog ora progi vagy hasonlo.
Szal hajra...elore a gyozelemig :)

"Ugye wines grafikus progit azert nem lehet csak ugy konvertalni a linuxra, mert az egyik a windowsos guit/widget keszletet hasznalja, az X pedig az Xlib-et alapb=l, amire aztan epul a rengeteg widget library"

Én is valami ilyesmit gondolok, ezért lenne jó a QT-s megoldás, csakhogy zártkódú program lesz.

"Eloszor is a wines kodot nagyon ugy kell megirnia, hogy teljesen elkulonuljon az UI meg a business logic. Ha ez hokes, akkor mar csak ki kell valasztania, hogy melyik widgetset-re akarja protolni. A legcelszerubb valami olyanra, amire van winfosos verzio. Utana meg egy kis programozgatas es teszteles win alatt a megfelelo widgetsettel, es ha minden tutira mukodik, mehet at a linuxra. Onnan mar csak par ugras, hogy atirja a rendszerhivasokat, es egyebb linux specko dolgokat. Vagy van olyan okos es mar alapban is szetszedte kulon c es h allomanyokra."

Megpróbálom ezt közvetíteni felé, de nem hiszem, hogy lesz türelme hozzá, nem nagyon látott még Liunux-ot, és szerintem a GTK-ról és a QT-ről sem sokat hallott.

( bocs | 2006. 02. 21., k – 20:16 )

Nekem is hasonló a problémám: sok éves c++ builder-es múlt van mögöttem.

- ha most kezdett el írni windows-ra borland c++-ben, akkor sürgősen hagyja abba. A Borland, sajnos el kell ismerni, teljesen a szakadék felé megy, a c++ builder vonal nagyjából halálra ítéltetett, pedig félelmetesen jó eszközt sikerült alkotniuk, ami még ma is ütős, de nincs jövője, a marketing droidok a Borlandnál elcseszték az egészet.

- a Kylix halott. egy másodpercet sem érdemes belefeccölni. Kylixes programok forgatása, futtatása, telepítése linuxon nem leányálom.

- ami megéri a belefektetett pénzt/energiát: Qt. Ez akkor igaz, ha pénzes termékről van szó, aminek működnie kell, MOST.

- ha nincs pénz, akkor a projekt úgy se komoly, akkor lehet játszani, kísérletezni mindenféle alternatív eszközökkel: mono (abszolút kiforratlan), wxwindows (nehézkes), lazarus (pascal), stb.

"Nekem is hasonló a problémám: sok éves c++ builder-es múlt van mögöttem.

- ha most kezdett el írni windows-ra borland c++-ben, akkor sürgősen hagyja abba. A Borland, sajnos el kell ismerni, teljesen a szakadék felé megy, a c++ builder vonal nagyjából halálra ítéltetett, pedig félelmetesen jó eszközt sikerült alkotniuk, ami még ma is ütős, de nincs jövője, a marketing droidok a Borlandnál elcseszték az egészet.

- a Kylix halott. egy másodpercet sem érdemes belefeccölni. Kylixes programok forgatása, futtatása, telepítése linuxon nem leányálom.

- ami megéri a belefektetett pénzt/energiát: Qt. Ez akkor igaz, ha pénzes termékről van szó, aminek működnie kell, MOST."

Valami bíztatóbbat? :-)

"- ha nincs pénz, akkor a projekt úgy se komoly"

Háát, attól még komoly lesz!

Van még alternatíva? (esetleg ez az Ultimate++?, erről még milyen vélemény van? - vagy JAVA?)

( gsimon | 2006. 02. 22., sze – 05:48 )

Esetleg a gtk-t nézném még meg a helyében, meg azt, hogy cygwin alatt mi megy belőle. Nem feltétlenül a win-nek kell lennie az elsődleges platformnak :)...

( aperger | 2006. 02. 22., sze – 06:45 )

Szia,

Van a Kylix 3 C++ IDE, ami képes megérteni a CLX-es C++ Builderes projekteket, de olyan rendszeren kell futtatni ha Debian-os vagy amin 2.4-es kernelt is tudsz használni, vagy a RedHat 7.3-8.0-9.0, Fedora FC2-3-4, SuSE 8.2-9.0. A kész program nekem eddig mindenhol elindult.
http://www.pergersoft.hu
Sajnos az IDE (a lefordított program nem) wine-vel működik, ebből vannak a gondok. A C++-os rész különösen problémás, én pascal-os vagyok. De van megoldás.

http://andy.jgknet.de/oss/kylix/wiki/index.php/Main_Page

A Qt nagyon drága... amíg összejön rá a pénz... a Kylix-is jó.

Perger Attila

Kösz az infot!.

Ha jól értem, egy mai 2.6-os kernelű Linux-on problémás a kylix, tehát a kylix használatához és a fordításhoz külön használni kell egy 2.4-es Linux-ot, viszont a fordítás után maga a program bármilyen (friss) Linux-on megy.

C++ lesz, nem pascal.

Szóval nem egyszerű!

Ha mégis Kylix maradna, akkor felkereshetünk még tanácsért?

C++-os részt nem használtam, mert minden dolgom (raktárkezelés, számlázás témakörben) pascal-ból jön. Persze ha tudok segítek!

**************************
Én sikeresen futtattam a Kylix 3 Prof. (Delphi IDE) fejlesztőeszközt a következő disztribúciókon: RedHat 7.2-7.3, RedHat 8, SuSE 8.2-9.0, UHU 1.1.1, Fedora Core 2-3-4 és ma sikerült Debian 3.1 alatt is újrafordítani az egyik rendszerem.
Jelenleg az FC4-at használok, de eddig nincs gondom.

Az FC3-4 (kernel 2.6) verziók alá pedig kell egy kis trükk...
(ezek az IDE futtatásához kellenek, fordításhoz, stb..)
a "stratdelphi" script-be kell írni (IDE futtatás)

LD_ASSUME_KERNEL = 2.4.21

egy kis beírás a "/etc/rc.d/rc.local" fájlba (soksor kellhet a futtatáshoz egyes disztró-kon)

echo > 1 /proc/sys/vm/legacy_va_layout

A CrossKylix http://crosskylix.untergrund.net/execshield.shtml oldalán elérhető egy patch ami a programok futtatásához kell az új kernelek alatt, a fordító hiányosságait javítja. Néhány oldal ahonnét én is összeszedtem a dolgaimat:
http://www.kylix.hu
http://www.drbob42.com
http://crosskylix.untergrund.net
http://www.kylix-patch.de.vu

Az utolsó linken lehet találni egyéb patch-eket a C++-os Kylix futtatásához.

PergerSoft - http://www.pergersoft.hu

***************************

Attila

A Kylix-szel az a baj, hogy
- nem fejlesztik tovább, bedöglött. Komoly projektnél ez azonnal kizáró tényező.
- pénzes
- forrást nem kapsz hozzá. a Qt-hez odaadják a teljes forrást, úgy buherálod meg, ahogy akarod.
- sok baj van vele, nem megfelelő locale beállításnál a lefordított program segfaultol és ilyenek. lásd valamelyik másik topic-ot.

mondjam még?

Szia,

Fejlesztik (inkább javítják, készülőben van egy Qt3-es fork, ami valószínü a Qt4-re is átalakítható lesz), csak nem a Borland.
Amíg a FreePascal és a Lazarus páros nem lesz elég stabil, addig nagyon is jó. Fontos, hogy az embernek ne kelljen eldobni a kódjait.
És oda át lehet vinni a kód jó részét.

Hát komoly project-re a Qt, hogy finoman fogalmazzak, nem olcsó. Ha én lennék a fejlesztő (a kód tulajdonosa) nem foglalkoznék nyilt forrással. Így már az is pénzes. Persze, lehet nyílt forrással fejleszteni. Csak ennek a mikéntjében én még nem vagyok járatos és nincs meg hozzá a kultúránk. :-( Sajnos összemosódik a nyilt forrás és az ingyenes program.
A fent említett raktár és készletkezelő fejlesztése addig fog tartani, amíg a készített programok jól futnak a mai disztribúciókon. Én 2.6.15.4-es kernelt használok és fut a Kylix (Delphi) és van érdeklődés a program irányt. Pláne, hogy a Delphi 7 alá elérhető egy modul amivel Linux-os binárist lehet fordítani 1 lépésben!
Egy teljesen új rendszert (témájában is különbözőt) már csak akkor kezdenék vele, ha a megrendelő kérné, ami nem valószínű. Én is a Qt és Java között vacilálok. Mindkettőben van tapasztalatom (C++/Java). Ha ügyviteli, gyártástámogató, analizáló programról van szó a választ a jelentéskészítő modul dönti el, hogy melyik legyen. Legalábbis nekem mindig az a kulcskérdés. Jó ha van egy jól kezelhető report szerkesztő, ami modulként beépülhet a programba. És akkor a különböző kimenetekről még nem is beszéltem (*.xls): ez rendszeres kérése minden felhasználónak.

Attila

( golgota | 2006. 02. 22., sze – 20:52 )

En csak ismetelni tudom magam. Valamilyen crossplatform widgetset-re kell epitkezni. A QT szerintem a legjobb ebben az esetben es a KDevelop, annak ellenere, hoigy nem vagyok se QT se KDE rajongo, a C++-t meg mar regota hanyagolom.
Es utana mer telleg csak a finomhangolas van hatra.

Belekukkantottam Ultimate++ honalapjaba, azert a Trolltech Qt-je joval-joval tobbet tudd, mint az Ultimate++. A Qt nem csak egy egyszeru widget gyujtemeny, egy csomo dolog bele van agyazva ebbe rendszerbe, hogy ne kelljen kulso lib-eket hasznalnia az embernek es konnyen portolhato legyen mas platformra is.

A Qt nem csak egy egyszeru widget gyujtemeny, egy csomo dolog bele van agyazva ebbe rendszerbe, hogy ne kelljen kulso lib-eket hasznalnia az embernek es konnyen portolhato legyen mas platformra is.

Akárcsak az Ultimate++:
- szálkezelés
- adatbáziskezelés
- hálózati protokollok
- objektum-szerializáció
- STL-nél használhatóbb tárolók
- XML
- stb.

Azt azé írtam hogy a QT-hez én sem ragaszkonék, csak mongyuk itt is bejön lassan, mint a win-ben, hogy mindenki KDE-t meg Gnome-ot használ és ezekre külön pöpec fejlesztőkörnyezetek vannak, ami kinyalja az ember seggét. Szóval kezdetnek jó ezeket használni. Persze a legegyszerűbb csak Xlib-et használni és vi-ban tolni, de nem biztos, hogy a Borland terméke után le tudná nyűgözni a dolog a srácot. :)
Szóval egyet kell értsek veled zsolt, de mégis úgy gondolom, hogy először fogjuk meg a csilivilibb végén, hálózzuk be, szoktassuk rá, amíg már vakaródzik a wintől. Akkor majd bedobjuk, hogy van finomabb, jobb anyagunk. :)

Érdekes dolog ez.
A múltban a C++ nyelvhez valahogy nem jöttek ki normális osztálykönyvtárak, talán a Qt és a Borland kivételével. A többi mind csak nagyot ígért, de azt sosem tartotta. Általában néhány problémára nyújtottak megoldást, egymástól eltérő filozófiával és sokszor elég körülményesen.
Szóval az emberekben kialakult egy általános rossz kép a C++-ról, pont a vacak osztálykönyvtárak miatt. Ezért aztán rengetegen elfordultak a Java és a .NET felé.
Ezért érdekes módon az emberek egyszerűen nem képesek elhinni, hogy létezhet olyan C++ osztálykönyvtár és IDE, amivel lényegesen könnyebben, gyorsabban lehet jobb minőségű programokat létrehozni, mint mondjuk Qt-vel vagy akár Javával. Ez túl meredeken hangzik és hihetetlen. Ezért aztán az emberek meg sem nézik.

Ja...megint az a fránya marketing hiányzik. :)
Aminek meg van az megint csak a Qt, meg a nagy M$ által kitalált "sokkal jobb" dolgok linuxos klónjai.
Na de ezek már csak sirámok meg nagyon offtopik jellegű dolgok, úgyhogy be is fejezem.

P.S.:
A Javát mondjuk azért egy kicsit lehet védeni a dokumentációja miatt, mert ennyire összeszedett doksi(k) nem nagyon van(nak).

probaltam mind az 511 illetve a 602-vel is.

Megcsinaltam az install alapjan a ~/upp-rol a kovetkezoket:
/usr/local/share/upp
/usr/local/lib/upp
/usr/local/bin/upp
/usr/share/upp
/usr/lib/upp
/usr/bin/upp

Majd mikor elinditom a theide-t akkor az arra panaszkik, hogy nincs upp dir neki es itt elszall

Valamit félreértettél.
A lényeg:
Másold be az egészet mondjuk /usr/local könyvtárba
Ekkor ott lesz egy upp-blablabla nevű könyvtár.
A benne lévő upp könyvtárat meg symlinkeld mondjuk /usr/local/lib/ -be.
a ~/upp-t töröld le, majd ő megcsinálja első futtatáskor.

Aztán csinálj egy ~/MyApps könyvtárat, ide mehetnek majd a saját project-jeid.

Igen kozben rajottem en is es most mar el is indul.. :-)
Viszont megprobaltam leforgatni a legelso pelda alkalmazast, s a vegen ilyen hibalistat ad:

/home/cz/upp/uppsrc/Core/Mt.cpp:6: error: redefinition of 'void CriticalSection::Enter()'
/home/cz/upp/uppsrc/Core/Mt.h:61: error: 'void CriticalSection::Enter()' previously defined here
/home/cz/upp/uppsrc/Core/Mt.cpp: In member function 'void CriticalSection::Enter()':
/home/cz/upp/uppsrc/Core/Mt.cpp:8: error: 'GetCurrentThreadId' was not declared in this scope
/home/cz/upp/uppsrc/Core/Mt.cpp:9: error: 'threadid' was not declared in this scope
/home/cz/upp/uppsrc/Core/Mt.cpp:10: error: 'section' was not declared in this scope
/home/cz/upp/uppsrc/Core/Mt.cpp:10: error: 'EnterCriticalSection' was not declared in this scope
/home/cz/upp/uppsrc/Core/Mt.cpp: At global scope:
/home/cz/upp/uppsrc/Core/Mt.cpp:14: error: redefinition of 'void CriticalSection::Leave()'
/home/cz/upp/uppsrc/Core/Mt.h:62: error: 'void CriticalSection::Leave()' previously defined here
/home/cz/upp/uppsrc/Core/Mt.cpp: In member function 'void CriticalSection::Leave()':
/home/cz/upp/uppsrc/Core/Mt.cpp:16: error: 'threadid' was not declared in this scope
/home/cz/upp/uppsrc/Core/Mt.cpp:17: error: 'section' was not declared in this scope
/home/cz/upp/uppsrc/Core/Mt.cpp:17: error: 'LeaveCriticalSection' was not declared in this scope
/home/cz/upp/uppsrc/Core/Mt.cpp: At global scope:
/home/cz/upp/uppsrc/Core/Mt.cpp:20: error: redefinition of 'CriticalSection::CriticalSection()'
/home/cz/upp/uppsrc/Core/Mt.h:66: error: 'CriticalSection::CriticalSection()' previously defined here
/home/cz/upp/uppsrc/Core/Mt.cpp: In constructor 'CriticalSection::CriticalSection()':
/home/cz/upp/uppsrc/Core/Mt.cpp:22: error: 'threadid' was not declared in this scope
/home/cz/upp/uppsrc/Core/Mt.cpp:23: error: 'section' was not declared in this scope
/home/cz/upp/uppsrc/Core/Mt.cpp:23: error: 'InitializeCriticalSection' was not declared in this scope
OL_Set.cpp

Mi hianyozhat meg neki?

Visszatertem az 511-re valamint a 3.4-es gcc-re es megjavult minden.. Koszonom a segitseget:-)
A peldak azok tokeletesen lefordultak mar cskak a referenciak nem akarnak rendesen mukszeni.
Pl a mysql is az MT resznel szall el:-(

/home/cz/upp/uppsrc/Core/Mt.h: In function `int AtomicInc(Atomic&)':
/home/cz/upp/uppsrc/Core/Mt.h:46: error: `__atomic_add' undeclared (first use this function)
/home/cz/upp/uppsrc/Core/Mt.h:46: error: (Each undeclared identifier is reported only once for each function it appears in.)
/home/cz/upp/uppsrc/Core/Mt.h: In function `int AtomicDec(Atomic&)':
/home/cz/upp/uppsrc/Core/Mt.h:47: error: `__atomic_add' undeclared (first use this function)
/home/cz/upp/uppsrc/Core/Mt.h: In function `int AtomicXAdd(Atomic&, int)':
/home/cz/upp/uppsrc/Core/Mt.h:48: error: `__exchange_and_add' undeclared (first use this function)
/home/cz/upp/uppsrc/MySql/MySql.cpp: In member function `virtual bool MySqlConnection::Fetch()':
/home/cz/upp/uppsrc/MySql/MySql.cpp:306: error: invalid conversion from `long unsigned int*' to `dword*'

Ezzel az a gond, hogy azt a fránya __atomic_add() függvényt a 3.4-es gcc-ben meg betették a __gnu_cxx névtérbe. Vagy kijavítod az Mt.h-ban vagy visszaállítod a gcc-3.3-at.
Nem lenne rossz, ha ezt az egészet beleírnád az Ultimate++ fórumba, hátha megoldja valaki. Ki kéne preparálni az Mt.h-t és az Mt.cpp-t egy csomó #ifdef-fel, hogy normális legyen.

( atommokus | 2006. 02. 24., p – 12:51 )

hali mindenkinek

az ultimate++-ban hogyan tudom megoldani, hogy egy program az egesz
kepernyot lefedje, mint pl a wxwidgets eseteben a

frame->ShowFullScreen(true, wxFULLSCREEN_ALL);

thx

/* bocs az esetleges helyesirasi hidakert */