Issue with graphics.h library?

[phx]

Originally Posted by bebbo

To make the NDK 3.9 headers usable for KICK1.3 I added
#ifdef __KICK13__

This could be a sensible approach, if done correctly, and you didn't forget anything. But that's really a *lot* of work!

Much easier is to take the original NDK1.3 and add essential stuff, that is missing, in the compiler's include path. My approach for vbcc was that the kick13-target just adds the

clib

and

proto

directories, but doesn't modify anything! As Olaf already mentioned the missing prototypes were the biggest problem at that time, and different compiler vendors all had their own solutions (like

functions.h

). This is something you would have to adapt anyway, when compiling old sources.

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

Yes, indeed. But only occurs when including POSIX and AmigaOS headers at the same time, which should be avoided, but sometimes can't, especially with AmiTCP or other networking stuff. Although there are workarounds, without patching the headers.

The NDK3.2 headers fix that, BTW.

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

As long as there are people using your environment, and making source texts publically available, there is always the risk of causing chaos and frustration for others. Did you at least mention in some prominent Readme that the OS headers were modified? But even then many people making releases will forget or ignore to mention under which specific environment their project has been created.

[Olaf Barthel]

Originally Posted by phx

Yes, indeed. But only occurs when including POSIX and AmigaOS headers at the same time, which should be avoided, but sometimes can't, especially with AmiTCP or other networking stuff. Although there are workarounds, without patching the headers.

Hang on, how many TCP/IP stacks were there in 1988 which would have run into trouble because the struct timeval declaration would conflict with their expectations? To the best of my knowledge, there was no such TCP/IP stack.

Commodore was working on it, but first the A2065 (or rather, its precursor from Ameristar) had to ship, and then the networking software followed which had to be linked against the application which made use of it (that was the A225 product, if I remember correctly). From what I recall, that must have been around 1989 and prompted the development of the SANA standard for Amiga networking devices. Hard-coded driver support just would not cut it.

Changing the struct timeval declaration in this manner is, if you would excuse the term, anachronistic. This is dousing a fire before it has even had a chance to start glimmering, let alone smoking. Mind you, in 1989 AmiTCP was still a few years away and would require Kickstart 2.0, as a minimum. Even ixemul.library was still years away.

What would be really helpful would be a solution similiar to what shipped as part of Lattice 'C' 5.0, which implemented the draft 1989/1990 ANSI 'C' standard. This version added a "proto/#?.h" header file for every known operating system library and device (including one for clist.library, which was cut in Kickstart 1.2 because its agent demanded too money). Thus, "#include <proto/exec.h>" would become possible. Never mind that the state of the NDK 1.3 header files was still unchanged (no correct function prototypes in the graphics.library header files and certainly not in any amiga.lib header file).

[phx]

Originally Posted by Olaf Barthel

Hang on, how many TCP/IP stacks were there in 1988 which would have run into trouble because the struct timeval declaration would conflict with their expectations? To the best of my knowledge, there was no such TCP/IP stack.

Exactly. This would be a non-issue for a 1.3 compilation environment.

My impression was that Bebbo listed different kinds of patches he needed, and that only the first one refered to 1.3. The timeval patch is probably something he did for 3.9 only. In the end it doesn't matter, as such a patch does more harm than help.

[Amiga1992]

Guys I understand there's a discussion that's important here but maybe split it into its own thread so it can be discussed properly? Because now I just get more and more confused.

I'm bringing this back on my topic: is there a chance to roll back the Amiga GCC environment to an older version and see if that " fixes" my problem? I would need a version from like 2020, or it seems to me that this splicing of 3.0 SDK protos into the NDK13 may just be what's creating my issue, so whatever version that would not have that addition.

If that happened before 2020 then I am stumped.

[Olaf Barthel]

Originally Posted by Amiga1992

Guys I understand there's a discussion that's important here but maybe split it into its own thread so it can be discussed properly? Because now I just get more and more confused.

I'm bringing this back on my topic: is there a chance to roll back the Amiga GCC environment to an older version and see if that " fixes" my problem? I would need a version from like 2020, or it seems to me that this splicing of 3.0 SDK protos into the NDK13 may just be what's creating my issue, so whatever version that would not have that addition.

If that happened before 2020 then I am stumped.

From what I can claim to understand about the circumstances, new function prototype header files, or a rollback to a previous version, are unlikely to resolve the issues you encountered.

It seems that struct AnalogSignalInterval is merely defined in the operating system header files created from the NDK 3.9 header files, but not actually declared. Which makes the compiler stop because it does not know the size of the AnalogSignalInterval structure.

