[Megválaszolva] Milyen C fordító Windowsra?

Fórumok

Az egyértelmű számomra, hogy ha pl Linux akkor GCC _a_ C fordító. De mi a helyzet Windowson? Mivel szokás lefordítani monjduk egy GIMP-et, vagy Python-t?

Hozzászólások

IMHO: MinGW vagy MSVC

--
A gyors gondolat többet ér, mint a gyors mozdulat.

kicsit off, de azert valamennyire a temahoz kapcsolodik:
- linux alatt mingw-vel lehet win-es binarisokat kesziteni, fasza, kiprobaltam, megy. kerdes, hogy hogyan lehet elerni hogy bizonyos retegfuggvenyek amik linuxon alapbol mennek (unistd, persze, mima's) menjenek mingw+linux alatt is? Pl fork(), pipe()? A win is multitaszk, nem hiszem hogy ezekre ne lenne implementacio, vagy wrapper.
- win alatti mingw-vel mi a helyzet? ott van fork()? ilyen szintu hordozhatosag mennyire megvalosithato? (igen, tudom, cygwin alatt megy minden, az fasza, de ott egyeb overhead-ek is vannak - cygwin.dll - ill nem lehet linux alatt elkesziteni...)

Nincs, ugyanis a Windows szalkezelese pl. teljesen mas, mint linux alatt. Windows alatt nincs fork, ott a CreateProcess-szel kell jatszani. A pipe()-re ugyanez van. Nem lehet wrapper implementaciot se igazan adni, mert tok maskepp kell parameterezni, es a linuxos API nem ad lehetoseget arra, hogy az elengedhetetlen leirokat visszaadja. Tehat mindenkepp maskepp kell megoldani, akkor meg akar a windowsos modon is meg lehet csinalni ifdeffel.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ilyenkor jó valamilyen OS feletti réteget használni. Én a Qt megoldásaival általában elégedett vagyok, de a boost is jónak tűnik. Két process között gépen belül én ma a shared memory-t tartom a leghatékonyabb megoldásnak. Megy a legtöbb OS alatt, és gyors. De ízlések és pofonok...
--
http://www.naszta.hu

Igen, kozben neztem en is ezt a winbase api-t. Ez a createprocessw() elegge meredeken kulonbozik a fork()-tol, a mingw-n belul nincs annyira jol dokumentalva. de nem is ez lenne, konkretan a szuk keresztmetszet, mert ha mondjuk (a fork-nal meg a pipe-nal maradva) meg is talalnank ezeknek a megfelelojet, egy ilyen pipe()+fork()+close([0])/close([1])+read()/write()+select() alapu kis egyszeru" multiplexelt ipc-t megvalositani (amit mondjuk csuklobol csinal az ember unix alatt), azt mar gondolom eselytelen (es ilyen szinten akkor valszeg qt-ben sem lehet lemenni, bar azt nem ismerem).

Csak azt nem ertem, miert akarod alacsony szinten megvalositani ezt a reszet, mikor rendesen meg van ez csinalva pl. a Qt-ben?

MinGW-ben nincs dokumentalva: parser error. Miert kellene a MinGW-nek dokumentalni? MSDN. Ott minden szepen le van dokumentalva, lehet olvasgatni.

En mindenkepp annak a hive vagyok, hogy ha egy feladatot meg akarok oldani, akkor ne a melegviz melegitesenek ujraimplementalasaval toltsem az ido jelentos reszet, hanem a konkret problema megoldasaval. Ha van egy framework, amit lehet hasznalni, akkor hasznalom. Persze, nekem sose lesz feladatom embedded rendszerek fejlesztese, ugyhogy abba nem tudok beleszolni, de mivel Windows a tema, itt nyilvan nem errol van szo (a WinCE API megint nagyon sokba kulonbozik, abba mar bele se menjunk).
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Csak azt nem ertem, miert akarod alacsony szinten megvalositani ezt a reszet, mikor rendesen meg van ez csinalva pl. a Qt-ben?
inkabb forditva: adott egy tonna kod, ami mar unix rendszereken megy, hasznalja ezeket az eszkozoket, oszt tfh hogy nem lenne baj, ha ezek futnanak win alatt is. kis faradsaggal, ugy, hogy a binarist is maga't le lehet forditani linux alatt.

az egy mas kerdes, kicsit szubjektiv is, hogy egy fork()+pipe() kaliberu problemara mellett egy qt az nem is kicsit agyu-vereb. de persze ketsegtelen, hogy hordozhato lesz qt-vel: valamit valamiert.

Amennyire most a cygwin honlapját olvasgatom, ezekhez a fork-exec szerű dolgokhoz mindössze egy cygwin1.dll-kell.

Nyilván, ha bash-t, sed-et meg hasonlókat akarsz használni, akkor kellenek azok is...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Amennyire most a cygwin honlapját olvasgatom, ezekhez a fork-exec szerű dolgokhoz mindössze egy cygwin1.dll-kell.

Így van. Például az lbzip2.exe (ehehe... bocs) simán elfut egy libbz2.dll + cygwin1.dll páros kíséretében. (Legalábbis azt hiszem.)

Ezen oldal szerint ha az alkalmazás valamilyen OSI szerint elfogadott nyíltforrás-licensz alatt van terjesztve, akkor a cygwin1.dll még csak nem is kényszeríti GPL alá az alkalmazást. Vagyis simán terjeszthető az OSI-nyílt program bináris formában (.exe + cygwin1.dll) egy olyan oldalon, ahonnan még az alábbiak mindegyike is letölthető: (1) alkalmazás illeszkedő verziójú forrása, (2) cygwin1.dll illeszkedő verziójú forrása (példának lásd ezt -- a lap tetején leírja, mi minek a forrása).

(Plusz a további lib-ekre is figyelni kell, természetesen.)

Úgy sejtem, hogy ha egy rendes Cygwin release-ben található cygwin1.dll forrására van szükségünk, akkor meg lehet hozzá keresni itt a megfelelő CVS tag-et (pl. "cygwin-1_7_3-release"), majd ezzel a tag-gel rendesen egy cvs export -kv:

$ cvs export -kv -r cygwin-1_7_3-release winsup

és az eredményt lehet csomagolni.

Haaat, a fene tudja. En ezt olyan... lusta megoldasnak erzem. Ha valaki windowsra (is) fejleszt, lehet jobb lenne, ha tisztaban lenne a mukodesevel, nem csak a fork-exec miatt, hanem ugy altalaban is. Ez sajna nem mindig jellemzo.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nezd, jelen pillanatban az az tenyalladek, hogy a Microsoft szarik magasrol a POSIX ajanlasokra, es baromi keves dolog van belole implementalva a Windows API-jaban. Emiatt lehet sirni, lehet duhongeni, egyet nem lehet: valtoztatni rajta. Jelen pillanatban kettofele kerulomegoldas letezik
- #if defined(WIN32) && !defined(__Cygwin__)
- valamilyen framework hasznalata, ahol ezt megoldottak

Az elso verziohoz nagyon el kell merulni a WinAPI rejtelmeiben ahhoz, hogy korrekt megoldas szulessen.

A masodik plusz elonye az, hogy az ilyen framework-ok altalaban mas tekintetben is egesz kellemes megoldasokat tudnak nyujtani, es lehet, hogy az alkalmazasban mashol is egyszerubb lesz az ember elete.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nem hülyeség amit szeretnél, ezt akarták a cygwin fejlesztői is, és ezért van cygwin.
Szinte biztos vagyok benne hogy lehet cygwin-re fordítani linux alól...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Én szeretem még az intel compliler-t is. 32 bit-en borland sem rossz.

Ha CMake alapú a projekt, akkor bármelyiket használhatod. ;)

