Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: quiesce on May 30, 2003, 01:10:15 PM
-
What is the best, most up to date free C/++ compiler for the amiga? I
can only find gcc... will that do, or are there better ones around?
-
GCC will do.
-
No 040/060 optimization though?
I vaguely remember another good ansi c compiler for the amiga, it used
to be distributed on the Amiga Format CDs... just can't remember its
name!
-
The gcc distribution I downloaded from aminet has files missing and
doesn't work. Does anyone know where I can get a functional
distribution?
-
ftp.ninemoons.com ?
www.geekgadgets.org ?
-
vbcc?
-
Yeah that was it, vbcc. Thanks. :)
-
quiesce wrote:
The gcc distribution I downloaded from aminet has files missing and
doesn't work. Does anyone know where I can get a functional
distribution?
Strange, I've installed it too and it works flawlessly. Have you downloaded all the required files and installed it as described on the README file? Notice that it needs its version of ixemul.library to work, which should be included in one of the archives. The geekgadgets site has a more recent version of gcc, but it's much more difficult to install.
Varthall
-
Yes I did all that. The archive did not include the env-archive/ or s/
directories though, even though the readme says they should be in
there.
-
consider H&P's Storm C V4!
-
Make sure you download BOOT.LHA
when I unpacked all the files using WinRAR (because I'm developing in WinUAE), I had problems.. but when I unpacked using the files in BOOT.LHA, as per the instructions on the geekgadgets site, its nearly working now. hehehe.
Just make sure you run ixnetprefs and turn networking off so that the install will go fine.
-
Well i have the gcc files installed now but I need to setup some
assigns I think, as it can`t find the include files. (#include
results in No such file/directory). Does anyone know what
the assigns are?
-
buy the amiga developer CD 2.1
then you will get storm C!!!!
thats the best advice any amiga programmer can get :-)
-
No that wasn`t helpful at all. Besides, I have an old devkit that contains stormc version 3, and it doesn`t work.
-
Yeah, the dev cd was good to get me started.. now I'm changing to GCC for two reasons. StormC3.0 cant do 2d arrays, and I want my program to compile alright on OS 4.0. :)
-
This is hopeless. I've been trying all day to get a compiler to work. The closest I have come is with vbcc, and I can get some example programs to compile with a load of warnings and which don't function properly when executed. If someone could help me out here i'd much appreciate it.
-
For a beginner, I think StormC 3.0 on the Amiga Developer CD 2.1 is the easiest way to start up. I think all you need to do is copy the OS include files over, and you can start programming straight away. Run Snoopdos to see where its looking for those files, if its having trouble loading them. Get the 3.9 NDK off the net somewhere (do a search) to find the latest AmigaOS includes/header files..
Which version of the developer cd do you have?
-
Thanks for mentioning that ndk, I found it on the amiga inc. website. :)
-
Well looks like I finally got stormc working. However, none of the
example code will work. It compiles fine but when it gets to the
linking stage, I get a ton of linker errors saying Symbol "_FOO" is
not defined (it seems to say this for every function...). What might
be going on here?
-
quiesce wrote:
Well looks like I finally got stormc working. However, none of the
example code will work. It compiles fine but when it gets to the
linking stage, I get a ton of linker errors saying Symbol "_FOO" is
not defined (it seems to say this for every function...). What might
be going on here?
yes ive had that problem too! dont run the example code
just type in your own!
-
Apparently there was a version of stormc that had linker issues... I dont know about that, but my StormC 3.0 on the 2.1 dev cd is fine. Try and get that version dev cd maybe..?
-
I've taken a look at the gcc 2.7.0 distribution.
The missing env-archive/ and s/ files are in the
gcc270-readme archive (don't ask me why, it
would be more logical if they put them in the
base archive). Don't forget to copy the ixemul
library, but beware that all newer software that
uses ixemul require a recent version, so you'll
have to copy the old version everytime you want
to use gcc. There's another exe in the bin directory
(called gcc-vfork or something similar) that works
better with a newer library, but it doesn't work
very well.
Another option would be to get the complete gcc
2.9.5 (which should have 060 optimization, too)
from Louise's page:
http://louise.amiga.hu/index.php
It's a 11 megs gzipped file, which should include
a complete and fully working gcc compiler together
with some utilities. I've checked the homepage,
it looks like it has been revamped and I couldn't
find the archive, I hope it's still there...
Another source of precious information is here:
http://www.ezcyberspace.com/gcc/
Varthall
-
@iamaboringperson: Well I never feel safe in beginning to code until
at least -some- example code works. After copying over the latest libs
and header files from NDK3.9, I tried compiling several of the example
files both from the NDK AND those provided with StormC. And the
errors they gave didn't seem to have any apparent reason for being
there.
For example, it once complained about a definition of a macro in a
header file, even though it was uniform with the other macro
definitions before and after it (they were function calls). I don't
remember the other details, but now this linking is giving me
problems...
@Varthall: Thanks a lot you found it. :) That should help me get gcc
running.
-
Ok, it should be no surprise by now that I'm STILL having problems. I
tried doing what iamaboringperson suggested and wrote a simple
helloworld program in stormc. Here is the code:
#include
int main()
{
printf("Hello world.\n");
return 0;
}
And this is what I get:
Error: Unknown function "printf".
...ram:helloworld.c, Line 5: printf("Hello world\n")
I included the stdio header file and it can't find a printf function!?
That't pretty f***ed up if you ask me.
GCC i'm not having much better luck on... ixemul doesn't like it, when
I compile I get an ixemul window saying "ssystem() is no longer
supported. See the README document for more information. If you are
using gcc, then replace gcc with gccv.".
Well first of all I tried replacing my version of ixemul.library with
the one included in the gcc archive, but that turned out to be the
exact same latest version. I tried gccv and that seemed to `compile'
without problems... but then I tried running it and it wasn't an
executable!...
-
I solved the compiling problem in stormc by copying accross the
includes from my gcc directory... but now it hickups on the linking
again. Here's what I get:
Linker error: Symbol "_printf" not defined (Hint: "main()").
Ram Disk:hello.o symbol _printf hint main()
Linker error: Aborted.
If no one can help me, can they direct me somewhere like a developers
group that can help?
Also if anyone can find me an old version of ixemul.library or tell me
how to get gcc/gccv to work with a recent version of ixemul.library, i
would be grateful.
-
The ixemul provided in gcc 2.7.0 is NOT the latest
version: it's the 41.4 compiled in '95. I don't
know which is the latest version, the most
uptodate version I have is the 48.0, date 14.7.98.
Remember that once a library is opened, it will
remain in memory and every program will use
that, not the copy in libs:. Maybe you have just
copied the old library over the new one, without
flushing the memory (with "avail flush" in a shell)
or resetting the machine.
I also remember gccv not working well, I guess that
it also doesn't support the newer ixemuls.
Don't lose hope, Quiesce, you've nearly made it ;)
Varthall
-
I stand corrected, it seems the version command doesn`t work properly.
And the latest version of ixemul is 48.2 or 48.3 I think.
-
I've had gcc compile a simple program now, but it doesn't want to link
any libs. For instance, if I type:
c++ -l gcc:os-lib/reaction.lib test1.c -o test
A requester pops up saying:
Please insert volume
/gnu/lib/gcc-lib/mc68020-cbm-a
in any drive
After clicking cancel a few times it then asks for
"/local/lib/gcc-lib/mc68020-cbm" and then "/gnu/lib/libgcc" and then
"/local/lib/libgcc" and finally, in the shell window I get: ld: No
such file or directory for libgcc:lib/reaction.lib.a
Am I doing this right?
-
And if I use the -lobjc argument I get ld: maformed input file (not
rel or archive) gcc:lib/reaction.lib
-
After doing a little experimenting, the bottom line seems to be that gcc expects an .a extention to all linker libs, whereas the one i'm trying to link has a .lib extension. Renaming it doesn`t help, it thinks the file is corrupt. Can someone explain to me how to link the .lib files or why they won`t work?
-
Maybe i'm asking the wrong questions. I want to produce a reaction GUI, and so far GCC seems to be the most promising choice for a compiler. If anyone has coded in reaction in gcc, maybe they can help me. :)
-
looks like you are not having much luck there :(
i have never had any success with reaction, so i hope people can help me with that too!
-
@quiesce:
You seem to have quite some trouble. It's been a long time since I did any Amiga-programming with gcc, but perhaps these hints and tips will help you understand what's going wrong. Please note that this is largely quoting from memory, with lots of experience of using gcc with Linux.
First of all, using an #include does not insert the code of external functions into your program---it just tells the compiler 'Look, somewhere out there, there's a function called foo(), with parameters bar and baz. Trust me. It exists. Don't complain, just generate the proper code to *setup a call* to that function.' The job of the linker is then to look at what the compiler created, and pull out the real code of foo() from a library. If you don't supply the proper linking options to the command line, you get errors like you described. That is a tell-tale sign you forgot to link to the proper libraries.
Now libraries come in two flavours: Amiga-style .lib-format, and gcc-style lib.a-format. Note the prefix 'lib' in the gcc-name. As far as I know, the gcc linker 'ld' cannot handle the Amiga-linker libraries: their format is simply too different. (Someone please correct me if I'm wrong.) It should be possible to convert them into each other: there's bound to be a program on Aminet to do that for you. By the way, do not confuse a .lib-file with a .library-file: they are very different things!
Now then. Fist your helloworld-program. The proper compilation directive for that is:
gcc -o helloworld helloworld.c -lc
Notice that I am calling onto the C-compiler here (and not the C++-one: your program is standard C!). Also note the -lc option: this means 'Link with libc.a'. Notice that is it not -llibc.a or -llibc. If your program contains any math, you should do something like:
gcc -o calculate calculate.c -lm -lc
instructing to link with libm.a first, and then libc.a. Don't reverse the order: it can lead to problems in program execution.
You then wanted to link your program to the Reaction-lib. That doesn't work for two reasons: your program doesn't use any function from that lib so there's nothing to link, and second its file format is incorrect. It is an Amiga-style .lib-file, after all.
Finally, the compiler asked you to insert various volumes. That tells me you have not executed a little script to set all the assign's needed for the GNU-system (and thus the compiler). The compiler will not work properly until you've set them all to their proper values. I recall that there is a small package of about 50 KB called 'ade-setup' or 'gg-setup' or something similar, which contains all the necessary files to do this. It is most likely not included in a standard set of GNU gcc-executables: it is very Amiga-specific. (The Aminet directory /dev/gg has an interesting README---have you looked at it?)
Anyway, I hope that the above helps you sufficiently to get the system up and running to a point where you can compile standard C- and C++-programs; after that the next hurdle is Amiga-specific system programs. Once you can compile those, you can start thinking about Reaction. Good luck.
(Note to experienced Amiga-coders: feel free to say where I went horrendously wrong; like I said, it's been a long time :-).)
-
Thanks for that. The c++ command was necessary because gcc doesn't like the "//" comment, and it appears in a lot of the header files.
Let me get something straight about libraries... linker libraries include code into the main program during the linking process? And .library files load functions into the program on execution? If my understanding of the latter is correct, how can I prevent the program from complaining about the absence of a function that comes from a .library file?
-
Another thing... i've looked on aminet and on google and can't find anything to convert amiga link libraries into gnu c link libraries. Does this mean I can't use third party link libraries in gcc, or am I not looking hard enough?
Edit: oops, turns out the util to do it was in my gcc package. :P
-
Seems some libs won't convert anyway... such as the mui linker libraries and reaction.lib.
When converting reaction.lib I get:
Convert this library into ALINK (join type) format.
How do I do this?
-
@quiesce:
Man, I wish Karlos or someone else helped me out here :-). I am under the impression you are trying to run before you can walk: take it one step at a time.
Once again, several issues. The '//' is a C++-style comment. gcc should not have any trouble with that when compiling in C-mode. Certainly version 2.95.x does not. Perhaps it was an addition to the compiler postdating 2.7.x.
You are correct in your understanding of the differences between a .lib- and a .library-library. In order to have gcc shut up about missing .library-functions you have three options: link to a lib which contains so-called stub code, use the compiler directive #pragma (the method used with SAS/C, AztecC and perhaps others too), or generate the necessary inline assembly statements yourself. gcc has extensive facilities for the latter. All methods do the same thing: they generate the proper code for setting up a function call to an Amiga-style run-time library. This unfortunately is somewhat different from a regular gcc-function call, hence the special treatment. If I had an Amiga myself, I could probably hack up some working code: while very arcane, it's not overly difficult.
The problem is that for the applications you wish to develop, the stub code route is difficult. You need to link to amiga.lib as well as, say, mui.lib. The former contains stub code for the basic library functions like OpenLibrary() and CloseLibrary(). The second deals with the calls specific to MUI. Unfortunately, linking fails because the gcc-linker doesn't understand the format of those libs. Since #pragma-statements are highly compiler-specific, you cannot simply 'borrow' them from the Amiga header files. Leaving you stranded with the inline assembly method of gcc... :-?
Which brings me to the final topic: I recall---a dim, hazy, nearly forgotten memory---that the SAS/C suite had a tool which performed the conversion for you. Although I don't really understand why the supplied program you mentioned fails: as far as I can remember is that linker libs *are* basically a string of 'join'ed object files. Also, ALINK was retired back in 1986, and I'm very sure the Amiga-port of the gcc-suite was developed much later. To see a program which still requires after this extinct dinosaur is surprising to say the least. Are you sure you're using the converter correctly?
I regret that's about as much I can tell you. While it is certainly possible to use gcc for Amiga-specific development (foregoing the use of ixemul), it's a bit of a pain setting it up properly and has you fiddling with internals no nere mortal should ever set eyes upon. Nevertheless, I hope you find my comments useful. Good luck!
-
Hi all,
Sorry Cymric ;-) I managed to miss this thread - I haven't been in the developer forums much lately. I'm up to my eyes in some coding at the moment and come to amiga.org to get a break from it :-)
Standard C / C++ code pass arguments to a function on the stack (a unix convention). The amiga libraries have an assembly level interface that works differently. Arguments are passed along in registers and a pointer to the library is passed in register a6.
To call amiga libraries from C, compilers have to generate the appropriate calling convention for a function (ie save off any registers that may get trashed, load the arguments and to a jsr to the code).
Naturally there are several ways of doing this. Inline assembly, stub libraries or #pragmas.
Any #pragma is compiler dependent (that being the point of pramas). IIRC StormC goes this route (with amicall / tagcall).
AFAIK, as Cymric says, gcc basically goes the inline assembly / stub link library way.
In any event, I strongly reccomend the inline asm header approach for performance critical code. Otherwise (with the link libraries) you are calling a function to call a function. Naturally this introduces some additional overhead. Not really much of an issue for GUI related stuff I guess...
I'm not actually using gcc at the moment, but IIRC there was a tool for creating gcc compatible stub .lib files from fd files?
Keep on plugging away at it. I'm sure you'll get there.
-
quiesce wrote:
If my understanding of the latter is correct, how can I prevent the program from complaining about the absence of a function that comes from a .library file?
It is. shared libraries have version numbers. From the documentation on a library, choose the minimum version that fully supports all the functions of that library you intend to use.
The OpenLibrary() call supports a minimum version number that you specify (often left as zero if you don't care which version). You give this as the second argument eg:
/* Open at least v41 of intuition.library */
IntuitionBase = OpenLibrary("intuition.library", 41);
OpenLibrary() will return NULL if either the library isn't available (should never happen for intuition btw ;-) ) or isn't available in at least the version you asked for. Simply test the return value for NULL and handle accordingly (maybe put up an error message and cleanly exit the program).
-
It seems that if I setup a pointer to the opened library, (like intuitionbase, as you said) the compiler won't complain. Thanks. :)
-
I hope noone minds me asking another coding question... ;) I would like to know how you go about creating another thread/process?
For instance, if I had the function STRPTR FRequester(STRPTR pattern, STRPTR pathname) which displayed a file requester window, this function would normally stall the rest of the program until the file requester closed and the function returned. How could I have this function call move onto another thread/process (not sure what the correct terminology is here) so that my program could multitask and do other things?
-
Actually that wasn't a very good example :-)
IntuitionBase is not a standard Library (in that it has extended stuff in it)
What I should have written int that example was
struct IntuitionBase *IntuitionBase;
IntuitionBase = (struct IntuitionBase*)OpenLibrary("intuition.library", 41);
/* we can check if we opened it ok by testing if IntuitionBase is not NULL */
But the general idea is the same for all libraries.
-
Hi quiesce,
Ah, the wonders of multithreading :-)
Creating multithreaded code has its complications. But generally what you do is to define a function that serves as the entry point for the new thread.
The next thing is to create a thread and tell it to launch from that address. You have two choices under amiagos
1) Use an exec.library Task
Tasks are lightweight and do not use many resources. Their principal drawback is that they cannot use dos.library or anything else which may use it (eg normal C IO mechanisms).
Use tasks when character IO is not important for your code.
You need to look at exec.library/AddTask() or amiga.lib/CreateTask()
Eg :
struct Task* myTask;
void myTaskMain()
{
/* code for myTask */
}
/* struct Task* CreateTask(name, pri, entry, stacksize)*/
myTask = CreateTask("mytask", 0, myTaskMain, 4096);
2) Use a dos.library Process
This is an exec.library task extended with the various handles that allow it to use the dos.library. It's pretty much complete. You need to look at dos.library/CreateNewProc(). This call returns a struct Process* (castable to struct Task*) and takes a range of arguments as a taglist.
If you do go for multithreading, you need to protect data that is used from parallel threads. You have to ensure that modifications to data are exclusive. For this you need to look at Signal Semaphores (see exec.library manuals).
You will also need to look at signalling and sending messages such that your threads can norify each other. An understanding of how exec works is very handy here.
It sounds a bit more complex than it is but it's also not for the beginner either.
-
Thanks.
-
@quiesce:
Karlos already did a great job of answering, and I agree with him: explicitly coding a program so it's fully multi-threaded/tasking is a very tricky job. Let the amount of programs which actually have the sort of threading you want serve as an indication. It's quite often difficult enough as it is to create a single-threaded application without there being bugs in it :-P.
-
OK I am finally getting somewhere now. I decided to begin with learning MUI instead of Reaction, as I can't find any documentation on Reaction.
I have successfully made a program which opens some libraries including muimaster, generates some objects, enters a loop and closes them. However there is one 'warning' that is giving me trouble when compiling:
warning: implicit declaration of function 'int DoMethod(...)'
This function is essential for MUI. According to the docs I have, it is defined in amiga.lib. However the location of the prototype isn't mentioned. I would assume that it were in or but including these does not solve the problem. Here is my code in full so someone can point out if I'm doing anything else wrong. :) (and yes I realise I don't do any error checking ;) )
-- main.h
void InitLibs(void);
void FreeLibs(void);
void InitMasterLoop(void);
void InitInterface(void);
extern Object * Application;
extern Object * AppWindow;
-- main.c
#include
#include
#include
#include
#include
#include
#include
#include "main.h"
struct IntuitionBase * IntuitionBase;
struct Library * MUIMasterBase;
Object * Application;
Object * AppWindow;
int main(int argc, char ** argv)
{
InitLibs(); // Load runtime libraries
InitInterface(); // Define MUI Objects
SetAttrs(AppWindow, MUIA_Window_Open, TRUE);
InitMasterLoop(); // Begin main loop
SetAttrs(AppWindow, MUIA_Window_Open, FALSE);
MUI_DisposeObject(Application);
FreeLibs();
return 0;
}
void InitLibs(void)
{
MUIMasterBase = OpenLibrary("muimaster.library", 19);
}
void FreeLibs(void);
{
CloseLibrary(MUIMasterBase);
}
void InitMasterLoop(void)
{
ULONG sigs = 0;
while(DoMethod(Application, MUIM_Application_NewInput, &sigs) != MUIV_Application_ReturnID_Quit)
{
if(sigs)
{
sigs = Wait(sigs | SIGBREAKF_CTRL_C);
if(sigs & SIGBREAKF_CTRL_C) break;
}
}
}
void InitInterface(void)
{
Application = MUI_NewObject(MUIC_Application,
MUIA_Application_Title, "MUITest",
MUIA_Application_Version, "0",
MUIA_Application_Copyright, "",
MUIA_Application_Author, ""
MUIA_Application_Description, "",
MUIA_Application_Base, ""
MUIA_Application_Window,
(AppWindow = MUI_NewObject(MUIC_Window,
MUIA_Window_Activate, TRUE,
MUIA_Window_AppWindow, TRUE,
TAG_DONE)),
TAG_DONE);
}
// And that's it!
-
Sorry, seems the board removed the indenting. :-P
-
Heh, I think it's high time this thread was moved to the developer forum ;-)
First and foremost, the prototypes for DoMethod() and DoMethodA() are in clib/alib_protos.h
If you want to indent your source for posting you need to use a non breaking space "& nbsp;" without the space between the & sign and the nbsp; bit (I had to seperate them here otherwise it would be parsed into a real non-breaking space and you wouldn't see it) (thanks to Tickly for telling me that originally ;-) )
A couple of small points that you should consider. How about returning a BOOL from InitLibs() that returns true if the library was opened and false if not? Then you can cleanly exit your program without a crash on systems where v19 of the muimaster.library is not available.
This could be as simple as
BOOL InitLibs()
{
return (MUIMasterBase = OpenLibrary("muimaster.library", 19)) ? TRUE : FALSE;
}
Incidentally, IIRC the use of void to signify no function arguments is deprecated since ANSI C v2. It certianly is in C++ ;-)
-
The issues in the first half of this thread are ones i've come up against lately in trying to get GCC going on an amiga.. can someone PLEASE SET UP A WORKING GCC CONFIGURATION WITH THE 3.9NDK LINK LIBS AND JUST LHA THE LOT AND STICK IT ONLINE? instead of newbies like us who have lots of enthusiasm but are having to download a shed load of #### from aminet and god knows wherelse and have to contemplate bizzare programs to convert libs over etc.
ta
-
@quiesce
Here is a simple ipc example (http://www.iki.fi/sintonen/src/ipc/) I wrote. Could prove useful.
-
@Karlos: Why is void deprecated, and what should I use instead?
-
@Piru: Thanks I'll take a look.
-
I dunno exactly. Maybe because it's a waste of typing ? :-P
I'm talking about void in argument lists eg
void function(void);
You can just write empty brackets instead:
void function();
Nothing in the brackets means no arguments expected. I think they borowed this from C++ and to give better upwards compatibility with it.
-
Actually you might want to check for yourself. I recall reading it in whitepapers on C (esp the ISO 1999 standard) but I may be wrong.
I do know that older C interprets empty brackets as 'no information given' about arguments.
This was deemed unnaceptable in C++ so they opted for the empty brackets means no arguments approach. Which makes more sense anyway ;-)
-
OK. Well here's an update on my program. I included the header clib/alib_protos.h> and the program compiled and linked without a single warning or error. However, when I run it, WinUAE exits completely! It never fails to do this. No crash, or anything. It just exits instantly. What the heck could be wrong here?
-
Have you tried it on a real miggy? Send it over if you like...
-
That's all well and good if it works for you but I can't code if it won't run in WinUAE (I haven't had a real amiga in over a year).
-
Well, I meant to see if it bails out here too.
Incidentally, did you add the checks for the library open (see my earlier post) ?
Tying to use a library that isn't open will cause all kinds of mayhem.
-edit-
I seem to recall there were some crashes on the amiga side that the emulator cant cope with so it exits. I've seen it happen before somewhere...
-
By commenting out functions, I have managed to find out that it is the call to SetAttrs() that is causing WinUAE to close. Why, I have no idea...
-
Looking back at your code post, don't you need to create the object before you go setting its parameters?
-edit-
sorry, I just saw that you did
-
I did that in the call to InitInterface()
-
Have you put any runtime pointer checks to make sure that your objects are created?
Each time you create something just add a little check to make sure the pointer is not NULL.
This goes for libraries too...
-
I stuck a few pointer checks in and weeded out a few errors. However now everything SHOULD work, but WinUAE still shuts down as soon as SetAttrs() is called.
-
To be honest I haven't done any MUI coding, but BOOPSI is pretty much all alike.
Send me the executable just to see if I can get any crash info. Perhaps it's not your program at fault...