28.12.2004 01:36
[#1]
po instalce GCC
witam;
właśnie zainstalowałem sobie GCC (68k)
(ale jest hojrak :D co? ....)
nie było tak źle, znalazłem pakiet z Installerem :D
ok, do rzeczy:
otworzyłem pierwszy tom Symfonii C++ i wklepałem jota w jotę typowy przykładzik, czyli słynne Helo World!
a kompilator...
mi mówi, że jest jakaś tam zła referencja do 'cout'...
dodam przy ty, że ten sam przykład z
pomóżcie!
właśnie zainstalowałem sobie GCC (68k)
(ale jest hojrak :D co? ....)
nie było tak źle, znalazłem pakiet z Installerem :D
ok, do rzeczy:
otworzyłem pierwszy tom Symfonii C++ i wklepałem jota w jotę typowy przykładzik, czyli słynne Helo World!
#includevoid main(void) { cout << "Dziala!!!" ; }
a kompilator...
gcc ram:hello.cpp -o ram:hello
mi mówi, że jest jakaś tam zła referencja do 'cout'...
10.Workbench:> gcc ram:hello.cpp -o ram:hellocpp /t/cc6nbB5u.o(.text+0x1c): undefined reference to `cout' /t/cc6nbB5u.o(.text+0x22): undefined reference to `ostream::operator<<(char const *)' collect2: ld returned 1 exit status 10.Workbench:>
dodam przy ty, że ten sam przykład z
stdio.hzamiast
iostream.hi z
printf()zamiast
coutskompilował się bez zgrzytów.
pomóżcie!
28.12.2004 13:32
[#3]
Re: po instalce GCC
@Kaczus, post #2
moze uzyc void main (void) bez problemu w tym przypadku bo chce tylko sprawdzic dzialanie kompilatora. co do tego standardu to ci powiem ze nie wszystkie kompilatory go chwytaja (mi bynajmniej nie chcialy) ja bynajmniej nie zauwazylem zadnej roznicy przy stosowaniu zapisu#include a #include using namespace std; moze roznice sa widoczne na okreslonych kompilatorach ale ja ich nie odczulem
28.12.2004 19:54
[#9]
Re: po instalce GCC
@Kaczus, post #2
no proszę, jednak obaj mamy cos nie tak.
a ja to już chyba w szczególności.
wypróbowałem g++ na pliku hi.cpp
#include
using namespace std;
int main(v)
{
cout << "Działa!!!" ;
return(0);
}
i zmienił sie tylko komunikat:
9.Workbench:> g++ ram:hi.cpp -o hi
/gg/m68k-amigaos/bin/ld: cannot open -lstdc++: No such file or directory
collect2: ld returned 1 exit status
nadal nie chce skompilować.
próbowałem też z wersją
void main() i void main(void)
i to samo.
z tym, że sytuacja tu mi się wydaje jakby nieco jaśniejsza, bo po prostu brakuje mu jakieś pliku tylko. czy mam rację?
a ja to już chyba w szczególności.
wypróbowałem g++ na pliku hi.cpp
#include
using namespace std;
int main(v)
{
cout << "Działa!!!" ;
return(0);
}
i zmienił sie tylko komunikat:
9.Workbench:> g++ ram:hi.cpp -o hi
/gg/m68k-amigaos/bin/ld: cannot open -lstdc++: No such file or directory
collect2: ld returned 1 exit status
nadal nie chce skompilować.
próbowałem też z wersją
void main() i void main(void)
i to samo.
z tym, że sytuacja tu mi się wydaje jakby nieco jaśniejsza, bo po prostu brakuje mu jakieś pliku tylko. czy mam rację?
28.12.2004 23:23
[#14]
GCC C++ działa!!!!
@R-Tea, post #12
jak to dobrze, że nie skasowałem tego CD-RW!!!
znalazłem mój backup wb sprzed roku na starym sfatygowanym cd-rw i okazało się że są tam archiwa tar.gz i lha, te które kiedyś ściągnąłem z geekgadgets.org :D jakimś cudem nen CD ocalał! :)
he. he.. no i działa mi kimpilacja źródełek c++
działa pięknie zarówno jak zastosuję rady Kaczusia jak i bez zastosowania tego using namespace std;
działa zarówno ze zwracaniem int jak i z void jaki i w ogóle jak nic się nie napisze przed main i w naviasie. działa bez raturn(0) jak i z nim. słowem, działa w wszelkich możliwych konfiguracjach. :D
uwaga: przy rozpakowywaniu jak był kimunikat że plik już istnieje dawałem na overwrite all zawsze. nie wiem czy dobrze, nie chciało mi sie sprawdzać wersji :) byle do przodu.
teraz tylko jeszcze devkę MUI musze dorzucić do tego i będzie komplecik :D
no..... teraz jak ktoś chce to mogę podesłać te 15 megsów.
znalazłem mój backup wb sprzed roku na starym sfatygowanym cd-rw i okazało się że są tam archiwa tar.gz i lha, te które kiedyś ściągnąłem z geekgadgets.org :D jakimś cudem nen CD ocalał! :)
he. he.. no i działa mi kimpilacja źródełek c++
działa pięknie zarówno jak zastosuję rady Kaczusia jak i bez zastosowania tego using namespace std;
działa zarówno ze zwracaniem int jak i z void jaki i w ogóle jak nic się nie napisze przed main i w naviasie. działa bez raturn(0) jak i z nim. słowem, działa w wszelkich możliwych konfiguracjach. :D
uwaga: przy rozpakowywaniu jak był kimunikat że plik już istnieje dawałem na overwrite all zawsze. nie wiem czy dobrze, nie chciało mi sie sprawdzać wersji :) byle do przodu.
teraz tylko jeszcze devkę MUI musze dorzucić do tego i będzie komplecik :D
no..... teraz jak ktoś chce to mogę podesłać te 15 megsów.
01.01.2005 23:02
[#17]
GCC i AmigaDOS
@R-Tea, post #1
witam;
co muszę inkudować, żeby móc odpalić komendę execute z ADOS ??
tyle wiem, że exec.library jest zawsze otwarta i jej nie trzeba otwierać, ale co inkludować żeby kompilator zaczaił ta komendę?
inkludowałem - z przykładów Grzegorza Kraszewskiego wyczaiłem, że potrzebne jest do OpenLibrary().
inkludowałem żeby móc odpalić Execute() np. tak:
execute("c:copy c:cal ram:",NULL,NULL);
a kompilator g++ pisze mi cos takiego:
gg:src/p1.cpp:20: warning: implicit declaration of function `int execute(...)'
/t/ccBOEkw7.o(.text+0x94): undefined reference to `execute'
collect2: ld returned 1 exit status
co muszę inkudować, żeby móc odpalić komendę execute z ADOS ??
tyle wiem, że exec.library jest zawsze otwarta i jej nie trzeba otwierać, ale co inkludować żeby kompilator zaczaił ta komendę?
inkludowałem
inkludowałem
execute("c:copy c:cal ram:",NULL,NULL);
a kompilator g++ pisze mi cos takiego:
gg:src/p1.cpp:20: warning: implicit declaration of function `int execute(...)'
/t/ccBOEkw7.o(.text+0x94): undefined reference to `execute'
collect2: ld returned 1 exit status
01.01.2005 23:27
[#19]
Re: GCC i AmigaDOS
@R-Tea, post #17
haha! działa!
dzięki :D
ale dziwi mnie że przeszkodziła różnica wielkości liter, przecież jak wpicuję w Shellu COPY czy Copy czy copy to za każdym razem zadziała.
linijka o błędzie:
/t/ccBOEkw7.o(.text+0x94): undefined reference to `execute'
postanowiłem zrobić experyment i wywaliłem inkludy i
oto wynik:
9.Workbench:> g++ gg:src/p1.cpp -o gg:src/p1
gg:src/p1.cpp: In function `int main()':
gg:src/p1.cpp:12: warning: implicit declaration of function `int OpenLibrary(...)'
gg:src/p1.cpp:12: warning: assignment to `Library *' from `int' lacks a cast
gg:src/p1.cpp:18: warning: implicit declaration of function `int Execute(...)'
gg:src/p1.cpp:20: warning: implicit declaration of function `int CloseLibrary(...)'
a najdziwniejsze jest to, że skompilował i działa!!!
jak to wyjaśnić?
czy te inkludy są zbędne?
dzięki :D
ale dziwi mnie że przeszkodziła różnica wielkości liter, przecież jak wpicuję w Shellu COPY czy Copy czy copy to za każdym razem zadziała.
linijka o błędzie:
/t/ccBOEkw7.o(.text+0x94): undefined reference to `execute'
postanowiłem zrobić experyment i wywaliłem inkludy
oto wynik:
9.Workbench:> g++ gg:src/p1.cpp -o gg:src/p1
gg:src/p1.cpp: In function `int main()':
gg:src/p1.cpp:12: warning: implicit declaration of function `int OpenLibrary(...)'
gg:src/p1.cpp:12: warning: assignment to `Library *' from `int' lacks a cast
gg:src/p1.cpp:18: warning: implicit declaration of function `int Execute(...)'
gg:src/p1.cpp:20: warning: implicit declaration of function `int CloseLibrary(...)'
a najdziwniejsze jest to, że skompilował i działa!!!
jak to wyjaśnić?
czy te inkludy są zbędne?
01.01.2005 23:37
[#20]
Re: GCC i AmigaDOS
@R-Tea, post #19
Execute nie jest komendą DOSa, który jak wiemy, jest nieczuły na wielkość liter. To jest funkcja biblioteki dos.library i w C++ jest deklarowana jako normalna funkcja, a w C++ w nazwach funkcji wielkość liter ma znaczenie.
To są tylko ostrzerzenia, został zastosowany domyślny prototyp - funkcja zwraca int, a jako argumenty ma nieokreśloną ilość intów, czyli: (...)
Tu akurat miałeś szczęście, bo wszystkie argumenty tych funkcji są typu 32 bitowego (wskaźniki i nie było żadnego konfliktu przy przekazywaniu parametrów przez stos)
Inkludy są niezbędne, bo jak będziesz miał funkcję która jako argument przyjmuje powiedzmy WORD, albo double, to zobaczysz piękny zwis :D , poza tym to brzytko wygląda jak przy kompilacji wywala tony ostrzezeń
Zadziałało jeszcze dlatego, że cały program był linkowany ze "stub'ami" do amigowych bibliotek - to są takie wesołe kawałki kodu, które pobierają dane ze stosu i przypisują je do określonych rejestrów (a do których, to chyba było osobno w amiga_lib zdefiniowane).
To są tylko ostrzerzenia, został zastosowany domyślny prototyp - funkcja zwraca int, a jako argumenty ma nieokreśloną ilość intów, czyli: (...)
Tu akurat miałeś szczęście, bo wszystkie argumenty tych funkcji są typu 32 bitowego (wskaźniki i nie było żadnego konfliktu przy przekazywaniu parametrów przez stos)
Inkludy są niezbędne, bo jak będziesz miał funkcję która jako argument przyjmuje powiedzmy WORD, albo double, to zobaczysz piękny zwis :D , poza tym to brzytko wygląda jak przy kompilacji wywala tony ostrzezeń
Zadziałało jeszcze dlatego, że cały program był linkowany ze "stub'ami" do amigowych bibliotek - to są takie wesołe kawałki kodu, które pobierają dane ze stosu i przypisują je do określonych rejestrów (a do których, to chyba było osobno w amiga_lib zdefiniowane).
01.01.2005 23:51
[#21]
Re: GCC i AmigaDOS
@shg, post #20
ok, wielkie dzięki, jarzę, a przynajmniej mam taką nadzieję :D
oto, mój programik:
#include
#include
#include
struct Library *dosBase;
main()
{
if (!(dosBase = OpenLibrary ("dos.library", 0)))
{
cout << "Can't open dos.library!n";
return (10);
}
Execute("c:copy c:cal ram:",NULL,NULL);
CloseLibrary (dosBase);
}
dodałem z inkludy, ale zostały jeszce 2 warningi po kompilacji:
gg:src/p1.cpp:11: warning: initialization to `UBYTE *' from `char *' changes signedness
gg:src/p1.cpp:17: warning: implicit declaration of function `int Execute(...)'
czy mógłbyś mi je "rozjaśnić" ? :)
oto, mój programik:
#include
#include
#include
struct Library *dosBase;
main()
{
if (!(dosBase = OpenLibrary ("dos.library", 0)))
{
cout << "Can't open dos.library!n";
return (10);
}
Execute("c:copy c:cal ram:",NULL,NULL);
CloseLibrary (dosBase);
}
dodałem z inkludy, ale zostały jeszce 2 warningi po kompilacji:
gg:src/p1.cpp:11: warning: initialization to `UBYTE *' from `char *' changes signedness
gg:src/p1.cpp:17: warning: implicit declaration of function `int Execute(...)'
czy mógłbyś mi je "rozjaśnić" ? :)
02.01.2005 00:07
[#22]
Re: GCC i AmigaDOS
@R-Tea, post #21
Ciesz się, że tylko tyle, miałbyś nowsze gcc błędów byłoby więcej...
Przede wszystkim domniemany typ int przy main - naum się w końcu pisać
int main(), to, że teraz nie ma błędu nie znaczy, że jak zmienisz
kompilator będzie dalej tak samo. Używaj dokładnych typów, czyli nie
0, a 0L jako argument OpenLibrary, itd... Jeśli używasz w miarę nowego
gcc, to #include i pozniej albo piszesz using namespace
std; albo zamiast cout uzywasz std::cout... Chcesz się uczyć C++, ucz
się porządnie, a nie bylejak. Chcesz się uczyć po łebkach, nie ucz się
wcale.
Przede wszystkim domniemany typ int przy main - naum się w końcu pisać
int main(), to, że teraz nie ma błędu nie znaczy, że jak zmienisz
kompilator będzie dalej tak samo. Używaj dokładnych typów, czyli nie
0, a 0L jako argument OpenLibrary, itd... Jeśli używasz w miarę nowego
gcc, to #include
std; albo zamiast cout uzywasz std::cout... Chcesz się uczyć C++, ucz
się porządnie, a nie bylejak. Chcesz się uczyć po łebkach, nie ucz się
wcale.
02.01.2005 00:14
[#23]
Re: GCC i AmigaDOS
@R-Tea, post #21
brakuje jeszcze:
#include - tam jest prototyp funkcji Execute()
powinno odrazu zlikwidować oba ostrzeżenia
Ogólnie dla każdej używanej biblioteki:
#include
za to dos/dos nie jest potrzebny, tam masz definicje struktur i stałych używanych przez dos.library (np. FileInfoBlock, czy jakieś MODE_NEWFILE), a z tego, co widzę, niczego z tamtąd nie używasz.
i jeszcze deklaracja zmiennej:
nie wiem, czy GCC ma coś takiego, jak automatyczne otwieranie bibliotek, ale jeżeli ma, a chcesz sam zadbać o biblioteki, to musisz zadeklarować bazę biblioteki dokładnie tak, jak w include'ach (wielkość liter), czyli:
struct Library *DOSBase;
pierwszy warning wziął się stąd, że nie masz zdefiniowanego prototypu dla funkcji i przyjmowany jest domyślny typ argumentu, normalnie to jest int, ale jak podajesz wskaźnik, to domyślnym typem jest char * (albo UBYTE *, nie wiem dokładnie, nie zagłąbiałem się w to), po zainclude'owaniu prototypów funkcji dos.library, powinno zniknąć
A ostrzeżenie oznacza, że zmieniasz typ zmennej ze znakiem na bez znaku, albo odwrotnie.
Jakby talej wywalało coś z UBYTE, to spróbuj jeszcze:
#include
tam są amigowe typy zmiennych, jak LONG, ULONG, BYTE, UBYTE, BPTR itp.
#include
powinno odrazu zlikwidować oba ostrzeżenia
Ogólnie dla każdej używanej biblioteki:
#include
za to dos/dos nie jest potrzebny, tam masz definicje struktur i stałych używanych przez dos.library (np. FileInfoBlock, czy jakieś MODE_NEWFILE), a z tego, co widzę, niczego z tamtąd nie używasz.
i jeszcze deklaracja zmiennej:
nie wiem, czy GCC ma coś takiego, jak automatyczne otwieranie bibliotek, ale jeżeli ma, a chcesz sam zadbać o biblioteki, to musisz zadeklarować bazę biblioteki dokładnie tak, jak w include'ach (wielkość liter), czyli:
struct Library *DOSBase;
pierwszy warning wziął się stąd, że nie masz zdefiniowanego prototypu dla funkcji i przyjmowany jest domyślny typ argumentu, normalnie to jest int, ale jak podajesz wskaźnik, to domyślnym typem jest char * (albo UBYTE *, nie wiem dokładnie, nie zagłąbiałem się w to), po zainclude'owaniu prototypów funkcji dos.library, powinno zniknąć
A ostrzeżenie oznacza, że zmieniasz typ zmennej ze znakiem na bez znaku, albo odwrotnie.
Jakby talej wywalało coś z UBYTE, to spróbuj jeszcze:
#include
tam są amigowe typy zmiennych, jak LONG, ULONG, BYTE, UBYTE, BPTR itp.
chyba go dam pod prëgierz 
01.03.2005 15:06
[#27]
Re: po instalce GCC
@R-Tea, post #1
Osiâgnâîem sukces!! Po instalce GCC, zaczâî reagowaę na komendy :)
Narazie zareagowaîa biblioteka ixemul.library okienkiem:
ssystem() is no longer supported.
See the README document for more information.
If you are using gcc, then replace gcc with gccv.
po uűyciu komendy gccv zamiast gcc, coôtam poszmeraîo na dysku i dostaîem
nawet plik: a.out To chyba miaî byę plik wykonywalny, ale niejest
(plik nie jest programem)
Chciaîem RTFM, ale w tym gâszczu niczego nie moűna znaleúę.
Gdzie jest bîâd? Dlaczego nie dziaîa gcc, tylko gccv?
Narazie zareagowaîa biblioteka ixemul.library okienkiem:
ssystem() is no longer supported.
See the README document for more information.
If you are using gcc, then replace gcc with gccv.
po uűyciu komendy gccv zamiast gcc, coôtam poszmeraîo na dysku i dostaîem
nawet plik: a.out To chyba miaî byę plik wykonywalny, ale niejest
(plik nie jest programem)
Chciaîem RTFM, ale w tym gâszczu niczego nie moűna znaleúę.
Gdzie jest bîâd? Dlaczego nie dziaîa gcc, tylko gccv?
