setup problémák

Clipper, CCC

Sziasztok ,

A $CCCDIR/tools/crypto fordítása Fedora core 5 alatt hibára fut, oka:

/usr/include/openssl/md5.h-ban az alábbi függveny
unsigned char *MD5(const unsigned char *d, unsigned long n, unsigned char *md);
szignaturája megváltozott:
unsigned char *MD5(const unsigned char *d, size_t n, unsigned char *md);

ezert javaslat:

$CCCDIR/tools/crypto/md5.cpp-be berakni: stdio.h
$CCCDIR/tools/crypto/sha1.cpp-be berakni: stdio.h

(benne is voltak, de ki vannak kommentelve)

  • 6942 megtekintés

( vadzoltan | 2007. 01. 20., szo – 19:13 )

Hi,

xml-RpcServer,windows
$CCCDIR\tools\m.bat: call bapp_w320 -lccc2_xmlrpc javitando ccc3_xmlrpc-re
Köszi

Vad Zoltán

( imp | 2007. 01. 21., v – 14:44 )

iszonyatosan fájdalmas lefordítani ezt a ccc3 fordítót, de legalábbis a leírás alapján lehetetlen...

itt tartok:
/opt/ccc3/trunk -ba checkoutoltam a 105-ös revisiont.

beállítottam pár környezeti változót:
$ env | grep ^CCC
CCCDIR=/opt/ccc3/trunk
CCCBIN=lin
CCCUNAME=linux

és el vagyok veszve a szkriptek között, egyik se képes hiba nélkül lefutni, meg hogy melyik mire való azt se nagyon lehet tudni, van vagy ötezer .bat meg .b, kissé kaotikus.

Egen, készül már a Wiki-re egy jobb leírás. Első körben a Windowsos, de az rögtön készen is van.
Javasolnék még 1-2 változót beállítani:
CCC_XSIZE=80x36
CCC_XFONT=ccc8x16
OREF_SIZE=1000000
PATH=$CCCDIR/usr/bin/$CCCUNAME:$PATH
LD_LIBRARY_PATH=$CCCDIR/usr/lib/$CCCBIN:$LD_LIBRARY_PATH
CCCTERM_CONNECT=$CCCDIR/usr/bin/$CCCUNAME/terminal.exe

Szerintem ezek segíteni fognak, de ha nem, akkor mondd meg lécci, mi az error.

w

( Wintermute | 2007. 01. 21., v – 15:21 )

Csináltam két Wiki oldalt a CCC telepítéséről, egyelőre elég elnagyoltak, de a semminél többek. A http://wiki.hup.hu/index.php/CCC címen elérhetők, az lenne a kérésem, hogy akinek hozzátennivalója van, vagy hibát talál benne, az szóljon, és javítok rajta.

w

ui: Zoli, esetleg Fedora 5-ön valami különbség?

Megnéztem, hozzászólás:

Nincs feltüntetve, hogy CCC2 vagy 3-ról van-e szó, de gondolom a 3-ról. Viszont a CCC_XSIZE és CCC_XFONT a CCC2 változói. A CCC3-ban ezeknek a

CCCTERM_FONTSPEC (default: -misc-console-medium-r-normal--16-160-72-72-c-80-iso10646-1)

CCCTERM_SIZE (default: 80x25)

felelnek meg. A CCCTERM_FONTSPEC-nél fontos, hogy UTF-8 fontot kell megadni. Meg kéne említeni, hogy a CCC3 (többé-kevésbé kizárólag) az UTF-8 környezetet támogatja, a CCC2 pedig a Latin1/2-t.

--
CCC3

Kipróbáltam a vindózos leírást, nagyon jó, köszönet érte.

Megjegyzések azért vannak:

1) Az svn nekem nem közvetlenül a CCC3-ba tette az anyagot, hanem a trunk-ba.

2) Nincs szó a külső függőségekről. Lefordult az install során a crypto könyvtár, de csak azért, mert nálam installálva van az openssl. Másnál elhasalna. Mi legyen a megoldás, vegyük ki kezdetben a crypto fordítását?

