12 June 2023, 15:59 | #1 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,665
|
Issue with graphics.h library?
I'm trying to compile some code I did not write and I ran into this error:
Code:
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; 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. |
12 June 2023, 16:33 | #2 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,224
|
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.)
|
12 June 2023, 17:40 | #3 | |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,665
|
Quote:
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? |
|
12 June 2023, 17:45 | #4 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,224
|
There is usually a CFLAGS variable in the makefile. If it has --noixemul flag defined, this will replace that.
|
12 June 2023, 19:15 | #5 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,665
|
Very helpful, thanks again.
So I have this: Code:
C_FLAGS = -Os -s -fomit-frame-pointer -std=gnu99 -mcrt=nix13 -Wall -Werror -Wno-pointer-sign Code:
ASM_FLAGS = -mcrt=nix13 -Wall -Werror -Wno-pointer-sign |
12 June 2023, 20:08 | #6 | |
Registered User
Join Date: Mar 2019
Location: Poland
Posts: 67
|
Quote:
|
|
13 June 2023, 00:21 | #7 | |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,665
|
Quote:
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. |
|
13 June 2023, 04:48 | #8 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,224
|
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 Last edited by Samurai_Crow; 13 June 2023 at 05:13. |
13 June 2023, 16:00 | #9 | ||
Registered User
Join Date: May 2001
Location: ?
Posts: 19,665
|
Quote:
Quote:
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 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?? Last edited by Amiga1992; 13 June 2023 at 18:16. |
||
14 June 2023, 03:13 | #10 | |||
Registered User
Join Date: Mar 2019
Location: Poland
Posts: 67
|
The latest NDK is here https://www.hyperion-entertainment.c....php/downloads
Get the one from AmigaOS 3.x NDK drawer. Quote:
Lowlevel.library requires v40 of graphics.library (kickstart 3.1), so compiling the source for kickstart 1.3 does not make sense. Quote:
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. Quote:
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. |
|||
15 June 2023, 08:18 | #11 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 692
|
Quote:
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 |
|
16 June 2023, 03:42 | #12 |
Registered User
Join Date: Mar 2019
Location: Poland
Posts: 67
|
|
16 June 2023, 10:35 | #13 |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 692
|
|
16 June 2023, 18:56 | #14 |
Registered User
Join Date: Mar 2019
Location: Poland
Posts: 67
|
You didnt mention that
Anyway, it is available on archive.org: https://archive.org/details/cdromsof...miga+developer |
20 June 2023, 15:44 | #15 | |||
Registered User
Join Date: May 2001
Location: ?
Posts: 19,665
|
Quote:
Quote:
Quote:
|
|||
29 June 2023, 00:41 | #16 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,665
|
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. |
12 July 2023, 14:19 | #17 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 546
|
Quote:
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. |
|
12 July 2023, 21:09 | #18 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,574
|
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. |
13 July 2023, 09:11 | #19 | ||
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 692
|
Quote:
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. Quote:
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! |
||
13 July 2023, 09:58 | #20 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 546
|
Quote:
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 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. Last edited by Olaf Barthel; 13 July 2023 at 10:11. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Library for loading graphics | sparhawk | Coders. General | 2 | 07 March 2020 20:38 |
Flickering graphics using BltBitMap function of graphics.library | balrogsoft | Coders. C/C++ | 16 | 04 February 2020 14:54 |
Sas/C vs. GCC regarding graphics.library | Steffest | Coders. C/C++ | 7 | 27 October 2017 03:52 |
graphics library v40.25 | Schlachtwerk | request.Apps | 0 | 14 February 2015 20:47 |
Some question about graphics.library lowlevels | Sonic | Coders. General | 3 | 28 July 2010 11:45 |
|
|