I guess MinGW is not compiling in C++11 mode.

ripa wrote:

I guess MinGW is not compiling in C++11 mode.

Is there an easy way to turn on this behavior though? As in, are there any instructions that I could follow that you could post or link to here?

Also, following the response that I received elsewhere when asking the same question, I tried including the "include" directory in the path and even copying it over the one in the source folder, and neither worked at all. I also have strong suspicions that the instructions that were posted for building this special version of libRocket on MinGW were incorrect, or that the user uploading it didn't check to make sure that it actually builds correctly under MinGW on Windows first before making it available. The author of the IBMulator program is mainly a Linux user (and even said so himself in various posts), so that unfortunately can't be ruled out.

Still, I am open to being incorrect about this (which I hope that I am), which is why I'm asking now whether there are any proper instructions for turning on "C++11" compile mode so that I can either correct the problem there (if this corrects the problems with the build process) or at least rule that out as being the cause if it still has problems compiling.

If you cannot make MingW support C++11 then you can probably just do small changes to the source code to allow compilation. It seems most (all?) errors stem from not understanding uintptr_t type.

typedef uintptr_t CompiledGeometryHandle;

So you have few options

1) Try to include <stdint.h>
2) add a #define uintptr_t uint64_t
3) add a #define uintptr_t size_t

See if any of those work.

vladstamate wrote:

If you cannot make MingW support C++11 then you can probably just do small changes to the source code to allow compilation. It s […]
Show full quote

If you cannot make MingW support C++11 then you can probably just do small changes to the source code to allow compilation. It seems most (all?) errors stem from not understanding uintptr_t type.

typedef uintptr_t CompiledGeometryHandle;

So you have few options

1) Try to include <stdint.h>
2) add a #define uintptr_t uint64_t
3) add a #define uintptr_t size_t

See if any of those work.

I specifically need to force it to support C++11 in this case to rule that out as being the cause. What I'm trying is to compile the unmodified source code using the MinGW environment itself. And if there are already issues with compiling the libRocket source code then it's also likely that the same is true for IBMulator itself.

Anyway, I'll try to see if there are any instructions online about it. Obviously I would also try contacting the author himself if he could even be reached, but since he appears not to be online that much at all, I doubt that I would receive anything back from him in return (assuming that he even checks his messages at all), which is why I asked here instead.

C++11 support depends on the compiler that comes with MinGW: GCC. Check which version of MinGW / GCC you have. E.g., on the command line, g++ --version, if I remember correctly. The manual here explains everything: https://gcc.gnu.org/onlinedocs/

To enable C++11 support in GCC, you need to use command line switch -std=c++11 or the older -std=c++0x when invoking the compiler. The compiler is invoked by the build system used by libRocket. When building, you can probably make it print out the compiler commands as they are executed with some "verbose" switch. You can then see if the c++11 switch is being used or not. If not, you need to study libRocket's build system to find out how to enable it.

ripa wrote:

C++11 support depends on the compiler that comes with MinGW: GCC. Check which version of MinGW / GCC you have. E.g., on the command line, g++ --version, if I remember correctly. The manual here explains everything: https://gcc.gnu.org/onlinedocs/

To enable C++11 support in GCC, you need to use command line switch -std=c++11 or the older -std=c++0x when invoking the compiler. The compiler is invoked by the build system used by libRocket. When building, you can probably make it print out the compiler commands as they are executed with some "verbose" switch. You can then see if the c++11 switch is being used or not. If not, you need to study libRocket's build system to find out how to enable it.

Would typing "mingw32-make -std=c++11" at the command prompt work (as opposed to "mingw32-make" by itself as the build instructions said)?

No. "mingw32-make" is not the compiler. You need to figure out how to pass parameters to the compiler in the build system (looks like CMake in this case). This might be relevant: http://stackoverflow.com/questions/11783932/h … g-in-cmake-file

ripa wrote:

No. "mingw32-make" is not the compiler. You need to figure out how to pass parameters to the compiler in the build system (looks like CMake in this case). This might be relevant: http://stackoverflow.com/questions/11783932/h … g-in-cmake-file

I see the instructions now, but I don't completely understand them. Are the flags added when running CMAKE from the command shell, or would this require making changes to the makefile?

Are there any updates, or is this essentially a Linux-only application?

No it is not. But you have to be willing to do something about it other than just wait for it to magically work perfectly. If you are not willing to tinker with it you will not get far. Open source software is often like that. You are unfortunately waiting for someone to give you the magic command line which won't happen.

Like I gave advice before few posts before you might need to dive in, make some changes.

Yes, this will require either changing the makefile file or the source code itself.

Just try different things.

Did you try this yet:

When building, you can probably make it print out the compiler commands as they are executed with some "verbose" switch.

For that you can try add "VERBOSE=1" or "-n" to your make command or export "CMAKE_VERBOSE_MAKEFILE=ON".

vladstamate wrote:

No it is not. But you have to be willing to do something about it other than just wait for it to magically work perfectly. If yo […]
Show full quote

No it is not. But you have to be willing to do something about it other than just wait for it to magically work perfectly. If you are not willing to tinker with it you will not get far. Open source software is often like that. You are unfortunately waiting for someone to give you the magic command line which won't happen.

Like I gave advice before few posts before you might need to dive in, make some changes.

Yes, this will require either changing the makefile file or the source code itself.

Just try different things.

The problem here is that the users in this thread never provided any evidence at all to suggest that this would correct any of the issues that I have with compiling it, since from what I can tell it's quite clear that they did not try this for themselves. If anyone here had actually tried compiling it in Windows using the instructions that the author provided, then they would actually know what was going on and as such would be in a far better position to provide assistance in this topic.