Másik ügy: A courier new fonttal, fekete alapon fehérrel, 15' monitoron nem olvasható a z. (Mondjuk ezt a monitort csak ideiglenesen használom, mint most a Vindózhoz, amim általában nem szokott lenni nekem.) Kéne valami megoldás, elsősorban egy olyan konzol font, amit fekete alaphoz terveztek.

--
CCC3

Hmm... Consolas a legjobb terminálhoz. Ötletes módon lehet beszerezni: Le kell asszem tölteni a office 2007 conversion packot a régebbi office-khez. Consola*.ttf .

Ha kell el tudom dobni. Elvileg nincs korlátolva a használata, csak szerkeszteni nem lehet. De ez nem tuti, mindenesetre MS licenc vonatkozik rája

( mrev | 2007. 01. 21., v – 16:02 )

Mivel kritika érte a CCC installációt, ellenőriztem a folyamatot. Elkészítettem ezt a nagyszerű scriptet:

#!/bin/bash

export CCCDIR=$(pwd)/trunk
export CCCBIN=lin
export CCCUNAME=linux
export CCCTERM_CONNECT=$CCCDIR/usr/bin/$CCCUNAME/terminal.exe

export PATH=.:$CCCDIR/usr/bin/$CCCUNAME:$PATH
export LD_LIBRARY_PATH=$CCCDIR/usr/lib/$CCCBIN:$LD_LIBRARY_PATH

svn checkout svn://ccc.comfirm.hu/ccc3/trunk
cd trunk
i.b

A letöltés és fordítás hiba- és warningmentesen lefutott.
A környezet: Ubuntu Dapper (64 bit), gcc 4.0.3.

Az persze nehéz kérdés, hogy mik vannak telepítve az alapkonfigurációhoz képest. Írva vagyon az olvass.html-ben, hogy a telepítő nem ellenőrzi előre a külső függőségeket, hanem belefut a hibákba. Fel van tételezve a fejlesztőről, hogy ismeri a fejlesztőeszközöket, vagy legalább felismeri, hogy mi hiányzik és pótolja a hiányzó dolgokat. Úgy emlékszem, hogy Ubuntun már a C/C++ fordító sincs fenn alapból, nekem is mindig gondot okoz, hogy összevadásszam a szükséges csomagokat. Kellenek az X fejlesztő csomagok. A ccc3_crypto könyvtárhoz kellenek az openssl fejlesztő csomagok. A jterminalhoz kell egy Sun-os Jáva és jar készítő. Az SQL csatolóhoz kell a Postgres, amit én forrásból szoktam installálni (az Oracle kliens fordításához nem kell semmi). A GTK csatolóhoz kellenek a GTK fejlesztő csomagok. Én sem emlékszem mindenre, azt sem tudom pontosan, hogy hívják a csomagokat, különféle rendszereken (Ubuntu, Suse, BSD, Solaris...) máshogy hívják őket, más és másképp megy a telepítésük. Vindózon megint csak másképp.

Aki értelmesen és türelmesen kapálódzik egy kicsit, az át tud jutni a nehézségeken, aki leírja, hogy hol akadt el, annak segítünk.

--
CCC3

...ha már így mondod, esélyes, hogy slackware-hez csinálok csomagot, de fordítási módszert kicsit átszabnám; az m fájlok meg a build nem nagyon jönnek be.. a /tmp-t használnám az egyes fordítási lépések közti tempfileok tárolóhelyéül, meg a file-ba belepakoljuk a fordítási kapcsolókat helyett is inkább egy olyat használnék mint ahogy a `gtk-config` parancs megadja a fordítási kapcsolókat, stb.

Lehetnek más jó megoldások is, de gondold meg, hogy a meglevő rendszer megy vindózos MSC fordítóval is. (Régebben Watcommal és Borlanddal is ment. Ha lennének életképes új változataik, újra támogatnám őket.) Azonkívül rengeteg programunk fordul a builddel (winen/UNIX-on egyformán), és maga a CCC fordítás is a builddel megy. Ehelyett egy másikat csinálni, elég nehéz munka, és nem biztos, hogy jobb lesz.

