JosDuchIt wrote: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.

-lauto is not a command line obtion, actually... -l is, and that's documented. All -lauto does is to link with libauto.a

JosDuchIt wrote:Soa) "-lauto" can still be used as an option and calls for libautob) can also be called with -mcrt=libauto ? (tested different forms libauto.a auto, auto.a : all "invalid C runtime libraries)

-mcrt just selects the C library, and with that the paths it uses for searching for libraries and header files. -lauto is "just" another link library, nothing else.

JosDuchIt wrote:- 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.

Then I suggest you keep linking with -lauto. There's no reason why this wouldn't work.

JosDuchIt wrote: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.

__USE_BASETYPE__ is not really obscure. In the OS4 headers, we opted to define libraries as opaque, i.e. everything is simply a struct Library *, even libraries that were traditionally "typed". A good example is intuition.library. You used to refer to it as struct IntuitionBase *. While this still works, the default behavior is not to refer to it as struct Library *. This makes code more robust in the sense that it will catch access to the library base that is always prone to problems and should be avoided.

if you define __USE_BASETYPE__, the headers will revert back to OS3 style, i.e. if you include proto/intuition.h, it will define IntuitionBase as struct IntuitionBase * again instead of defining it as a struct Library *

JosDuchIt wrote: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 egstruct GfxIFace *IGfxbut did not use a corresponding GetInterface() call.

For code that should remain backwards compatible, I would actually suggest to still use libauto...

JosDuchIt wrote:So why is that not important anymore on AOS4 ?

It's not only a matter of choice. ixemul.library was, by all accounts, ugly. It messed directly with stack frames and did all sort of evil things to keep things like vfork working. For that reason, all attempts to port ixemul.library to OS4 have been abandoned.

Instead, work went into two other projects: newlib and clib2. newlib is shared and part of the system, and pretty efficient, but lacks some features. clib2 had some initial problems, but has a lot of features that ixemul had (minus vfork).

Actually, the whole ixemul/vfork usefulness was, IMHO, always overrated. In the end, there are very few instances where fork could be replaced with vfork, and you had to be very careful about using features not directly related to ixemul when using vfork. Most instances where fork could be replaced with vfork where the usual fork/execve pairs (i.e. you fork a new process and immediately replace it's process image by a new one). But these instances can be replaced by AmigaOS specific code easily, without the usual CF that is involved with vfork.

So yes, ixemul.library mostly allowed configure/make/make install ports, but with a bit of extra work, these can be done with clib2 or newlib, too.

trixie wrote:As there are apparently more people puzzled by the present situation, I'm going to write an article that will summarize the currently recommended practices related to the creation of ReAction GUIs under OS4.x. Stay tuned

trixie wrote:As there are apparently more people puzzled by the present situation, I'm going to write an article that will summarize the currently recommended practices related to the creation of ReAction GUIs under OS4.x. Stay tuned

I'm going to write an article that will summarize the currently recommended practices related to the creation of ReAction GUIs under OS4.x. Stay tuned

Looking forward for it

It is unclear whether absolute gadget size and dimensions can be specified at all for ReAction gadgets that are not in a layout. They are BOOPSI so theoretically that could be possible (the standard Intuition BOOPSI classes work without a layouting system). The thing is, why would you want to? Considering today's configurability of the OS4 appearance - the different fonts, themes, user-defined GUI element shape and size - how would you be able to ensure a usable GUI without an automatic layouting system?

I just want to add new gadget types to Gui4Cli, especially a listview with possibility for the user to change the visible part of fields (field sizes). I am looking more closely to GadTools, Boopsi classes or Reaction, but surely not to the point i can tell how this can be done.

Gui4Cli is conceaved to allow drag & drop of gadgets in the same window or between windows.I don't use this feature very much, using my own gui4cli application in which i can define matrixes of gadgets and add them to the script(gui) i am working on. Thinking of it, i never checked if drag&drop still works under OS4. Making a gui with my gadget-matrix generator is a matter of seconds. (Gui4CLI is the ideal bottom up, early prototyping language to me)Gui4Cli also allows to add "absolute" simple graphics (lines, ellipse,..) to the window background (not working yet under OS4) which would marry les well i think with relatively positioned gadgets. Maybe not such a big problem.

Rewriting Gui4CLi such that it uses automatic layout change seems not impossible: instead of having the script defining absolute position eg xBUTTON L T W H "title"One could define its matrix position xBUTTON Row Column "title"

That would probably be a major overhaul of the source. I am not sure if i could manage that.Abyway there are other improvements that i want to implement first.Cleaning up the code (includes, deprecated & obsolete's) first.