From: miro.kropacek@gmail.com   
      
   Do you realise you're mixing gcc, mintlib and mint issues into one bag?   
      
   There's 0% chance the libraries you're using are official. 16-bit ("mshort")   
   support had been dropped sometime in the 2000s, long before gcc 4.2.   
      
   So whoever gave you those mintlib builds, ask him to make an update with gcc   
   4.6.4.   
      
   I can't remember when exactly but there has been a change in FPU register   
   handling in gcc so perhaps you can't directly use your old libs with "latest"   
   gcc but it's worth a try.   
      
   Anyway, your blaming of developers/applications is totally off.   
      
   Dňa pondelok, 27. februára 2017 2:00:28 UTC+10 Francois LE COAT napísal(-a):   
   > Hi,   
   >    
   > Michael Schwingen writes:   
   > > Francois LE COAT wrote:   
   > >>>> What worries me the most, is that there's no 16bits integer type. The   
   > >>>> C language is inappropriate for 16/32bits ATARI machines.   
   > >>>   
   > >>> Huh?   
   > >>>   
   > >>> Of course there is - I just tried using gcc-m68k-atari-mint   
   cross-compiler   
   > >>> (4.6.4) - it is called "short", just like expected.   
   > >>   
   > >> Replacing integer type (int) by short type (short) in my 30 years old   
   > >> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer   
   > >> type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC   
   > >> 4.2 and later don't have this 16bits int type. This is a cruel lack =(   
   > >   
   > > Huh?   
   > >   
   > > "short" *is* an integer type, so gcc has what you need. If using "short"   
   > > does not work, your code is buggy in other areas and simply needs to be   
   > > debugged/fixed - this is not gcc's fault.   
   > >   
   > > I can accept that you don't want to do that work, but again: that is your   
   > > decision and not gcc's fault.   
   >    
   > If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2   
   > or later, I would appreciate de retro-compatibility with the ATARI ST.   
   > But these 16bits versions of MiNTlib, GEMlib etc. are not still   
   > maintained ... You would say that it is "buggy" or something else,   
   > but it is simply 30 years old, such as the sources of my Eureka 2.12   
   > software. The retro-compatibility with the ATARI ST is not maintained.   
   >    
   > The problem is really with the "programmed obsolescence" with GNU/GCC 4,   
   > and people developing the ATARI target. They forget that ATARI ST is   
   > a 16/32bits architecture, and the "integer" type should be proposed as   
   > a 16bits type. This is a matter of adequacy from the language with the   
   > target. A 32bits integer type is far too demanding for an ATARI 520ST   
   > with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.   
   >    
   > Please notice that my software Eureka 2.12 runs on the early 520ST =)   
   > Most of the ATARI software produced today are not, you can check it.   
   > The software generated with AHCC have more chance to run with ATARI ST.   
   >    
   > Regards,   
   >    
   > --    
   > François LE COAT   
   > Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)   
   > http://eureka.atari.org/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)