-lauto is not a command line obtion, actually... -l is, and that's documented. All -lauto does is to link with libauto.aJosDuchIt 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.
-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: So
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)
Then I suggest you keep linking with -lauto. There's no reason why this wouldn't work.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.
__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.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.
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 *
For code that should remain backwards compatible, I would actually suggest to still use libauto...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 eg
struct GfxIFace *IGfx
but did not use a corresponding GetInterface() call.
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.JosDuchIt wrote:
So why is that not important anymore on AOS4 ?
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.