Külön utálom a make programot és az ezersoros makefiléket.

Ha megnézed, a build egy egyfilés (1000 sor) CCC program, ami kitalálja, hogy milyen fordítási műveleteket kell végezni. Vannak nyilvánvaló hibái, de a haszon/hossz mutatója világcsúcsközelben jár. Szóval érleld még egy ideig a gondolatot, hogy tényleg le akarod-e cserélni.

--
CCC3

az előnye számomra hátrány: ne ő találja ki, hogy mit kell lefordítani, hanem én explicit akarom megmondani, hogy mit hogyan. látom én benne azt, hogy ez vindoze alatt is megy, de nekem a unix way szimpatikusabb azokban az esetekben, amiket említettem.

más. ha írok egy hello worldot, akkor hogy adom meg neki parancssorban azt, hogy ezt most g++ -Os -el fordítsa? ha ilyen épp nincs is, szívesen látnék olyat, hogy:

$ ccc3 x.prg y.prg z.prg -o bin -cxx-opts '-Os -Wall'

Hát azt látod, hogy nincs ilyen CCC3 fordításvezérlő, hanem a build működteti a scriptjeit.

A build minden prg-t lefordít, amit a megadott forrásdirectorykban talál. Ha nem kell minden prg-t belefordítani a projektbe, akkor a szükségtelen darabokat át kell vinni máshová, pl. egy save nevű helyre. Tehát nem szoktuk felsorolni a forrásokat. A build a prg-ken kívül még 10 másfajta forrást is automatikusan fordít (cpp, c, lex, lem,...), azokat sem kell felsorolni.

A C fordítási opciók az CCCDIR/usr/options/lin/compile.opt filében vannak megadva. Van valami opció, amivel ehelyett egy másikat használ (most nem emlékszem a nevére). És van ugye a BUILD_CFG, ebben egy olyan filét lehet megadni, amit az opciókhoz hozzáad, erre még sosem volt szükség, azért nem derült ki az általad talált hiba. Namost a CCC könyvtárak lefordultak valamilyen C flagekkel. Nem biztos, hogy azután célszerű ezeket összelinkelni, valamilyen más opciókkal fordított objectekkel. Emiatt a C opciók nem szoktak gyakran változani.

Még az előzőhöz. A win/UNIX hordozhatóság nem csak azt jelenti, hogy ugyanaz a forrás fordul itt és ott, hanem hogy külön makefile sincs, sőt egyáltalán nincs makefile. Ezért majdnem olyan egyszerű a fordítás, mintha Pythonnal dolgoznál.

--
CCC3

..jut eszembe, találtam még tegnap egy furcsaságot, most fejből írom, és azt hiszem, ez igy van benne a prg2obj.bat-ban, de lehet hogy már a tracelés következtében fejtettem ki ilyenre: 


exoprt BUILD_OPT="compile.opt"

cat $CCCDIR/usr/include/options/$CCCBIN/gcver.opt   >>$CMPOPT
cat $CCCDIR/usr/include/options/$CCCBIN/$BUILD_OPT  >>$CMPOPT

szóval a BUILD_OPT-ot mondjuk overrideolhatod úgy, hogy 

BUILD_OPT="compile.opt /valami/masik/konyvtar/custom_compile.opt"

,
de hogyha az elejerol elhagyod a compile.opt-ot, és whitespaceval kezdodik a valtozo erteke, akkor dob egy errort is.

ez a build rendszer honnan jött egyébként?

A build a prg-ken kívül még 10 másfajta forrást is automatikusan fordít (cpp, c, lex, lem,...), azokat sem kell felsorolni.

és ha nekem cxx-eim vannak? vagy ha épp csak a .c-ket kell lefordítani? erre nincs BUILD opció?
mondjuk ilyen, hogy: BUILD_SOURCES="cpp c lex lem". mi van, ha nekem Cpp-im vannak case sensitive fs-en?

