Ez akkor gondolom minden gcc hívásnál kell - értsd a linkelésnél is?
KÖSZÖNÖM!
Az opcióval rájöttem a legkézenfekvőbb megoldásra - gcc manual - nem tudom miért nem jutott ez előbb eszembe :( Párszor már keresgéltem itt, de olyan mennyiség az opció, hogy nagyon el tudok benne veszni.
Na azért mégsem olyan egyszerű ez a dolog :(
Most épp a fordítottjával próbálkozom, azaz i386 platformon próbálom lefordítani a cuccot amd64 -re. A segítséggel ez egyszerű lett volna -m64. Persze fel kellett telepíteni a libc6-dev-amd64. Szépen megfér a libc6-dev(-i386) -al.
Viszont, használok egy olyan libraryt mint a liboop, na ezzel mit kellene tenni?
Amit akartok azt cross-compile-nak hívják, és minden libből meg kell, hogy legyen a megfelelő verzió. A fontosabb libeket esetleg a disztribúciód szállítja, minden mást újra kell fordítani. Komolyabb programnál ez elég nagy szívás tud lenni...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
Én Debian :)
Azt látom, hogy a dolog ment egészen addig, amíg a liboop linkelésére nem került a sor - abból nincs meg a megfelelő library. Látszik, hogy a libc6-dev-amd64 letöltésével egy i386 architektúrájú gépre, létrejött egy /lib64 és egy /usr/lib64 - a multiarchitektúra lapjai megvannak. A saját forrásaimat gond nélkül lefordítottam amd64 -hez.
Azt nem találom, hogy a többi library -t, hogy tudom letölteni (apt-get, aptitude) úgy, hogy azok a megfelelő helyre kerüljenek? Találtam valami leírást, ami eleve úgy kezdődik, hogy ez egy elavult, minden bizonnyal hibás eljárás (pl. az átalakítás után nem fog működni az update/safe-update opció az apt-get -el).
A gondom az idő hiánya és a lustaság. Letölteni a hiányolt libraryt az architektúrához nem gond, de hova bontsam ki? Szóval homály :( Muszály lesz kitalálnom, a közeljövőben arm -hoz kell környezetet létrehoznom, mert az eszközön nem hiszem, hogy lesz eláég hely és erőforrás ezekhez a műveletekhez. Ha tudtok valamit szóljatok.
Most nem tudom hogy van, de én Gentoo-n játszottam ilyesmivel, méghozzá win-es programokat (GIMP és saját Qt-s cuccok) fordítottam.
Ott ugye minden forrásból van telepítve, de a rendszer annyira jó volt, hogy pont ugyanannyira volt nehéz a gtk win-es verzióját felrakni/fordítani, mint a simát.
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
Tudom, hogy ez amolyan skrupulus - rigolyás öreg vagyok (vagy inkább örge). Azért hogy lefordítsak egy programot egy komplett rendszert alárakni? És akkor nemsokára csinálhatok ilyen ARM guest.
Nem tetszik, bár biztos egyszerűbb.
Bocs. Ezt most értelmeznem kell! Szóval 32 bites win7 alatt futtatott virtualbox host -al napi egy-két crash? Vagy 32bites win7 alatt bármi 64 bites crash, vagy mi van?
A Virtualbox bugos Windows 7-en és ha 64 bites guest-eket futtatsz magával rántja a host OS-t is. A hibajegyek alapján egyébként csak bizonyos Core i5/i7 és újabb AMD processzorokon és több mint 4GB host ram esetében jön elő a dolog,bár az újabb hibajegyekben már ebben sem biztosak, sőt abban sem, hogy csak Windows 7-el jelentkezik. :) A vicc az, hogy fél éve nem találják a hibát.
Sokaktól halottam (olyanoktól is akinek adok a szavára), hogy a win7 stabil és jó. Lehet, de szerintem a winXP is stabil és jó - az általam ismert ms produkciók közül eddig a legjobb windows verzió. Szigorúan véve, valójában csak magához és a windows -hoz képest általában stabil. A jól telepített és átgondolt Linux -hoz képest, szerintem nem említhető egy napon. Tehát ha alap operációs rendszerben gondolkodok egy virtuális géppark felépítéséhez, akkor csakis valami pingvin.
A win7 már csak azért is gyanús, hiszen az erőforrás igénye képtelenül magas. Különösen, ha arról beszélünk, hogy le kellene fordítani egy konzolos programocskát. Persze, aki a virtualizációban él, az ezt fogja kézenfekvőnek találni, kitaposott, jól dokumentált útvonal. De valójában ez olyan mintha atomreaktort építenénk egy zsebtelep kiváltására.
Nem baj majd ha odajutok, hogy muszáj kitaposom a másik utat.
Nem fugg ossze, hogy melyik milyen arch, csak a CPU es a virtualizacios sw tudja (ma mar gyk. minden CPU es virtualizacios SW tamogatja mindkettot). 32 bites host OS-l is ugyanugy lehet 64 bites guestet futtatni, mint 64 bites hoston 32 bites guestet.
Ellenben x86/x86_64-n nehez lesz ARM-t virtualizalni.
Visszatérve a cross compile problémára - erről szól eredetileg ez a topic.
Jellemző, mint kiderül létezik egy olyan, hogy apt-cross amivel letölteni és telepíteni lehet a különféle más architektúrához szánt csomagokat, egy bibi van, a Squeeze (mostani stable) még nincs kész :( ez az én formám.
Viszont találtam egy olyat, hogy dpkg-cross ami pont erről szólna, de egyenlőre kijelenti, hogy nincs feltelepítve a libc6-dev-cross - pedig van, másként objecteket sem tudtam volna forgatni.
Illetve nem világos, hogy az architektúra opcióban "-a" a cél vagy a host architektúrát kell beírni. Próbálkozott valaki ilyennel? Most mit, a cross dologhoz az old stable Lenny -t kell használni?
En azt ajanlom, hogy egyelore inkabb 64 biten forgass 32 es 64 bites csomagokat - erre van tamogatott, stabil lehetoseg -, a 32 bites kornyezetet meg hagyd meg a 32 bites csomagok forditasara. A 64->32 irany konnyen atjarhato, a 32->64 irany sajnos annal kevesbe.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
De hát a topikcím is arról szól, hogy 64 bites architektúrán - gondolom 64 bites op. rendszer alatt - akar 32 bites kódot fordítani. Szóval nem értem, mi a topiknyitó gondja a Virtualbox-al.
"amd64 architektúrán i386 -os fordítás"
A topicban menet kozben felmerult a forditott iranyu (i386 architekturan amd64) forditas is. En elsosorban erre reagaltam, csak nem volt olyan komment, amihez hozza tudtam volna ezt erdemben fuzni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
Hááát nem tudom.. én annó kinlódtam csomót a cross compilerekkel, igaz, ott sokminden más is eltért.
A lényeg, egyszer felbasztam az agyam és felraktam 2 linuxot ( suse, redhat ) + openbsd vmware -be és nfs -en bemountoltam. Ezután a make tette a dolgát.
Hozzászólások
gcc -m32
-m32
Ez akkor gondolom minden gcc hívásnál kell - értsd a linkelésnél is?
KÖSZÖNÖM!
Az opcióval rájöttem a legkézenfekvőbb megoldásra - gcc manual - nem tudom miért nem jutott ez előbb eszembe :( Párszor már keresgéltem itt, de olyan mennyiség az opció, hogy nagyon el tudok benne veszni.
* Én egy indián vagyok. Minden indián hazudik.
Na azért mégsem olyan egyszerű ez a dolog :(
Most épp a fordítottjával próbálkozom, azaz i386 platformon próbálom lefordítani a cuccot amd64 -re. A segítséggel ez egyszerű lett volna -m64. Persze fel kellett telepíteni a libc6-dev-amd64. Szépen megfér a libc6-dev(-i386) -al.
Viszont, használok egy olyan libraryt mint a liboop, na ezzel mit kellene tenni?
* Én egy indián vagyok. Minden indián hazudik.
Amit akartok azt cross-compile-nak hívják, és minden libből meg kell, hogy legyen a megfelelő verzió. A fontosabb libeket esetleg a disztribúciód szállítja, minden mást újra kell fordítani. Komolyabb programnál ez elég nagy szívás tud lenni...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
Én Debian :)
Azt látom, hogy a dolog ment egészen addig, amíg a liboop linkelésére nem került a sor - abból nincs meg a megfelelő library. Látszik, hogy a libc6-dev-amd64 letöltésével egy i386 architektúrájú gépre, létrejött egy /lib64 és egy /usr/lib64 - a multiarchitektúra lapjai megvannak. A saját forrásaimat gond nélkül lefordítottam amd64 -hez.
Azt nem találom, hogy a többi library -t, hogy tudom letölteni (apt-get, aptitude) úgy, hogy azok a megfelelő helyre kerüljenek? Találtam valami leírást, ami eleve úgy kezdődik, hogy ez egy elavult, minden bizonnyal hibás eljárás (pl. az átalakítás után nem fog működni az update/safe-update opció az apt-get -el).
A gondom az idő hiánya és a lustaság. Letölteni a hiányolt libraryt az architektúrához nem gond, de hova bontsam ki? Szóval homály :( Muszály lesz kitalálnom, a közeljövőben arm -hoz kell környezetet létrehoznom, mert az eszközön nem hiszem, hogy lesz eláég hely és erőforrás ezekhez a műveletekhez. Ha tudtok valamit szóljatok.
* Én egy indián vagyok. Minden indián hazudik.
Most szerettem meg a Fedorát :-)
Az tudja.
Kivéve a glib-et, ott ütközik a 32 és a 64 bites...
Most nem tudom hogy van, de én Gentoo-n játszottam ilyesmivel, méghozzá win-es programokat (GIMP és saját Qt-s cuccok) fordítottam.
Ott ugye minden forrásból van telepítve, de a rendszer annyira jó volt, hogy pont ugyanannyira volt nehéz a gtk win-es verzióját felrakni/fordítani, mint a simát.
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
Küszködés helyett: VirtualBox
És ez hogy? Virtualbox virtuális amd64 -et futtatok egy i386 architektúrán? Ez tud ilyet (csak átfutottam "feature overview" -t de nem látok ilyet.
* Én egy indián vagyok. Minden indián hazudik.
Igen, VT-X/AMD-V képes proceszorokon emlékeim szerint lehet 32 bites hoston 64 bites guestet futtatni.
Tudom, hogy ez amolyan skrupulus - rigolyás öreg vagyok (vagy inkább örge). Azért hogy lefordítsak egy programot egy komplett rendszert alárakni? És akkor nemsokára csinálhatok ilyen ARM guest.
Nem tetszik, bár biztos egyszerűbb.
* Én egy indián vagyok. Minden indián hazudik.
hát, 32bites win7 alatt 64bites akármit futtatva készüljetek napi 1-2 host crashre. ez virtualbox-szal van csak.
Bocs. Ezt most értelmeznem kell! Szóval 32 bites win7 alatt futtatott virtualbox host -al napi egy-két crash? Vagy 32bites win7 alatt bármi 64 bites crash, vagy mi van?
* Én egy indián vagyok. Minden indián hazudik.
A Virtualbox bugos Windows 7-en és ha 64 bites guest-eket futtatsz magával rántja a host OS-t is. A hibajegyek alapján egyébként csak bizonyos Core i5/i7 és újabb AMD processzorokon és több mint 4GB host ram esetében jön elő a dolog,bár az újabb hibajegyekben már ebben sem biztosak, sőt abban sem, hogy csak Windows 7-el jelentkezik. :) A vicc az, hogy fél éve nem találják a hibát.
http://www.virtualbox.org/ticket/6166
http://www.virtualbox.org/ticket/8963
http://www.virtualbox.org/ticket/8202
http://www.virtualbox.org/ticket/8330
És van még pár tucat hibajegy hasonló témában. Mit mondjak elég siralmas.
Sokaktól halottam (olyanoktól is akinek adok a szavára), hogy a win7 stabil és jó. Lehet, de szerintem a winXP is stabil és jó - az általam ismert ms produkciók közül eddig a legjobb windows verzió. Szigorúan véve, valójában csak magához és a windows -hoz képest általában stabil. A jól telepített és átgondolt Linux -hoz képest, szerintem nem említhető egy napon. Tehát ha alap operációs rendszerben gondolkodok egy virtuális géppark felépítéséhez, akkor csakis valami pingvin.
A win7 már csak azért is gyanús, hiszen az erőforrás igénye képtelenül magas. Különösen, ha arról beszélünk, hogy le kellene fordítani egy konzolos programocskát. Persze, aki a virtualizációban él, az ezt fogja kézenfekvőnek találni, kitaposott, jól dokumentált útvonal. De valójában ez olyan mintha atomreaktort építenénk egy zsebtelep kiváltására.
Nem baj majd ha odajutok, hogy muszáj kitaposom a másik utat.
* Én egy indián vagyok. Minden indián hazudik.
Nem hinném, hogy a problémát a Windows 7 okozza. A Vmware Player tökéletesen stabil pl. nekem ua vason 32-bites host OS 64-bites guest-ekkel.
Nem fugg ossze, hogy melyik milyen arch, csak a CPU es a virtualizacios sw tudja (ma mar gyk. minden CPU es virtualizacios SW tamogatja mindkettot). 32 bites host OS-l is ugyanugy lehet 64 bites guestet futtatni, mint 64 bites hoston 32 bites guestet.
Ellenben x86/x86_64-n nehez lesz ARM-t virtualizalni.
----------------
Lvl86 Troll
Nem értek ennyire hozzá, de a chroot-olt környezet is jó lehet neki.
Visszatérve a cross compile problémára - erről szól eredetileg ez a topic.
Jellemző, mint kiderül létezik egy olyan, hogy apt-cross amivel letölteni és telepíteni lehet a különféle más architektúrához szánt csomagokat, egy bibi van, a Squeeze (mostani stable) még nincs kész :( ez az én formám.
Viszont találtam egy olyat, hogy dpkg-cross ami pont erről szólna, de egyenlőre kijelenti, hogy nincs feltelepítve a libc6-dev-cross - pedig van, másként objecteket sem tudtam volna forgatni.
Illetve nem világos, hogy az architektúra opcióban "-a" a cél vagy a host architektúrát kell beírni. Próbálkozott valaki ilyennel? Most mit, a cross dologhoz az old stable Lenny -t kell használni?
* Én egy indián vagyok. Minden indián hazudik.
Nézd meg az emdebian oldalát, elvben ők csinálják a keresztfordító cuccokat debian-hoz , lehet, hogy náluk már vannak squeeze-s csomagok.
http://www.emdebian.org/
Ránéztem, ígéretes. Egyenlőre azonban inkább csak annyit sikerült elérni, hogy szétesett az aptitude :(
* Én egy indián vagyok. Minden indián hazudik.
En azt ajanlom, hogy egyelore inkabb 64 biten forgass 32 es 64 bites csomagokat - erre van tamogatott, stabil lehetoseg -, a 32 bites kornyezetet meg hagyd meg a 32 bites csomagok forditasara. A 64->32 irany konnyen atjarhato, a 32->64 irany sajnos annal kevesbe.
--
De hát a topikcím is arról szól, hogy 64 bites architektúrán - gondolom 64 bites op. rendszer alatt - akar 32 bites kódot fordítani. Szóval nem értem, mi a topiknyitó gondja a Virtualbox-al.
"amd64 architektúrán i386 -os fordítás"
A topicban menet kozben felmerult a forditott iranyu (i386 architekturan amd64) forditas is. En elsosorban erre reagaltam, csak nem volt olyan komment, amihez hozza tudtam volna ezt erdemben fuzni.
--
Hááát nem tudom.. én annó kinlódtam csomót a cross compilerekkel, igaz, ott sokminden más is eltért.
A lényeg, egyszer felbasztam az agyam és felraktam 2 linuxot ( suse, redhat ) + openbsd vmware -be és nfs -en bemountoltam. Ezután a make tette a dolgát.