Error 2 from incomplete type Ogre::LogManager and LML_TRIVIAL not declared in scope when compiled as debug #2587
Comments
|
We test every commit with GCC 7.5.0 on Travis, but it should build with newer versions @tritonas00 What version of GCC do you use? |
|
10.2.0 |
|
The code that causes the error is only used in debug builds @happysmash27 Could you try and build in release mode and see if that fixes the error? |
|
Both GCC 7.5.0 and 10.2.0 give the same errors as 8.4.0 (though the warnings for unrelated issues are slightly different). As for building as release… that would be The documentation in BUILDING.md seems to suggest that the target name should be "RELEASE", but this fails with: So I ended up going with what the online search results said. The documentation in general seems to be pretty unclear; there appears to be no section on which commands to run, so the only reason I was able to compile at all was that I had used Cmake a few times before, and could guess the process. I've added a note to my task list to look into improving the documentation on compilation once I have finally gotten everything to compile, for anyone that likes compiling from source but may have not encountered CMake much yet. …And actually, speaking of which, it finally compiled! Actually trying to launch it leads to missing resources though. Zipping the contents of each folder into individual zip files under bin/resources, however, seems to work, e.g, assuming one is in the build/bin directory, to include "skeleton" one would use: Then go back into the main resources directory and to the next subdirectory to zip the next contents, and so on. It may be useful to implement this in the compile script at some point, maybe, unless it was already included and my setup was just suboptimal. After doing this, there is still at least one other error: But that is an error for another day, and probably a separate issue again, since it is technically separate. |
did you run |
|
Our up to date build instructions can be found here: https://github.com/RigsOfRods/rigs-of-rods/wiki/Compile-(Linux) As for the mygui error, it should be fixed in this commit: a2623cb |
That worked much better than doing it manually. Thank you very much! |
happysmash27
changed the title
|
Patching the commit made everything run correctly. So, now all that's needed in this issue is for it to work correctly in debug. I have edited the title to reflect that. |
|
...Wait, already closed. Hmm. |
|
I would not consider it a closed issue, since although it is still possible to run the program, this issue could make it harder to debug it. |
|
Ok then. Can you try with |
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following is my
makeoutput all redirected to the file many_errors.log then copied into GitHub:Err... that's a bit much. It's hard to see where the thing that causes error 2 even is! That is certainly a lot of deprecated calls.
But anyway, after redirecting everything to a single file using
make >many_errors.log 2>&1it is easy to open the file in emacs and search for "error" to find the issues:I am using GCC 8.3.0, selected as my system compiler as it gave the best compatibility for compiling dependencies of boost in my most recent Gentoo world upgrade. I find that these types of issues usually have to do with new GCC versions, so it is important to note.
So... which GCC versions are Rigs of Rods compiled on that do not give this error, if any (assuming that is even the root of the issue)? If they are older than GCC 8.3.0, perhaps it may be wise to fix the issues that appear on newer compilers. The more time goes on, the harder it gets to make older compilers keep working. The oldest compiler I have working on my system is gcc-4.9.4, and even then I had to explicitly unmask it for it to remain installable. It is a shame backwards compatibility is often so bad on GNU/Linux.
The text was updated successfully, but these errors were encountered: