Problems and solutions for installing or running FreeOrion, including discussion of bugs if needed before posting a bug report on GitHub. For problems building from source, post in Compile.
#0 0xb740f8ac in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7cb1438 in ?? () from /usr/lib/libGL.so.1
#2 0xb66154d4 in ?? ()
#3 0x00000000 in ?? ()
What do you mean it has nothing to do with the topic posted under? I get a segmentation fault. Or did you mean it has nothing to do with Programming? Yeah, i ment to put it in the Compile section, but somewhere I got that messed up.
I looked at the bug report. It matches what happens to me perfectly. When the AI finishes it's turn, then I get a segfault.
I have no special graphics drivers. I have an ATI Radeon 340M (about 5 yrs old) that I have modified in the BIOS to have 128MB of memory.
WAIT! When I ran the command you gave, freeorion gave me no segfault! Now it runs fine! I compiled log4cpp from source yesterday, if that may have helped, which I doubt. This is wierd....
Dang it!!! I ran svn update because my code was two weeks old, and then recompiled. Now it segfaults on start! It is a problem with liblog4cpp according to this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6fbe6c0 (LWP 17894)]
0xb78ab6c2 in log4cpp::TimeStampComponent::append ()
from /usr/local/lib/liblog4cpp.so.4
(gdb) bt
#0 0xb78ab6c2 in log4cpp::TimeStampComponent::append ()
from /usr/local/lib/liblog4cpp.so.4
#1 0xb78aa182 in log4cpp::PatternLayout::format ()
from /usr/local/lib/liblog4cpp.so.4
#2 0xb78a2c7d in log4cpp::FileAppender::_append ()
from /usr/local/lib/liblog4cpp.so.4
#3 0xb789bc35 in log4cpp::AppenderSkeleton::doAppend ()
from /usr/local/lib/liblog4cpp.so.4
#4 0xb78ac872 in log4cpp::Category::callAppenders ()
from /usr/local/lib/liblog4cpp.so.4
#5 0x0826a14d in HumanClientApp::HumanClientApp ()
#6 0x08276037 in HumanClientAppSoundOpenAL::HumanClientAppSoundOpenAL ()
#7 0x08279adb in main ()
I compiled log4cpp on my computer with the same compiler I used for freeorion. I have attached the strace output. Meanwhile I may have copies of the old ones I can play around with.
BTW, this segfault occurs in both the libs I compiled and the ones from the repos.
Try doing a "scons --clean" in freeorion-source and GG subdir before you change libs.
I could reproduce the segfault you mentioned and opened a bugreport about it. The problem is related to an openGL call, which may be not supportet by some graphiccards.
I have log4cpp from debian etch, had no need for compiling/installing it manually.
The OpenGL requirements for running FreeOrion are now version >= 1.5. Previously, they were version >= 1.1. This is only going to go up. Soon(tm), the requirement will be version >= 2.0.
P.S. glDrawElements() is not the problem, it's glGenBuffers(), glBufferData(), etc.
tzlaine wrote:The OpenGL requirements for running FreeOrion are now version >= 1.5. Previously, they were version >= 1.1. This is only going to go up. Soon(tm), the requirement will be version >= 2.0.
P.S. glDrawElements() is not the problem, it's glGenBuffers(), glBufferData(), etc.
I am not glad about that. That means 3 of 4 linux-system at my home won't be able to run FO any longer. Are you sure it is necessary to use GL > 2.0? What for?
Dang it!!!! This means that once the shaders are implemented I will have to wait 4-5 months before I can run it again! (still working on my gaming rig)
Would it be possible to add a command line option (--no-shaders) to disable shader support? If not I will attempt to continue resource management AI development using an older version.
freereign wrote:Dang it!!!! This means that once the shaders are implemented I will have to wait 4-5 months before I can run it again! (still working on my gaming rig)
Would it be possible to add a command line option (--no-shaders) to disable shader support? If not I will attempt to continue resource management AI development using an older version.
You might have your new rig by the time "Soon(tm)" arrives; development proceeds at the speed we can go with limited volunteer contributions. If it gets here faster than you get upgraded, my guess / inkling / impression is that shaders will be used primarily in the combat system, so it may be relatively easy to avoid / work around the steeper requirements, particularly if you're interested in development and not just playing the game.
Long term, GL 2.0 will be required. Fall-back implementations can be created that don't use earlier features, but this is significant extra work that we don't really have or want to expend the coder time on.
Additionally,
tzlaine wrote:By the time people are actually able to play FreeOrion in any real sense, they will have had lots of time to [upgrade].
Alright. If it would take to much effort, forget it. Maybe I will eventually (after v1.0) work on a modification of it that lightens the OpenGL requirements. Maybe
Right now though, I should be able to test AI out using an older version, correct?