Saját agyszülemény.

Build rendszer = 1 darab CCC program + ext2ext.bat scriptek.

Kis programra gondolj, 1 darab ezer soros forrás. A scriptek megfelelnek a make implicit szabályainak. Ezeket minden fájltípusra és minden platformra külön meg kell írni.

A buildnek nem filéket mondunk (hogy azokat fordítsa), hanem directorykat, ahol a fordítandó források vannak. Ha egyszer meg van neki adva (a -d opcióval) egy directory, akkor ott minden forrást (amit felismer) le fog fordítani. A -d opció defaultja . (a pont).

Ha valamit _nem_ akarsz lefordítani, akkor azt olyan helyre kell tenni, ami _nincs_ megadva a buildnek forrásdirectoryként. Ez praktikus, mert a directoryk tartalma összhangban van a projekttel.

Ha cpp-k helyett cxx-eid vannak, az gond. Vagy átnevezed őket cpp-re, vagy megtanítod a buildet a cxx-ekre. Ez úgy menne, hogy a buildbe fel kell venni +1 sort, plusz meg kell írni a cxx2obj.bat scripteket. Ilyen helyzetben én az átnevezést választottam. Persze kellemetlen, ha a cxx-ek egymást inkludolják.

Még egy dolog: Vannak eredeti cpp-k, és vannak olyanok is, amik a (prg,lem,lex)->cpp fordításból keletkeznek. Vigyázni kell, hogy ezek ne keveredjenek össze. A generált cpp-k ezért mindig a ppo directoryba kerülnek. Biztos látod, hogy a fordítás során melléktermékként létrejövő fájlok külön könyvtárakba kerülnek. A buildnek nincs clean opciója, hanem egyszerűen le szoktuk törölni az obj directoryt.

--
CCC3

Kezdem érteni a miértet, csak kicsit zavar hogy nem használja ki a unix adta lehetőségeket; de meg lehet szokni biztos.
Ami még zavar, az a dolog kötelező jellege. Mint ahogy nem használok mindig make-t sem, ha itt sem akarok buildet használni, akkor mit tegyek? Ezért gondolkozok az alternatív megoldáson..

Ha megnézed a build-et magát, nem sok mindent csinál, hanem scriptekre bízza a munka oroszlánrészét. Ezért egyáltalán nem gond, ha csinálsz olyan make szabályokat, amik egy az egyben reprodukálják mondjuk a prg2obj.bat működését, és kézzel felsorolod a make-nek a prg-ket, amiket le akarsz fordítani. De én is azt javaslom, hogy dőlj hátra és lazíts, hagyd, hogy a build dolgozzon helyetted. Nem nagy kaland olyan könyvtárszerkezetet kialakítani, hogy minden a helyén legyen benne, és a többi ezáltal meg is van oldva. Nagy kényelem ám! :)

w

( imp | 2007. 01. 22., h – 01:13 )

épp a .bat fájlokat tracelem, találtam egy ilyet: 


$ cat -n $CCCDIR/usr/build/_compile.b
    18  if ! test -f $BUILD_CFG; then
    19      cat $BUILD_CFG >>$CMPOPT 
    20  fi

az a cat vagy hibát dob, vagy nem fut le...

( pásztortűz | 2007. 01. 23., k – 15:05 )

Varning mentesen fordult a CCC3 win fölött. A hello.prg is.
A Hello Word! helyett küldött egy
connect_to_terminal failed errno=0 -t.

._.

Én is láttam a hibaüzenetből, hogy nem tud a terminál elindulni, de nem látok hibát a változó beállításában.
A ccc3.bat fájlom a következőképp néz ki:
set CCCDIR=C:\CCC3
set CCCBIN=mng
set CCCUNAME=windows
set CCCTERM_CONNECT=%CCCDIR%\usr\bin\%CCCUNAME%\terminal.exe
set PATH=%PATH%;%CCCDIR%\usr\bin\%CCCUNAME%
set PATH=%PATH%;%CCCDIR%\openssl\bin
set PATH=%PATH%;C:\MinGW\bin
set PATH=%PATH%;C:\CCC3\zip
set INCLUDE=%CCCDIR%\openssl\include;C:\MinGW\include
set LIB=%CCCDIR%\openssl\lib;C:\MinGW\lib
set OREF_SIZE=1000000
set JTERMINAL=start /b java -jar %CCCDIR%\jt\jterminal\jterminal.jar localhost JTPORT
set PATH=%PATH%;C:\PF\Far
title "CCC3-GCC environment"
Far.exe

Ha lát valaki benne hibát szóljon!

Köszönöm.

._.

Telepítve van a TCP? Bár valószínűtlen, hogy nem, hiszen interneten vagy (hacsak nem egy másik gép).

Lehet részletekben próbálkozni. Bemész a CCCDIR/terminal/xtest-be, lefordítod az ottani programokat, elindítod az x scriptet, ami elindítja az xstart listenert, utána egy másik ablakban elindítod a terminált (paraméterek nélkül), amire fel kell jönnie a programnak, vagy valami hibaüzenetnek, amitől okosabbak leszünk.

--
CCC3

x script a következő log-t adta:

bind failed (errno=0) {{socket, 1208},{name,Test Program},{env,{CCCTERM_CONNECT=SOCKET:$(SOCKET)}},{interface,NIL},{port, 55000},{workdir,NIL},{command,proba1.exe}}
Sajnos a TCP/IP lelkét nem ismerem, de mintha ott lenne a hiba.

A terminal.exe-nek így nem akadt dolga.
Köszönöm.

._.

Mindenkinek javaslom, hogy windows-on szolgáltatás szintjén lője le a tűzfalat!
Nagyon nagyon nagyon sok problémára megoldás ez, biztonságot pedig nem jelent a megléte.

Lassan nekiveselkedek én is kíndózon létrehozni ccc-s környezetet, de már csak a miheztartás végett, és hogy kipróbáljam.

Magamnál azt látom, hogy a 2K enged védett portra (pl. 81) bindelni. Viszont ugyanazt a hibaüzenetet kapom, mint te, ha valamivel megfogom az 55000-es portot, pl. ha kétszer indítom az x scriptet. Tehát az a kérdés, nem fogja-e valami az 55000-es portot? Egyébként az automatikus konnektnél a szerver keres egy szabad portot egy elég nagy intervallumból, tehát úgy néz ki, mintha valami szándékosan lefoglalná az összes portot.

--
CCC3

Nos, kipróbáltam két natív Windows-on ma a témát. Az egyiken Symantec akármicsoda volt, ilyen színes csilivili, ami szerintem tűzfal is, és a CCC remekül működött vele.
A másikon ZoneAlarm volt, és maga a terminal.exe, mint olyan, működött rendesen, ha neten lévő hostra mentem ki. De lokálisan egyszerűen nem tud semmilyen portra rábind-elni. xstart ugyanígy járt, az sem tudott semmilyen portra rábind-elődni. Ez akkor is igaz maradt, ha a Windows tűzfalat leromboltuk, és a helyét felszántottuk, meg a ZoneAlarm-ot is. Úgy tűnik, a ZoneAlarm valamit lecserél a kíndózban, amitől véglegesen képtelenné válik arra, hogy lokális alkalmazások server socketet nyissanak rajta. Szipacs.
Pásztortűz, ZoneAlarm-od van?

w

Nem! Már régóta nem használok ZoneAlarm-ot. Nekem egy Linksys WRV54G-es router mögött van a gépem. Ennek van tűzfala, de próbáltam úgy is, hogy
leakasztottam róla, de hiába. Kikapcsoltam a windows saját tűzfalát, de nem segített. Én egyébként arra gyanakszom, hogy valamelyik SP frissítéssel qrta el BG. Ugyanis állandóan a felfedezett biztonsági rések javítására hívatkoznak, amikor frissítést kezdeményeznek. Az nagy segitség, hogy tudom, hogy a lokális üzemnél tiltódik le művelet. Mindenesetre nagyon köszönöm mindenkinek a segitséget. Nem adtam fel és tovább próbálkozom. Jelzem majd, ha sikerült.

._.

Továbbra sem értek a Windowshoz, XP-hez 2 méternél közelebb még nem voltam, de egy-két felvetés:

Van-e loopback (127.0.0.1) interfész? Nálam (2K) van, noha az ipconfig/all nem mutatja. A

c:\winnt\system32\drivers\etc\networks

filében van egy olyan sor, hogy

loopback 127

Van-e ilyen a gépeteken? Nem tudom, hogy ez mit okoz,csak érdekelne.

A hibát produkáló gépen egy GetLastError() hívással kéne közelebbi infót kapni a hibáról. Egyébként gáz, hogy vindózon sikertelen bind() után errno==0.

--
CCC3

( jancsy | 2007. 01. 26., p – 10:31 )

A HupWiki útmutatásai szerint telepítem fel a ccc-t windows-os környezetre. Szépen alakul minden, már a ccc.bat-ra mutató parancsikon is kint van az asztalon, de ccc3 könyvtáramban nincs trunk. Az utasításokat lépésről lépésre követtem. A MinGW egy korábban letöltött verzió. Esetleg ez lehet a hiba?

Nem, természetesen a végleges executable-hez nem kell a CCC environment. Linuxon szükség van az .so file-okra és a terminal.exe-re, Windowson csak a terminal.exe kell, és a CCCTERM_CONNECT környezeti változó. CCC2 és Windows esetén meg semmi, csak az exe.

w

( mrev | 2007. 02. 04., v – 15:27 )

Van egy hiba, amin nem tudunk túljutni: Egyes XP konfigurációkon nem működik a terminállal való konnektálás (bár olyan XP is akad, amelyiken működik).

Nincs módomban XP-n tesztelni, mert nincs XP-m, és nem is akarok ilyesmit beszerezni. A Win2K gépemből (ami ritkán van összeszerelt állapotban) nem tudtam hasonló hibát kicsiholni. Tehát arra számítok, hogy azok, akiknél a probléma fellép segíteni fognak a javításban, és elküldik a hibaüzeneteket, vagy esetleg konkrétan ki is találják, hogy mi van elrontva. Lehet, hogy csak a TCP konfiguráció van elszúrva, ennek a kibogozása ugyanolyan érdekes volna.

E célból pár napja javítottam a vindózos hibaüzenetekben, ehhez képest azóta nem kaptam egy error jelentést sem, tehát sajnos nincs előrelépés. Kéne lökdösni egy kicsit az ügyet.

--
CCC3

( cARGo- | 2007. 02. 07., sze – 22:34 )

Sziasztok,

Linux alá próbálnám telepíteni ezt a csodát, de az install.b, elszáll az utolsó során, és a "mklink.exe not found" üzenettel kilép. Tényleg nincs is ilyen file a trunk könyvtárban. Ez még senkinél nem volt probléma?

ja, most látom, hogy nincs build.exe-m sem, az alábbi hibaüzenet jön:


