Thanks for all info
Obviously only my first question made sense.
btw: before posting my questions i tried gcc--help and it is there that i did not find -lauto or -noixemul anymore.
I rechecked now: -lauto is not mentioned but obviously works end is helpfull in the porting from OS3 to OS4.
It would be good that the gcc --help mentions it.
a) "-lauto" can still be used as an option and calls for libauto
b) can also be called with -mcrt=libauto ? (tested different forms libauto.a auto, auto.a : all "invalid C runtime libraries)
However, the use of libauto is now discouraged, even though many SDK examples use it for the sake of making the code shorter. Opening everything yourself gives you much better control.
I do agree but in a learning phase, adapting the examples every time is time consuming.
While porting from OS3 to OS4, you want to concentrate on functionality that no longer works, on obsoletes and deprecated first. I seem to have benefited from this.
Indeed, the context of my questions is the following
- i am preparing to improve the Gui4CLi source again, which is using quite a lot of libraries.
Having had good but ill digested advice this source now compiles for OS4 (but for warnings) and i did not touch for more than 2 years.
My opening and closing of libraries certainly is a mess, but i always compiled using -lauto. The OS4 SDK's gcc never complained about this.
To get closer contact again with C-programming i am first trying to compile short examples and am struggling with -lauto __USE_INLINE__ , __USE_BASETYPE__, or just plain OS4 code
__USE_INLINE__ works nicely
__USE_BASETYPE__ is more obscure to me and gives me redefinition errors even in simple code. A good explanation of what it does would probably help.
I just now tried to compile Gui4Cli source without -lauto and i get a lot of undefined references.
Checking for their origin i see that i did open the corresponding libraries, i did define the interface pointers eg
struct GfxIFace *IGfx
but did not use a corresponding GetInterface() call.
As far as i remember, that switch was added only for some gcc builds, just to avoid working with ixemul , and that all not important on aos4 anymore.
Yes, but -noixemul also allowed you to avoid to open and close the os (sytem) libraries.and you had to use -lauto to keep this advantage, if you did not use the first switch.
The use of ixemul was said to make linux ports easier.
So why is that not important anymore on AOS4 ?
In the case of ReAction classes, it is also recommended not to use OpenLibrary() at all (as is done in libauto). Instead, use OpenClass() and obtain the class pointer right away. You will later use it with NewObject() to create a BOOPSI object instance directly from the class pointer, sparing you from using the _GetClass() functions or the public class ID. The latter two methods (used by reaction_macros.h) are slower. On my 667 MHz Sam, more complex GUI layouts are created noticeably faster if you use the class pointer obtained from OpenClass().
thanks for the info. I want to look into Reaction more closely, and noted that Reaction examples were present on UtilityBase site, which is down for some time now. If somebody could point me to them elsewhere that would be great.
The Gui4Cli source shows that the author D.Keletsekis was moving that way, when he left the Amiga. However he used GadTools mainly,. It seems that he wanted to define either 'Gadtools gui's/windows" or Reaction Gui's/windows. It is not clear if this would be implemented as a choice to the user writing a script ( The script starting with G4C/Reaction versus G4C/Gadtools
) or if it would be a Gui4cli tooltype/option.
My ideas are unclear here: Is it possible to mix Reaction gadgets and Gadtool gadgets on the same window?