()->with('message','image not found');
    	}

    	  return redirect()->back();	
    }

    public function CustomerviewAjax(){
     
     return view('fontend/customer_dashbord/dashbord_view_ajax');

    }
}
- 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?
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.
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'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 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().
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.
Try gcc --help!
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 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.
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.
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.
) 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?
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..
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.
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).
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.
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 Gad