You mentioned that you are using lowlevel.library on a system running a Kickstart version earlier than 3.1. There is a disk-based version of lowlevel.library which, however checks if it is running on Kickstart 3.1 or higher. Are you sure that lowlevel.library even opens correctly?

[bebbo]

Originally Posted by Amiga1992

Guys I understand there's a discussion that's important here but maybe split it into its own thread so it can be discussed properly? Because now I just get more and more confused.

I'm bringing this back on my topic: is there a chance to roll back the Amiga GCC environment to an older version and see if that " fixes" my problem? I would need a version from like 2020, or it seems to me that this splicing of 3.0 SDK protos into the NDK13 may just be what's creating my issue, so whatever version that would not have that addition.

If that happened before 2020 then I am stumped.

make clean
make v date=2020-07-31

maybe you should use different PREFIX then

make v

returns to the latest versions.



and maybe even

make clean
make all NDK=3.9

could help you, since at that time the NDK 3.9 *with patches* was used.
(now NDK 3.2 only having the timeval patch is used by default)

[Thomas Richter]

Originally Posted by Olaf Barthel

including one for clist.library, which was cut in Kickstart 1.2 because its agent demanded too money

Thanks for sharing. I actually always thought it was removed from ROM because it was considered not very useful - and not because someone wanted money for it. Nothing in the Os actually depends on it, so I wonder why it was actually included in first place or what its intended use case was.


I would not call the string manipulation functions in the C standard library particularly valuable, but at least they are widely accepted and standardized, so code can depend on it.

[Olaf Barthel]

Originally Posted by Thomas Richter

Thanks for sharing. I actually always thought it was removed from ROM because it was considered not very useful - and not because someone wanted money for it. Nothing in the Os actually depends on it, so I wonder why it was actually included in first place or what its intended use case was.


I would not call the string manipulation functions in the C standard library particularly valuable, but at least they are widely accepted and standardized, so code can depend on it.

Sorry, that was just a rude joke of mine

The clist.library used to be a dedicated Kickstart ROM component in Kickstart V31 (= 1.1), and its sole client was console.device. The reason why it was removed in Kickstart 1.2 was that console.device was rewritten, removing the dependencies on clist.library.

[Thomas Richter]

Ehem, understood. So yes, I'm not the only one who thinks this library was pretty useless. Unfortunately, this does not seem to be the last rewrite of the console. Another one is overdue...

[phx]

Originally Posted by Amiga1992

Guys I understand there's a discussion that's important here but maybe split it into its own thread so it can be discussed properly? Because now I just get more and more confused.

I think Docent gave the best replies. And the information you provided until now are also confusing for many of us (lowlevel under 1.3?).

It would have helped a lot if you post the source you are talking about. Then we may speculate about the original author's intentions and make suggestions how to make it work.

[Olaf Barthel]

Originally Posted by phx

I think Docent gave the best replies. And the information you provided until now are also confusing for many of us (lowlevel under 1.3?).

It would have helped a lot if you post the source you are talking about. Then we may speculate about the original author's intentions and make suggestions how to make it work.

Making the synthesized 1.3 'C' header files work would have to start with closing the gaps, rendering them more consistent.

Just to find out what works and what does not, I built the compiler on Linux and then wrote a lazy one-liner (no Perl involved) which puts each relevant header in the "ndk13-include" directory through the wringer:

find ndk13-include/ -type f -name '*.h' | sed -e 's/ndk13-include\///' | awk '{ printf("echo >include.c \"#include <%s>\" ; m68k-amigaos-gcc -I ndk13-include -c include.c || echo \"#include <%s> failed\" \n", $1, $1);  }' | sh

This mostly works, but it does not work for the following 23 header files:

clib/graphics_protos.h
dos/exall.h
graphics/gfxbase.h
graphics/gfxmacros.h
inline/console.h
inline/diskfont.h
inline/dos.h
inline/exec.h
inline/expansion.h
inline/graphics.h
inline/icon.h
inline/intuition.h
inline/layers.h
inline/mathffp.h
inline/mathieeedoubbas.h
inline/mathieeedoubtrans.h
inline/mathieeesingbas.h
inline/mathieeesingtrans.h
inline/mathtrans.h
inline/potgo.h
inline/timer.h
inline/translator.h
proto/graphics.h

The error messages produced are the kind which likely drives newcomers away, up the wall, etc.

