Through, firstly try it. As seems (at least from my first try) there can be some issue with new Bison, when it by some reasons tried to parse in adtools's libintl some .y file, and seems done it wrong, and one of the files can't compile. I found in google some fixes, but then, somehow that problem auto fixes, and i can't reproduce it anymore : that why i didn't write about in article.
So, try it firstly, if you will meet with the same error when will build adtools, and expectually that libintl, i may try to check it again, as i probably fixed it for myself, just can't by some reasons rollback to recheck it.
Is there anything different I have to look out for when I want to install third party libs, like libsdl, libpng and such or does it work just like with the native SDK?
Approx. 1h 45mins, if done completely with configure beforehand. Yes, I know it will easily be three or more times faster on the pc, but I want to keep the build native since that should still be the ultimate aim, shouldn't it? To have a working SDK that is able to compile such big projects. Otherwise we can drop the whole native sdk development and let the devs focus on something else.
I do still have one question. Does cross compiling support shared builds/objects? I know that shared builds are turned off for the cross builds (buildbot, through a linux server) in scummvm since it does not build working binaries.
Yes, I know it will easily be three or more times faster on the pc, but I want to keep the build native since that should still be the ultimate aim, shouldn't it? To have a working SDK that is able to compile such big projects. Otherwise, we can drop the whole native SDK development and let the devs focus on something else.
Just IMHO is that as we have no resources, we already need to drop in SDK all those Autotools, CMake, automakes and whatever else. They always VERY old, and never up2date, and never bug-free. What we need from SDK, its everything else which left: native libraries for clib2 and newlib, includes, native GCC (yeah, to compile natively on os4 anyway).
We anyway have NO SDK updates at all anymore (and I not sure if we ever will), so why we need to hold things inside, which will be mostly of no use because of different factors :) But anyway that not big deal, what we have now already enough, especially when there is ability to cross-compile things.
Quote:
I do still have one question. Does cross compiling support shared builds/objects? I know that shared builds are turned off for the cross builds (buildbot, through a Linux server) in scummvm since it does not build working binaries.
Cross-compiling in no way anyhow different from a native building. Just you build amigaos4 things by x86 binaries, but still, everything as on native. Of course, you can build the same shared objects and whatever else. Everything the same as native, just bug less and issue free when it comes to Autotools and stuff.
I never like sobjes, but I still build one app which uses them: LodePaint, and that one I build on Cygwin's cross-compiler, so yeah, no problems.
Wrt to native compiling... Our system will die even faster if there won't be an up to date native compiler anymore. The reason is easy. If a dev cross compiles he/she is already working most of his/her time on a foreign system. Why would he/she care anymore once we really lose a native sdk?
I'm just talking from my pov, if I'd be forced to compile everything on a foreign platform, I'd sooner or later drop the hassle and simply use the program on said foreign platform (at last if my hardware dies).
And right now, I don't want to do that, I want to be able to do everything on amiga, for how long...I don't really know. Since I don't do high end gaming, I could already switch to windows or linux with my (gaming) interests (scummvm residualvm, uae). I would even have less to care about... And I fear that this might be one of the main reasons why no new users arrive...why would they bother with so much drawbacks?
If we start to let the native sdk stuff die too why would any outside devs, let alone users, care to use amigaos?
Plus, it's awesome as hell to be able to natively compile programs on amigaos.
I'm not 100% sure. I am currently working on an arexx script that uses ffmpeg -i (run from Art Effect to build a preview of 20 thumbnails from a selected video, and then prints data about the video at the top). It's working ok, but I can't figure out how to accurately parse fps, and I'm getting the resolution from a frame grab, which could be problematic if I decide to go with scaling.
When I google some of the features of -i, I'm seeing a number of threads where people are asking questions, and somewhere in the answers someone says "just use ffprobe".
I'm thinking of switching to mplayer. It appears to produce data on a video in an easy-to-parse format, although some of the results I don't quite understand (codecs are returned as codes, so I guess I would need to map those to whatever).