Hyperion Entertainment Message Boards

- gcc options -noixemul and -lauto- are no longer available . Is automatic opening of system libraries in the pipeline, or can this still be done ?
- can or will the SDK be adapted to allow compilation for OS3.9, AROS ?
- can or will a gcc option be available to show for which target machines it can compile?

- gcc options -noixemul and -lauto- are no longer available . Is automatic opening of system libraries in the pipeline, or can this still be done ?

Imho having -noixemul its wrong by default, because why we should use it at all ? It was used on os3.9, and still used on morphos just by some ancient reassons imho. As far as i remember, that swith was added only for some gcc builds, just to avoid borking with ixemul , and that all not important on aos4 anymore. As for the -lauto, i think it no present for newlib, but present for the clib2 , but anyway, all that problems with "-l_some_a" , can be solved by this way: you check what undef references you have, the go to SDK directory, and do search over the whole for that undef reference, and then add that a.lib.

- can or will the SDK be adapted to allow compilation for OS3.9, AROS ?

No way imho. For what aos4 developers, should ever worry about ancient-non-supported os3, and aros ?

Through, you always can use "vbcc", which can build bins for os3/os4/mos/wos/pup/aros on any platform (i.e. you can install it for os4, and build binary for any platform). But as far as i know, vbcc is no longer officially supported by os4 sdk (but can be wrong here), but even if it, still, SDK for sure will not have any other targets except os4 ones, so you will need to download manually os3 or any other targets for.

- can or will a gcc option be available to show for which target machines it can compile?

Can't remember right now, but as far as i understand, aos4 gcc which come in SDK, will always able to produce code for aos4 only.

@JosDuchIt

JosDuchIt wrote:- gcc options -noixemul and -lauto- are no longer available.

libauto definitely is still available - I've just spent a couple of hours getting rid of the autoinit dependence in my programs What has been removed is libraauto, the autoinit for ReAction classes, which is now part of libauto.

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.

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().

JosDuchIt wrote:- gcc options -noixemul and -lauto- are no longer available . Is automatic opening of system libraries in the pipeline, or can this still be done ?

As has been said, libauto.a is available.

-noixemul was never available. It was in the OS3 compiler, but not the OS4 gcc. In the OS4 compiler, selection of the C library is done via the -mcrt= option.
So, to compile with newlib, use -mcrt=newlib, while clib2 can be used with -mcrt=clib2. In theory, if ixemul would exist, it would be used with -mcrt=ixemul.

-mcrt=newlib is default.

JosDuchIt wrote:- can or will the SDK be adapted to allow compilation for OS3.9, AROS ?

No. Why should Hyperion support anything else but their own systems ?

The SDK compiler is derived from the adtools project (in fact, it was the reason for founding adtools). Adtools was always cross platform, and I think OS3 compilers exist within that project, so if you need a compiler for OS3, you might want to look there. It is hosted on sourceforge.

JosDuchIt wrote:- can or will a gcc option be available to show for which target machines it can compile?

It can only compile for OS4, so what else do you want it to show ? The SDK compiler will generally produce code for ppc-amigaos targets, that is, AmigaOS 4.x.

gcc -v shows the target like so:


8.AmigaOS4:> gcc -v
Using built-in specs.
Target: ppc-amigaos
Configured with: ../gcc/configure --prefix=/gcc --host=ppc-amigaos --target=ppc-amigaos --build=i686-cygwin --enable-haifa --enable-sjlj-exceptions --enable-languages=c,c++
Thread model: single
gcc version 4.2.4 (adtools build 20090118)
8.AmigaOS4:>

[edit]
Of course:

8.AmigaOS4:> gcc -dumpmachine
ppc-amigaos

is shorter

Try gcc --help!
[/edit]

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.



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)

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.




@kas1e

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 ?

@trixie

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?

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.

gcc -help will never point on it imho, just as to any other "link" libs. I am sure its all already mentioned in the some "Getting started" docs in the SDK, but if not, then its should be added only to documentation, and not to compilator-help-output. Dunno , if there any os3-to-os4 porting guide in SDK, but as far i remember in the same "getting started" pdf its mentioned somehow..

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.

Then just use -lauto. You not need to worry about -noixemul switch at all. I remember now, for all my os3-to-os4 ports, i use -lauto, right, to avoid opening of many libs. And still, should to add, that -lauto not cover _all_ libs. Some of them you still should open manually, and while you open some of them, why not open others (at last you will know for sure what is opened, and what is closed). Anyway, -lauto also can be used.

Like that what i do when port Amifig to os4:

-O2 -D__USE_INLINE__ -lamiga -lauto

or for LunaPaint:

-D__USE_INLINE__ -lpng -freetype -lz -lauto

The use of ixemul was said to make linux ports easier.

We have many POSIX (and other unix) necessary functions in the SDK already, for making porting of unix apps less problematic: all those getuids, mkdir, chdir, rmdir, umask, stat , link, lseek, etc ,etc. We still not have some very necessary implemetations of few posix's functions, like "fork()", or differnt forms of exec(). Anyway, ixemul are not need it anymore (you can think about it as just about "absolete", even if something from ixemul can be not avail on our SDK, but i think almost everything we have).

So why is that not important anymore on AOS4 ?

Because SDK have almost all necessary unix-posix-etc-kind functions already. All what you need its add correct lib.a , and that all. To be honest, i found aos4 SDK much better than other ones , just because its all pretty easy now, without strange "noixemuls" switches. You just make a code, compile it and then link it, like as you do on any normal OS with gcc.

In other words, if you want to port something from os3 to os4, all what you need: #define __USE_INLINE__ in source (or just -D__USE_INLINE__ for the compiling line) + -lauto (as well as other libs, beuse -lauto its not something which magically will solve all undefined symbosl and open every library automatically).

If you want to port something from unix to os4: You not need to worry not about USE_INLINE, not about -lauto , not about any other switch, you just compile it as it , with having in mind all that "HOME" / PROGDIR: changes and stuff. Of course , none of unix programms have amiga realted code inside, so you not need to bother at all about "open/close" amiga libs when porting from unix.

@JosDuchIt

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.

There is a tutorial over at OS4coding.net, written by Menthos:
http://www.os4coding.net/blog/menthos/c ... helloworld

However, it does a couple of things that are now considered deprecated or are not recommended to do any more. 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

Is it possible to mix Reaction gadgets and Gadtool gadgets on the same window?

First of all, forget Gadtools gadgets under OS4 - they are way too limited and limiting. In a window, ReAction gadgets are governed by a special layouting mechanism (which itself is implemented as a gadget, called "layout.gadget"). The layout determines gadget sizes and positions - unlike Gadtools gadgets, which are programmed to specific dimensions. You wouldn't be able to connect a Gadtools gadget to a ReAction layout anyway because Gadtools do not conform to the BOOPSI specification.

trixie wrote:In a window, ReAction gadgets are governed by a special layouting mechanism (which itself is implemented as a gadget, called "layout.gadget"). The layout determines gadget sizes and positions

I know someone trying to write a ReAction GUI which does NOT use automatic layout for some stuff, and he has basically given-up trying to do it as he cannot seem to get it to work. Do you know if it ought to be possible?

@ChrisH

I know someone trying to write a ReAction GUI which does NOT use automatic layout for some stuff, and he has basically given-up trying to do it as he cannot seem to get it to work. Do you know if it ought to be possible?

I don't know, and honestly, I've never asked myself that question. 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?