The use of anachronistic (there's that word again) header files which work only on Kickstart 2.0 and beyond (if at all) aside, fixing the small errors which derail compilation would make a big difference.

[Amiga1992]

Originally Posted by phx

I think Docent gave the best replies. And the information you provided until now are also confusing for many of us (lowlevel under 1.3?).

it's confusing for me too and I am trying to figure it out. Maybe it does not use lowlevel.library, but what code would I have had to share? I cannot share this codebase or I would have, but if any snippets can help maybe I can try that. I'm not trying to be obscure by choice.
Also the error is on the protos, not the code itself. maybe I should take it back a notch because there has been a lot of talk and a lot of it also stems from my own confusion. Here's the error again:

In file included from /opt/amiga/m68k-amigaos/ndk13-include/clib/graphics_protos.h:18:0,
                 from /opt/amiga/m68k-amigaos/ndk13-include/proto/graphics.h:6,
                 from /home/MyProject/src/joys.c:16:
/opt/amiga/m68k-amigaos/ndk13-include/graphics/gfxbase.h:119:30: error: field 'MonitorVBlank' has incomplete type
  struct AnalogSignalInterval MonitorVBlank;

This is some joypad reading code and I asked why it would use graphics.h, maybe it's related to reading at certain intervals?

[Olaf Barthel]

Originally Posted by Amiga1992

it's confusing for me too and I am trying to figure it out. Maybe it does not use lowlevel.library, but what code would I have had to share? I cannot share this codebase or I would have, but if any snippets can help maybe I can try that. I'm not trying to be obscure by choice.

Indeed: you are experiencing the pains which accompany any use of the 'C' programming language, many of which will go away over the years because you will have learned why they exist (and still don't like it), but by then you can either fix or avoid them.

Also the error is on the protos, not the code itself. maybe I should take it back a notch because there has been a lot of talk and a lot of it also stems from my own confusion. Here's the error again:

In file included from /opt/amiga/m68k-amigaos/ndk13-include/clib/graphics_protos.h:18:0,
                 from /opt/amiga/m68k-amigaos/ndk13-include/proto/graphics.h:6,
                 from /home/MyProject/src/joys.c:16:
/opt/amiga/m68k-amigaos/ndk13-include/graphics/gfxbase.h:119:30: error: field 'MonitorVBlank' has incomplete type
  struct AnalogSignalInterval MonitorVBlank;

Hang on, this is not in the prototype header file, but in the "graphics/gfxbase.h" header file which is included by the prototype header file. The error chain goes like this:

1) What header file was included and where was it found? It's "/opt/amiga/m68k-amigaos/ndk13-include/clib/graphics_protos.h".
2) What file prompted it to be included? It's "/opt/amiga/m68k-amigaos/ndk13-include/proto/graphics.h", which in turn was included by "/home/MyProject/src/joys.c" in line 16.
3) What is the issue? A data structure type is not defined which the header file "/opt/amiga/m68k-amigaos/ndk13-include/graphics/gfxbase.h" makes use of in line 119. A data structure field by the name of "MonitorVBlank" is supposed to make use of it.

This is some joypad reading code and I asked why it would use graphics.h, maybe it's related to reading at certain intervals?

No, this is something much simpler: your code cannot even be translated into a form which would allow it to be processed by the compiler and produce executable code and data.

The issue is with the contents of the "graphics/gfxbase.h" header file which references a data structure type which has not been defined in the header files which "graphics/gfxbase.h" depends upon.

How do you fix that? This may not be fixable because what you see in this error message may prompt the compiler to abort compilation altogether, with no subsequent compilation errors being shown. Put another way, you devise a workaround, you'll get the rest of the compiler errors which are now hidden from you.

With 'C' compilers you tend to see an avalanche of error messages, some of which are caused by the compiler trying to be helpful and doing its best to make sense of the code beyond the error it stumbled over.

[phx]

Originally Posted by Amiga1992

but what code would I have had to share?

Ideally the joys.c source and all local header files it depends on. This is preferable, because then we could test that with different compiler environments and find out if it works with one.

I cannot share this codebase

Problems with the original license? But ok, you may have your reasons.

but if any snippets can help maybe I can try that.

You could try to reduce the source to the lines which still reproduce the error and give us the command line for compiling it. Does a simple

#include <graphics/gfxbase.h>

or

#include <proto/graphics.h>

already show the issue?

Also the error is on the protos, not the code itself.

If I should have a guess, with the information given, I would say that you see the error because

struct AnalogSignalInterval

is undefined. With the original 3.x NDK this cannot happen, because it is defined in