--
http://www.naszta.hu

imho MSVC, de ott a Borland C forditoja is, meg a MinGW-e is.
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Ha C-rol van szo es nem C++, akkor az MSVC nem feltetlenul jo valasztas, mert pl. tobb hasznos C99 feature-t nem tamogat (es legalabbis regebben egyeb gondok is voltak vele C tamogatas teren, nem tudom azota jobb lett-e).
MinGW-t javaslom (gcc), vagy az intel c compiler nem tudom van-e windowsra.

- Use the Source Luke ! -

MS Visual Studio 6.0-val volt sok gond (nem volt szabványos). Az MSVC 2005 (8.0) óta sokat ment az MS a szabványok felé. Szerintem ma teljesen korrektül tudja azokat. Az én javaslatom az, hogy vagy MSVC 2005 vagy MSVC 2008-at használjon, ha MSVC a compiler. Erősen javasolt a service pack-ok használata, mert MSVC 2005 SP nélkül memory leak-es az STL-ben.

--
http://www.naszta.hu

Par alapveto dolog:
- Does not understand named initializers;
- Does not understand variable-length arrays;
- Does not understand the inline keyword (understands _inline though);
- Does not understand compound litterals;

lasd itt

De voltak vele mas problemak is regebben (vagy most is, nem tudom).

