Issue with graphics.h library?
 

I'm trying to compile some code I did not write and I ran into this error:
Can anyone shed any light on what this might be, so I can try to fix it?
It fails right when it tries to #include graphics.h on line 16, so I don't think it's anything related to the code that follows that statement.

I'm an absolute n00b so be gentle.

I see you are using Kickstart 1.3. Are you using the correct runtimes? --mcrt=nix13 might do it just as a guess. (LibNix has a special version for Kick13. I hope I typed that tag correctly.)

Thanks for the input! I have no idea, I've inherited this and I am trying to figure out what the fuck is going on. I'll look into that.

I take it I need to make a new Makefile using this different runtime? I also don't know how this was ever compiled before. There was also some other little errors that I don't get how they could be there, maybe an older amiga-gcc was used and fine with this setup?

There is usually a CFLAGS variable in the makefile. If it has --noixemul flag defined, this will replace that.

Very helpful, thanks again.

So I have this:
And also this:
seems like -mcrt=nix13 is already there, so what to look for next? :confused

It think that you have messed up includes - gfxbase.h seems to be from release 2.0 or higher as MonitorVBlank is not defined in 1.3 gfxbase.h, also struct AnalogSignalInterval is defined in monitor.h, which is not available in 1.3, it appeared first in 2.0 includes.

Well as I said before, I have not messed up anything, this is code I inherited and I am trying to figure out how to make it work.

I was thinking about this too, after Samurai mentioned the 1.3 thing, but it's so weird because this code has been compiled before, just not by me. Are these includes somewhere inside amiga-gcc? I feel like this problem can come from this all being made with a much older version of amiga-gcc, if I understood correctly, the way to handle KS1.3 software changed at one point.

Now could there be a reason to include a newer graphics.h in this control port code? The control port code uses, afaik, lowlevel.library, which may only be available on 2.0+

Again this is all speculation, I'm trying to figure things out as I go.

Bebbo's GCC port of 6.5 downloads its headers from somewhere. Your source is probably correct but was built with different includes. The C runtime change means it is already adjusted to a port version of Bebbo's GCC. That possibility was not present on earlier versions of GCC.

There is a CD32 controller handler code somewhere on Aminet.net that doesn't require Lowlevel.library so look for that and splice it in as needed.

Edit2: found it
https://aminet.net/package/dev/asm/ReadJoyPad

Where can I get the latest includes then?
But is lowlevel.library part of graphics.h? Why is graphics.h included here? Maybe it's some remnant code I can just exclude.

Also: based on the latest compiled binary of this, this all works, and it might not be using lowlevel.library at all, if I remember correctly, because I think it brought thru some problems so the code was replaced by something that directly addressed a CD32 controller.

[edit] Just looked at this code more.
First, i dug deep within amiga-gcc for the includes, and I compared NDK graphics.h and NDK13 graphics.h, and they both look identical, so not sure what I am missing. ALSO looked into clib/graphics_protos. Neither seem to have a definition for "MonitorVBlank"
Furthermore, this joystick code DOES use lowlevel.library, but I don't see any mention of "MonitorVBlank" anywhere within the code :confused

I don't want to create my own joypad code at the moment, but I want to understand why the hell is graphics.h included here and why it fails on keywords that don't seem to be called/defined anywhere.

[edit 2] i am a tit, I forgot to check gfxbase.h , will do that now. This is exhausting.

[edit 3] checked the gfxbase.h from NDK13-include , and it actually DOES have struct AnalogSignalInterval MonitorVBlank;, so wtf?? the error says it has an "incomplete type struct", what does that even mean??

The latest NDK is here https://www.hyperion-entertainment.c....php/downloads
Get the one from AmigaOS 3.x NDK drawer.
lowlevel.library apperared in kickstart 3.1 with release of cd32. It is not part of graphics.library, it is just a convenience library to ease checking of keys, joysticks or pads, setting up interrupt handlers or disabling parts of system in a compatible way.
Lowlevel.library requires v40 of graphics.library (kickstart 3.1), so compiling the source for kickstart 1.3 does not make sense.

read my previous comment in this thread - your includes are incorrect or messed up and are not real 1.3 includes - in includes for 1.3 gfxbase.h is much shorter.
clib/graphics_protos contains only prototypes of graphics.library functions that user can call and MonitorVBlank is an internal variable of type 'struct AnalogSignalInterval' that is used to keep vertical blanking interval. This variable was introduced with os 2.0 with the new monitor display database system.

It means that your includes are incorrect - in includes for 1.3 gfxbase.h does not contain MonitorVBlank field.
What is the target machine and operating system for the code you are trying to compile? a500, a1200?
Did you get the source code together with the build environment the code was earlier successfully built or just the source code?

"incomplete type struct" means that the type of MonitorVBlank variable is not defined.

The includes for 1.3 are grafted from the 3.* includes.
The NDK3.9 headers are better prepared for 1.3 usage - amiga-gcc already has some patches there.
TBD:
- provide patches for NDK3.2 similar to the NDK3.9 patches.
- or provide a reliable source for the original kick 1.3 headers

Amiga Developer CD 2.1 contains includes for 1.3 in ndk folder.