<graphics/monitor.h>

, which is included directly before

struct GfxBase

is defined. Check for that line in your headers. Then check

graphics/monitor.h

for

struct AnalogSignalInterval

.

We heard from bebbo that he patched NDK3.9 headers to simulate an NDK1.3 compilation environment. Maybe something went wrong there? There was definitely no

MonitorVBlank

under 1.3. So I would expect

        UWORD   MinDisplayColumn;
#ifdef __KICK13__
        ULONG   reserved[23];    /* for future use */
#else
        UBYTE   ChipRevBits0;
        ...
#endif
        };

after

MinDisplayColumn

.

[Olaf Barthel]

Originally Posted by phx

Does a simple

#include <graphics/gfxbase.h>

or

#include <proto/graphics.h>

already show the issue?

I already checked: #include <graphics/gfxbase.h> is broken, along with 22 other header files in the synthesized 1.3 header file set. Please check my earlier posting on this matter. I omitted the full compiler output for the broken header files because it was much too much

If I should have a guess, with the information given, I would say that you see the error because

struct AnalogSignalInterval

is undefined.

In 'C' language terms, it is undeclared not undefined, isn't it?

[phx]

Originally Posted by Olaf Barthel

I already checked: #include <graphics/gfxbase.h> is broken, along with 22 other header files in the synthesized 1.3 header file set.

I suspected that. Thanks for checking!

In 'C' language terms, it is undeclared not undefined, isn't it?

I'm not so sure. I remember I was hesitating for a few seconds when writing it, but then decided to write undefined. My thought was: you can only define the layout of a structure.

For variables it is clear. You can either just declare them or define them. But for structures or typedefs? In any case you cannot do both there! Interesting question (and off-topic again) ...

EDIT: Ok, I think there are both cases for structures as well. For me a structure definition is:

struct test {
  int a,b,c;
};

And a structure declaration also exists, which is just:

struct test;

But a structure declaration wouldn't have helped here, so I would still say the problem was a missing definition.

[Amiga1992]

Originally Posted by phx

Ideally the joys.c source and all local header files it depends on. This is preferable, because then we could test that with different compiler environments and find out if it works with one.

I need to look at all this again but have not had a minute. This is weird though and I realized only recently, that joys.c line is pointing at a path that does not exist, so that might be all there is to it. This shouldn't be the case though, so I need to do some checks.

Again thanks for understanding given my constrains and trying to help.

[Amiga1992]

I am again trying to go back to this mess
I decided to just scrap the gameport code (I don't need it), but then I landed on the same problem again. It's literally telling me the error is in ndk13-include/graphics/gfxbase.h

Everyone got carried away beyond my understanding in this thread so I ask again, what should I do to fix this problem? Which are the headers I should actually be using and where do I get them from?

In file included from /home/Project/src/graphics.c:15:0:
/opt/amiga/m68k-amigaos/ndk13-include/graphics/gfxbase.h:119:30: error: field 'MonitorVBlank' has incomplete type
  struct AnalogSignalInterval MonitorVBlank;

[Docent]

Originally Posted by Amiga1992

I am again trying to go back to this mess
I decided to just scrap the gameport code (I don't need it), but then I landed on the same problem again. It's literally telling me the error is in ndk13-include/graphics/gfxbase.h

Everyone got carried away beyond my understanding in this thread so I ask again, what should I do to fix this problem? Which are the headers I should actually be using and where do I get them from?

In file included from /home/Project/src/graphics.c:15:0:
/opt/amiga/m68k-amigaos/ndk13-include/graphics/gfxbase.h:119:30: error: field 'MonitorVBlank' has incomplete type
  struct AnalogSignalInterval MonitorVBlank;

As I said earlier, you need includes for kicksart 1,3.

- Get the developer cd v 2.1 from the link I posted in message no 14
- backup/rename ndk13-include directory to something else
- copy contents of NDK\NDK_1.3\INCLUDES1.3\INCLUDE.H directory from developer cd to ndk13-include directory
- run make

[Amiga1992]

Originally Posted by Docent

As I said earlier, you need includes for kicksart 1,3.

But I already have those as shown in the error I posted above. It's erroring on the 1.3 includes. Please read again the error code I posted above.

[edit] I did exactly what you said just to be thorough, i copied the files from that exact CD to where you said , and I have even more errors now, also noticed there's far less folders of H headers there than in the old folder. this is not a solution.

As I mentioned before I think the only thing that *might* fix this is somehow being able to install an older version of the environment, dated around end of year 2020