./mk_ccc: line 2: /home/cargo/ccc/trunk/usr/bin//__unix.b: Nincs ilyen fájl vagy könyvtár
cp: stat `objlin/*.lib' sikertelen: Nincs ilyen fájl vagy könyvtár
cp: stat `objlin/*.so' sikertelen: Nincs ilyen fájl vagy könyvtár
./mk_ui_: line 2: /home/cargo/ccc/trunk/usr/bin//__unix.b: Nincs ilyen fájl vagy könyvtár
cp: stat `_ui_/*.lib' sikertelen: Nincs ilyen fájl vagy könyvtár
cp: stat `_ui_/*.so' sikertelen: Nincs ilyen fájl vagy könyvtár
./mk_uic: line 2: /home/cargo/ccc/trunk/usr/bin//__unix.b: Nincs ilyen fájl vagy könyvtár
cp: stat `_uic/*.lib' sikertelen: Nincs ilyen fájl vagy könyvtár
cp: stat `_uic/*.so' sikertelen: Nincs ilyen fájl vagy könyvtár
which: no build.exe in (.:/home/cargo/ccc/trunk/usr/bin:/home/cargo/ccc/trunk/usr/bin/linux:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/bin:/opt/ant/bin:/usr/lib/java/bin:/usr/lib/java/jre/bin:/usr/share/texmf/bin:.:/usr/local/pgsql/bin:/home/cargo/bin:/usr/share/texmf/bin)
ldd: missing file arguments
Try `ldd --help' for more information.
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix0.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix0.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix0.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix0.b: line 4: build.exe: command not found
cp: stat `objlin/*.lib' sikertelen: Nincs ilyen fájl vagy könyvtár
cp: stat `objlin/*.so' sikertelen: Nincs ilyen fájl vagy könyvtár
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unixc.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix0.b: line 4: build.exe: command not found
cp: stat `objlin/*.lib' sikertelen: Nincs ilyen fájl vagy könyvtár
cp: stat `objlin/*.so' sikertelen: Nincs ilyen fájl vagy könyvtár
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix0.b: line 4: build.exe: command not found
cp: stat `objlin/*.lib' sikertelen: Nincs ilyen fájl vagy könyvtár
cp: stat `objlin/*.so' sikertelen: Nincs ilyen fájl vagy könyvtár
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unixc.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unixc_btbtx.b: line 5: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix0.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unixc.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unixc.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix0.b: line 4: build.exe: command not found
cp: stat `objlin/*.lib' sikertelen: Nincs ilyen fájl vagy könyvtár
cp: stat `objlin/*.so' sikertelen: Nincs ilyen fájl vagy könyvtár
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix0.b: line 4: build.exe: command not found
cp: stat `objlin/*.lib' sikertelen: Nincs ilyen fájl vagy könyvtár
cp: stat `objlin/*.so' sikertelen: Nincs ilyen fájl vagy könyvtár
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix0.b: line 4: build.exe: command not found
cp: stat `objlin/*.lib' sikertelen: Nincs ilyen fájl vagy könyvtár
cp: stat `objlin/*.so' sikertelen: Nincs ilyen fájl vagy könyvtár
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unixc.b: line 4: build.exe: command not found
which: no z.exe in (/home/cargo/ccc/trunk/usr/bin:/home/cargo/ccc/trunk/usr/bin/linux:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/bin:/opt/ant/bin:/usr/lib/java/bin:/usr/lib/java/jre/bin:/usr/share/texmf/bin:.:/usr/local/pgsql/bin:/home/cargo/bin:/usr/share/texmf/bin)
ldd: missing file arguments
Try `ldd --help' for more information.
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unixc.b: line 4: build.exe: command not found
which: no zgrep.exe in (/home/cargo/ccc/trunk/usr/bin:/home/cargo/ccc/trunk/usr/bin/linux:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/bin:/opt/ant/bin:/usr/lib/java/bin:/usr/lib/java/jre/bin:/usr/share/texmf/bin:.:/usr/local/pgsql/bin:/home/cargo/bin:/usr/share/texmf/bin)
ldd: missing file arguments
Try `ldd --help' for more information.
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
./install.b: line 108: m: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unix_.b: line 4: build.exe: command not found
/home/cargo/ccc/trunk/usr/bin/linux/bapp_unixc.b: line 4: build.exe: command not found
./install.b: line 125: mklink.exe: command not found

a telepítéskor a hupwiki-ben leírtak szerint jártam el...

Előre is köszönet a meglátásokért...

Be kell állítani ezeket a környezeti változókat:

export CCCDIR=/home/cargo/ccc/trunk
export CCCBIN=lin
export CCCUNAME=linux
export CCCTERM_CONNECT=$CCCDIR/usr/bin/$CCCUNAME/terminal.exe

export PATH=$CCCDIR/usr/bin/$CCCUNAME:$PATH
export LD_LIBRARY_PATH=$CCCDIR/usr/lib/$CCCBIN:$LD_LIBRARY_PATH

és újraindítani install.b-t vagy i.b-t.

Nálad minimum a CCCUNAME nincs beállítva, ami az első sorból látszik
./mk_ccc: line 2: /home/cargo/ccc/trunk/usr/bin//__unix.b: Nincs ilyen fájl vagy könyvtár
Ennek kéne lenni:
/home/cargo/ccc/trunk/usr/bin/$CCCUNAME/__unix.b
==>
/home/cargo/ccc/trunk/usr/bin/linux/__unix.b

--
CCC3

igen, sajnos látom
--> basszus kimaradt egy "export" a .bashrc-ből

cat .bashrc:

export CCCDIR="/home/cargo/ccc/trunk"
export CCCBIN="lin"
CCCUNAME="linux" # hülye vagyok pont
export PATH="$CCCDIR/usr/bin:$CCCDIR/usr/bin/$CCCUNAME:$PATH"
export LD_LIBRARY_PATH="$CCCDIR/usr/lib/$CCCBIN:$LD_LIBRARY_PATH"
export CCCTERM_CONNECT="$CCCDIR/usr/bin/$CCCUNAME/terminal.exe"
export $CCCTERM_SIZE="80x36"
export OREF_SIZE="1000000"

kösz a választ

Túlzásnak tartom a Wintermute által javasolt

OREF_SIZE=1000000

beállítást. Ez akkor kell, ha a program 1 millió memória objektumot akarna egyszerre tárolni. Átlagos programnak erre nincs szüksége. Hátránya viszont, hogy nagyra hízik a program és akadozó lesz a szemétgyűjtés.

Ha tényleg sok memóriaobjektum kell, akkor egy indítóscriptbe érdemes beleírni az OREF_SIZE beállíást, vagy pedig a magában programban is be lehet állítani. A default egyébként 40000, ha jól emlékszem.

--
CCC3

Hát, én hosszú évekkel ezelőtt egyszer úgy jártam, hogy egy nagy és csúnya alkalmazásom X óra futás után közölte velem, hogy hát neki bizony elfogyott az OREF. Oké, nem volt jól megírva, ez kétségtelen tény, de akkor megfogadtam, hogy márpedig ezt az üzenetet még egyszer nem akarom látni, és feltoltam egymillióra :D
Nem érzem, hogy a programjaim nagyra híztak volna, vagy akadoznának. De átírom a Wikiben, nehogy valaki más meg érezze. :)

w

( mana1 | 2007. 02. 09., p – 17:54 )

Helló!

Windows Xp-n nem tudom lefordítani.
.Cpp-t még csinál, de .obj-k már nem keletkeznek. Így csak az .obj does not exist-eket kapom sorra.

Sajnos eléri a gcc-t (:no input files)
CCC2-t próbálom felrakni, mert még előbb elkezdtem vele a szerencsétlenkedést minthogy idetaláltam volna és örülök hogy egyáltalán félig felraktam nem szeretnem előlről kezdeni ha nem muszaj. Itt megnézhető az install log-ja: http://home.arcor.de/merlin50/log.txt

( mrev | 2007. 02. 09., p – 23:10 )

Elromlott a tördelés ebben a témában, másikat kéne kezdeni.

--
CCC3

( mana1 | 2007. 02. 15., cs – 13:07 )

.obj állományom sehol nincs, nem jönnek létre.
Itt kellene egy outcpp állománynak létrejönnie nem? Mert ez sem keletkezik, legalább is a helló világ-os .prg fordításánál, .cpp, .ppo-m van. Ccomp-nak ide kéne pakolnia a paraméterezést MinGW-nek vagy hogy van ez?

_compile.bat-ban: 

:mng ------------------------------------------------------------
if not "%cccbin%"=="mng" goto msc

echo %1 >outcpp
ccomp c++ @%CMPOPT% -o %TARGET% %2\%1.cpp 2>>outcpp
goto iferror

( mana1 | 2007. 02. 17., szo – 01:17 )

Lefordult!,._*#&@&@#>ˇ^ˇ^°˘˘˛˘|ä#>&&#>