but that's not an internet resource

You didnt mention that :)
Anyway, it is available on archive.org: https://archive.org/details/cdromsof...miga+developer

This program has to run on an A500, and here's what really grinds my gears: the latest compiled executable I have, does. It runs on 1.3 and it works with the controller.

If I had the environment, I would be able to compile this thing. I only have the source code. I do not know what was the last environment this was compiled with. What I have built as an environment is the latest everything so I am guessing whatever this was built with, must be incompatible with the latest environment.

I still am befuddled by this. Furtehr testing of last working executable shows some odd behavior:
- If controller is not recognized as CD32 pad, controller code does not work at all.
- If I quit the program and run it again, the controller does not work anymore.
- On the above situation, if I exit and I run something like JoyPortTest from Aminet, then I run it again, it works again.

It seems the support is botched and will need further testing, but at this point, i'll be happy if I am able to just make this thing compile at all. There's one more last thing to try when I have time.

Yes, the various Amiga Developer CD ISO images are available for download, but there is no convenient shortcut for downloading just the NDK 1.3 header files. You would have to download the ISO image first (I recommend the "Amiga Developer CD v2.1"), then extract the portions which cover the 'C' header files (in the "NDK/NDK_1.3/Includes1.3/include.h" directory) and hope for the best.

While this is certainly doable, the effort and overhead are considerable. Downloading some 220 MBytes of ISO image to extract a mere 470 KBytes of header files. Panning for gold in 1850's California would have been more productive ;)

That said, the NDK 1.3, released by Commodore in fall 1988, might glitter, but it is not what we would call gold today. The 'C' header files were intended to be used with the commercial Amiga 'C' compilers of that time, these being Lattice 'C' 4.0 (from early 1987) and Manx Aztec 'C' 3.6a (from late 1987). Both would support K&R 'C' as per the 1978 "The 'C' programming language" book.

You could make use of these period-authentic header files on a modern 'C' compiler, but you'd be boxed in by the lack of certain amenities. For example, no official, complete and correct list of function declarations for the Amiga operating system existed in 1988. Aztec 'C' 3.6a shipped with a "functions.h" header file which mostly got things right, but it was compiled from what the authors found in the AutoDocs, which were wrong in many important places.

Beyond that, the Amiga 'C' header files still would contain typos which could derail compilation and the order in which you included the header files mattered greatly. Always start with "#include <exec/types.h>" or there will be surprises along the way. Be prepared for more compiler warnings than you might have seen in a whole year.

There should be no reason to patch OS headers, because they have always been valid for all compilers. When did that stop? The only part which is compiler-specific were the proto-headers, which may contain compiler-specific library calls.

If there is really a problem in a header file, the best way is to contact Olaf to fix it or implement a workaround for gcc.

This is what happens when people start to patch official headers. :sad

There is patching and there is patching. And there is patching?



To make the NDK 3.9 headers usable for KICK1.3 I added
#ifdef __KICK13__
int reserved[10];

#else
...

#endif
to get rid of some not usable members. Still not complete but one can work with.


And there is more evil patching like



#ifndef _TIMEVAL_DEFINED
#define _TIMEVAL_DEFINED
struct timeval {
...
#endif


To avoid double/different definition of a type - here the well known timeval.




My general view - not related to someone personally:



Since every maintainer has it's own point of view, it's reasonable that not every change will be adopted. Well, sometimes it's not...
I ceased imposing my changes long time ago.


Anyway, my gcc version is an outlawed oddity for the riders of a dead horse, it's not that important.


Have fun!

You can lead a horse to water, but you cannot make it drink, especially if it's dead ;)

As I mentioned, developing software for the Amiga was always hard and arguably it never became much easier over the decades.

There is little context in the header files designed to help you make sense of what there is (the intuition header files could easily double as documentation, but the dos header files are really a mostly unordered collection of bafflement), stuff is unexplained, at times useless, at times misnamed.

Synthesizing 1.3 compatible header files from the NDK 3.1 or later header files does not necessarily lead to results which fail to work better than the original 1988 NDK 1.3 header files managed to. The only aspect in favour of the original NDK 1.3 header files is that they are fully consistent in their inconsistencies and do not raise questions with regard to how the data structures declared in later operating system revisions fit into the picture. Such are the perils of accidental time travel, I suppose :D

The supposedly "Right Way" to do this is to learn on the job what you could do with the 'C' development environment of yore (which includes the operating system documentation, of course), as it was in 1987/1988 and explore, gradually, how this environment changed over the years. How did we get from 1.3 to 2.0, then to 3.0 and so forth? What APIs are available, which data structures were introduced, etc. but who has that much time... Hint: The "Amiga Developer CD 2.1" contains all of the material to get you started if you want to dig in and learn not just how to ride a dead horse, but to also make it drink and tell rude jokes, wearing a funny hat and smoking a cigarette.

Changes made to header files which were never intended to evolve or allow for patching are bound to require explanations as far as side effects and humorous details are concerned. Caveat emptor: somebody will have to explain this. Developing software for the Amiga was always hard, and every time somebody makes the effort to not make it harder should be appreciated. You do not have to justify the effort.