jury

Yes, it seems as you say, cmake always finds mman.h (must be that linux one) so configures build scripts accordingly. But when cross-compiling, the destination platfor does not have this library, thats why I wanted to try to switch this off manually. Great, will check it today. Thanks.

Well, it seems that this optional HAVE_MMAP is broken, unless I do not understand something, but I can not find any code for not Windows or mmap. I decided to check it on linux environment, so in VFS.cpp I undefined HAVE_MMAP (#undef HAVE_MMAP) and compilation goes fine, but linking ends with: MappedFileMemoryStream.cpp:69: undefined reference to `GemRB::readonly_mmap(void*)

The videos did not have sound, but the main menu and the game itself had the music and sound effects.

OK, my linux machine was freezing because I forgot to free what I malloc'ed And when I run "htop" before starting gemrb, I saw it could eat 3 gigabytes in few seconds. And as I do not use swap in my operating systems and linux memory management is as is (if I remember correctly, when I was using Windows it always informed that it does not have more memory not allowing to continue what I wanted so never froze because of no memory) it sometimes crashed and most of the times it was freezing the machine to the state that only cutting power supply from it worked. After freeing the malloc'ed chunks it works fine, so that malloc is ok (and I was pretty sure that the malloc was the culprit) And as for the destination platform, I could not find the accurate answer to the question on thread support so I asked one of the operating system devs. And I got a short answer, the platform does not support threads

Thanks, I have some ideas why that build completely freezes my linux box. Will try to investigate it. Yes, I've checked sources now and its optional since 0.8.8. And I tried to adjust it to my destination platform firstly because of course it is mandatory in 0.8.7 and secondly because when I read a bit on mmap it seams that it could be ideal for my platform, as I have read that mmap can out-perform standard file access methods. And optimization of file access is definitely on my list of things to take care of after all will build fine and will be stable. So I will spend some more time to try to "simulate" mmap, but not too much as its not the highest priority for me.

Great, thanks. And if it goes for thread support, I still do not have a sure answer, so I need to dig more. But meanwhile I decided to continue the work on adjusting code to compile for the destination platform. The next (and I think the last one) thing is replacing mman.h stuff as we do not have this library. I have read some stuff on what this library is and if I'm not wrong all I need to do is to adjust readonly_mmap function in VFS.cpp. I came up with something like this: void* readonly_mmap(void *vfd) { char *tab; int fd = fileno(static_cast<FILE*>(vfd)); struct stat statData; int ret = fstat(fd, &statData); assert(ret != -1); tab = (char*)malloc(statData.st_size); fread((char*)tab, statData.st_size, 1,static_cast<FILE*>(vfd)); return tab; // return mmap(nullptr, statData.st_size, PROT_READ, MAP_PRIVATE, fd, 0); } right before sleep yesterday. It compiled fine on my linux box and first Baldurs Gate started! So I thought that today its just a matter of couple of clicks and I will have a working 0.8.7 on the destination platform. But no success, gemrb doesnt even start there (havent "debugged" it yet why) giving segfault and on linux box it starts fine, but quite fast it crashes or hangs the machine the way that only hard reset helps (cant even switch to console to kill the process, not many things can kill linux this way) Do you have any clues why the above could behave like that, or have a better idea how to replace mmap function?

I have downloaded latest sources from git repository and the first compiler errors I hit were connected to threads (condition_variable, mutex, thread) and as far as I know, this toolchain does not have thread support. I've searched the sources regarding this and found out that quite some modules use this approach in git sources, so I guess this is a show stopper (unless you have some neat peak) But I need to dig in some more on this subject thou, as I do not understand it for sure. The toolchain has got all the required .h include files, so during compilation it doesnt complain that it can not find them. But from what I have read many times that "our" platform doesn't support threads, period. So I will try to find out why the toolchain has the includes which can not be used. So now, I guess I have to fall back to 0.8.7 version. Especially that when I left it over 2 weeks ago, I remember there were only 2 more things standing in the way to finish compilation.

Thank you! I will be back with the results.

I've checked the projects that I thought in their README's I've seen some macros that would fit what you need, but with no success. So I've searched the web to see if its possible to list all macros and found something like this "-dM -E - < /dev/null" And after searching the results, I think I found something what almost for sure was created exactly for this purpose: __MINT__

Great!

As a no c/c++ developer I can write silly things, so feel warned But I see it this way: I do not have knowledge from the roots, and there is quite some history there for sure, but at some point "our platform" received really nice tool for cross-compilation, based on gcc 4.6.4. It was not 1:1 "conversion" as in "normal" gcc at the point of 4.6.4 the standard library for example had math library integrated. But "our" toolchain still had this library externally, so when I cross-compile most of things I must provide the linker with "-lm" flag. Now we have gcc 9.sth.sth (and if I remember well, there is already 10.x.x or even 11) but its base is still that 4.6.4 one, so the story continues. And if I remember correctly, those functions I decapitated where some math functions (log or sth like this) so this is why it compiles without "std::" prefix and complains otherwise. As for the second question, hmm, no idea, but I think I had seen something like that in some cross-compiled project, so will check there and be back.

OK. I have got something. I'm not a professional c/c++ developer, just a hobbyist with some knowledge of c and almost non knowledge of c++ (well, it theory I quite understand the workings of object oriented programming, but never coded anything in oop) So this is what I got when searching the web on making diff file. If its not what you expect, just let me know and I will correct myself. This is a current state of patching the source for the need of cross-compiling for atari platform. I have not had a chance to work on this for the last 2 weeks unfortunately, but this weekend I should have a lot of free time so I will try to finish this having a working binary diff.txt

Sorry for late reply, but I have missed your post. I will try to get you the current diff today (85% chance) or tomorrow (99.999999999999% chance [I never say 100% ] )

The MC68x is Ataris last computer (Falcon 030) accelerated to the possible max (68060 CPU, faster RAM, better and faster graphics subsystem) and the ColdFire CPU one is FireBee which is a fan continuation of Atari line. So far I have tested gemrb on the first one. I have wondered a little through first Icewind Dale and Baldurs Gate and it performs mostly OK. And if it goes for FireBee, I have not tested it yet, but I'm pretty sure it will perform just fine. I have to try if thou. Here is the first one. You could make module (I do not have access to sources now, so I write just from memory) PluginLoader excluded from builds which are statically linked. Above platform does not have dynamic libraries (well, it has, but its kinda weird and nobody uses it) or dynamic loading. So to compile PluginLoader.cpp I needed to comment out dlfcn.h (as there is none on the mentioned platform) and tweak some code which uses dlfcn.h functions to NULLs (or whatever as this module never executes when all is linked statically)

Doh... I do not know how I did not see this allignment ifdef. OK, about 90% of sources compiled, enough for now. Thank you.