- Use the Source Luke ! -

Valóban még most sem teljes a kép. Azt azonban el kell ismerni, hogy nagyságrendekkel jobb, mint a 6.0 volt. Minimális különbségek egyébként a GCC-ben is vannak, de ma már lehet olyan ötleted, hogy olyan szabványos kódot írsz, ami gyakorlatilag mindenen fordul. :)

--
http://www.naszta.hu

Tudom, hogy ezek nincsenek benne implementálva (még), de ezek nélkül azért egész kényelmesen lehet fejleszteni. Ma már - szerintem - minden open source cuccot úgy érdemes írni, hogy lehetőleg a 3 nagy compiler (gcc, msvc 8.0 <=, intel cc) alatt forduljon.

--
http://www.naszta.hu

Cygwin-t használtam eddig, ha néha fordítottam valamit Windows alá, és a binárisnak szüksége van a Cygwin dll-re a futáshoz.
A MinGW-nél ez hogy működik? Lehet önállóan futásképes programot fordítani, vagy ehhez statikus linkelés kell?
Lehet-e csak a C fordítót telepíteni, vagy itt is kell mindenféle GNU program még?

Mivel szokás lefordítani monjduk egy GIMP-et, vagy Python-t?

MinGW-vel.

Köszönöm a válaszokat!

--
Keep it simple, stupid.

Én is MinGW-vel próbálkozok Win alatt, de szerintem ne az igazi:
a lefordított fájl mérete kb. másflészer akkora (24KB), mint amit Borland Turbo C-vel fordítottam (17KB), emellett fele olyan gyors ugyanaz a kód...
--
Azt akarom, hogy az emberek ne kényszerből tanuljanak, hanem azért, mert tudni akarnak.

Azért a korábban felsoroltakon kívül létezik Win-re az LCC, a Pelles-C, a Watcom-féle C/C++ fordító (asszem mostanában OpenWatcom-nak híjják, és a maga idejében az egyik leggyorsabb kódot fordította), most már mintha menne Win alatt az LLVM-féle CLANG. Választék az van.

Egyiknél sem tudtam, hogy létezik ilyen... o_O Borland Turbo C IDE-ben csak F9-et nyomtam, gcc pedig a -Wall paraméterekkel fordította le.

Egyszerű konzol alkalmazás, van benne memória és fájlkezelés is.
Hozzá kell tenni, hogy a Turbo C-vel készített prog WinXP alatt ezt az üzenetet írja ki az első futtatásnál:
C:\WINDOWS\SYSTEM32\HASPDOS.SYS
--
Azt akarom, hogy az emberek ne kényszerből tanuljanak, hanem azért, mert tudni akarnak.

linuxon a C fordítót icc-nek hívják