Switching between different versions of the source code is also problematic (not to mention extremely inconvenient to say the least) which is why I'm only going to follow whatever instructions are by far the most likely to correct any of the problems here. If there is no evidence at all to suggest that the users replying did not actually try this for themselves, then I'm extremely doubtful that their suggestions would even have any effect at all.

And as I said beforehand, I would definitely have contacted the author of the program itself for assistance in this case, but since the author does not even appear to be active at all, then I simply assumed that I wouldn't get a reply from him.
================================================================================================================================
What I really need, most of all, is for at least one person here to actually TRY compiling it in Windows for themselves, so that they would at least be able to try to see what's going on and to try to correct any issues from there. Only then would they actually know if there is a way to correct this issue. I would also try the same thing myself except that I'm already quite busy with other software-related projects as it is, and even then that's only when I'm at my PC.
================================================================================================================================
EDIT: The problem here is not with the main IBMulator program (although that might also be experiencing compile errors under MinGW) but rather with the special version of libRocket that it requires. What I really need is for someone to at least be able to compile the special version of libRocket (which is available from the author's page).

Then all I can say is good luck!

ripa wrote:

Then all I can say is good luck!

Then what's the point of responding? If it's quite clear that you haven't tried this yourself, then naturally most people would simply assume that it would either make the problem worse or (at best) have no effect at all. You said that you had some possible solutions, therefore it is entirely up to you to prove that they would work. It is not up to everyone else to prove the negative; it is up to you yourself to prove the positive.

And some of us don't have time to go through trying each and every possible and conceivable feature modification for ourselves, because many of us simply don't have the time to do all of that. Many people here have jobs, or are working on their own software projects, or are working on other types of projects in general.

Anyway, I'm going to try some of these suggestions anyway, once I have the time, but it's doubtful that any of them would work at all if there was no evidence to support any of these claims.

My first PC ever was a PS/1 model 2121 386SX/16. I have fond memories of that four quadrant start screen with archaic DOS 4.0 and Windows 3.0

Alas my main rig is Windows 7 32-bit for reasons of backward compatibility so IBMulator doesn't run on my main rig being 64-bit, although I have seen it in action. I can get PS1 2121 emulation through PCEM, but it's not quite the same.

If you do manage to recompile IBMulator, I'd implore you to make it 32-bit as well. 😀

Thanks.

- SoftPCMuseum_: It takes literally a few minutes to do the few changes to the makefiles and the code you were suggested to do, and compile. And you clearly have time to post complaints this long on a forum, so how do you not have time to do the change?
While I agree with you on some things, I really think you should stop expecting people to serve you things on a silver platter...

Battler wrote:

- SoftPCMuseum_: It takes literally a few minutes to do the few changes to the makefiles and the code you were suggested to do, and compile. And you clearly have time to post complaints this long on a forum, so how do you not have time to do the change?
While I agree with you on some things, I really think you should stop expecting people to serve you things on a silver platter...

I did not mean for this to sound like I was expecting people to serve me things on a silver platter, since that was not my intention at all. All that I was asking for was evidence to suggest that this would actually work (or to prove that they had actually tried this for themselves) because otherwise it would have been a complete waste of my time if that was not the case. Infact, I actually tried spending considerable amounts of time working on setting up the development environment, time that had already taken me away from my own emulator's development as it is, since it involved not only setting up the MinGW environment and terminal, but also configuring each series of tools required by the development environment so that it was exactly what the author stated was required, with all of this in the end becoming an extremely complicated process in itself. If I had been expecting everyone to serve me everything on a silver platter then I clearly wouldn't have gone into this much effort in setting up such a completely new environment (and even sacrificing some time that would normally be used for developing my own emulator in the process).

Remember that this was also done at my expense at that (as stated quite clearly above), so if I am not able to continue from there, then there is a very good reason for why that is the case. Remember that a similar case would occur for someone writing BASIC programs if they were to switch over from writing for AppleSoft BASIC to GWBASIC or Microsoft QuickBasic - they would also have to devote major amounts of time in setting up a completely new development environment, not to mention relearning much of the BASIC language since there are major differences between the two. They would also need help in switching over to the new "dialect" of BASIC at that.

ripa wrote:

C++11 support depends on the compiler that comes with MinGW: GCC. Check which version of MinGW / GCC you have. E.g., on the command line, g++ --version, if I remember correctly. The manual here explains everything: https://gcc.gnu.org/onlinedocs/

To enable C++11 support in GCC, you need to use command line switch -std=c++11 or the older -std=c++0x when invoking the compiler. The compiler is invoked by the build system used by libRocket. When building, you can probably make it print out the compiler commands as they are executed with some "verbose" switch. You can then see if the c++11 switch is being used or not. If not, you need to study libRocket's build system to find out how to enable it.

Normally double-posting might not be allowed here, but do you know where the switch is supposed to be added in the Makefile? I currently have it open on my PC, but I have no idea as to where the flags are supposed to be placed, especially given how large it is (for a text file, that is). When invoking the compiler again, I see now that the file itself is created automatically when running the "mingw32-make" command.

EDIT: Apparently, I had the wrong file. The correct file was CMakeLists.txt. Still, I am not at all sure as to where the commands are supposed to be placed, especially since there are separate listings for different platforms.

EDIT 2: There is also another file called CMakeCache.txt, which also uses compile flags. Still, I am not sure as to where these specific flags should be placed.