In the meantime the engine author worked a bit on fullpipe and made it at least enter the intro everytime on using window for me, it still crashes in fullscreen and there are still sprite errors which lead to a crash later on, but we are getting there.
Sgit diff issue where sgit status shows a modified file but sgit diff does nothing, may be worked around with re-cloning the repo. It happens rarely but when it happens with a certain repo, it may be reoccur again easily.
IF i clone the repo with sgit clone blabla and then configure and build
the binary will crash, because sgit is one of those porgrams that, on creating the directory structure while cloning, does something ScummVM afterwards doesn't like.
Are the "yutotools" (autoconf, automake, aclocal etc.) part of the gcc development or are they special?
I'm trying to configure a project, but only get lots of errors
Quote:
automake autom4te: m4sugar/m4sugar.m4: no such file or directory configure.ac: error: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal) automake: error: no 'Makefile.am' found for any configure output automake: Did you forget AC_CONFIG_FILES([Makefile]) in configure.ac?
Quote:
/SDK/Local/share/aclocal-1.15/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG /SDK/Local/share/aclocal-1.15/smpeg.m4:13: run info Automake 'Extending aclocal' /SDK/Local/share/aclocal-1.15/smpeg.m4:13: or see http://www.gnu.org/software/automake/ ... ke.html#Extending-aclocal configure.ac:35: warning: macro 'AM_INIT_AUTOMAKE' not found in library configure.ac:41: warning: macro 'AM_GNU_GETTEXT_VERSION' not found in library configure.ac:42: warning: macro 'AM_GNU_GETTEXT' not found in library configure.ac:64: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:151: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:166: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:179: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:221: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:241: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:242: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:256: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:269: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:286: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:287: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:304: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:305: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:328: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:346: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:364: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:382: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:400: warning: macro 'AM_CONDITIONAL' not found in library configure.ac:480: warning: macro 'AM_CONDITIONAL' not found in library autom4te: m4sugar/m4sugar.m4: no such file or directory
Then again, there is only smpeg.m4 in there, nothing else (and it also tries to access aclocal-1.15 dir, which doesn't exist on my sdk - i renamed it for testing)
@Raziel If you do it all on amigaos4, then using automake, autoconf, aclocal and so on will give you hard times. They not up2date, have issues to amiga specific pathes, and all sort of bugs.
Once project you works on, and its active project (meaning it want latest autoconf and stuff), then use crosscompiler (yeah..). On amigaos4 that all will give you stress and annoying issues which have no needs to be sorted, just compile it all on cygwin.
Maybe it possible to sort exactly those issues you have, but on crosscompiler you will have none. And having some notebook or any sort of PC with crosscompiler just only for amigaos4 are good and easy way to do porting.
Hmm, i was under the impression that i have to use the same "available" versions of sdk tools in a cross compiler as natively...obviously i was wrong, since cross compiling means only the binary will be amigaos...
Is there an easy way to set up a cross-compiler under windows 10? -- easy, as i've never done it
@Raziel If you want crosscompiler for exatly use all those autoconf, automake, aclocal, bisons, perls, cmakes and all stuff : then better not MSYS2, but CYGWIN. Reasons is that : cygwin will have no issues between unix and win32 pathes , so you will have no needs to deal with another issues.
MSYS2 (mingw and stuff) its more like gcc compiler for win32. And while it also have cmake, autoconf and stuff, it will give you issues because of win32 patches, like "/" vs "C:" , etc.
I just tried MSYS and wrote article about just because was in interst to check out how it all will be, but cygwin is better for ports (Exactly for ports, and for all that autoconf/cmake stuff).
If you in interest (and in last half of year i from day to day plan to do) i can write another article with step-by-step guide how to do all the stuff for cygwin and some tips/tricks.
MSYS2 are fine too of course, when you develop your own os4 software it make no differences then. But for porting work, and expectually things like scummvm, all those autoconfs/cmakes, then Cygwin, or you will need from time to time change all those "/" on "c:" and stuff, which kind of annoying.
Expectually that difference is only about what to install one time, and then use without problems.
Quote:
Hmm, i was under the impression that i have to use the same "available" versions of sdk tools in a cross compiler as natively...obviously i was wrong, since cross compiling means only the binary will be amigaos...
You just will install there adtools, which later you can update by just latest SDK on top (the same SDK of course which used for native). Just in crosscompiler you will not have amigaos4 binaries to execute, but x86/x64 ones , which will generate amigaos4 bins. But includes, link libs and stuff - all will be the same of course.
I'd need it for porting and especially autotools stuff, since that doesn't seem to work natively,
I'd love to have an easy-to-set-up environment to be able to do that.
Your sig points to zerohero's stuff, but that wonn't work for me. Neither does the cygwin setup here on the site (both are missing essential program which stop me right when i want to use git or update), so i'd love to have an article where i can set up cygwin easily and just start porting after it's installation.
I'm in the process of installing all the MSYS2 stuff right now, probably can drop it then.
I can do thorough testing of your todo script then, since i'm going to install everything from scratch...thank you
btw: msys2 don't work as well. I'm stuck in an infinite loop needing to build lhasa, but can't because i'm missing a working gcc...which i can only make after installing SDK.lha...which i can't due to missing lhasa
@Raziel Probabaly will finish it today, just need 3-4 hours more.
Quote:
msys2 don't work as well. I'm stuck in an infinite loop needing to build lhasa, but can't because i'm missing a working gcc...which i can only make after installing SDK.lha...which i can't due to missing lhasa
Mmm.. just to make things clear : does not matter if you on msys2 or on cygwin, you firstly need to install their GCC. Not our one. For cygwin you install cygwin's gcc, for msys2 you install msys2's gcc (mingw). Then, by that gcc you compile all the tools you need at first (and that include lhasa). Our gcc there not need it and play no role, as you build bins and stuff for that computer on which you run it. lhasa there is need it to unpack/pack .lha archive from those environments on win32, i.e. to run exactly on win32. That why their gcc used.
And only after that, you build cross-compiler gcc for amigaos4, by their gcc.
That how all crosscompilers works everywhere : you have one compiler for native (i.e. where you install it), and then, by that native compiler you compile any gcc for any other machine you need. For example, if you want to have crosscompiler for aros, morphos, aos4 and aos3 , you install cygwin (or msys2), then their own GCC firstly (without anything about amiga parts) and only then, you install those 4 crosscompilers and can use them when need it.
In other words, if you want just crosscompiler for aos4 , you end up with 2 gcc in your msys2 or cygwin environment : their one, and our one builded by their one.
Yes, i did get that. The Problem is that "their" gcc is t properly installed if i follow the msys2 script. I'm left with an error on configuring about not finding any compilers. There seem to be a mishap in the script...
edit: no acceptable c compiler found in $PATH when i try to compile lhasa
There was an error about git wanting a usrname and email adress, after that the msys2 console went bonkers. Closed, restarted msys2 and now it actually downloads and installs stuff, lets watch and wait.
Looking forward to your script, but, please, no rush, other things are far more important and i have to leave for work anyway again soon(ish)
Yeah, seems you not only one have that issue, on os4coding one dev found the same:
Quote:
seem unfortunately bintools doesn't build properly in x86_64, so you need to use the 32-bit MSYS2 tools to build. This problem comes up because in the i686 world, long and long long are the same size, but in the x86_64 world, long long is larger than long.
Not sure how to fix it all easy (and not sure if need to bother now), with cygwin you will have no issues.
Just wait few hours more and i will put article online
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
