Latest Posts

Topic: Cann't start build 15 but the rc2 works

ModellbahnerTT

Topic Opener
Joined: 2009-07-19, 11:58
Posts: 70
Ranking
Likes to be here
Posted at: 2010-04-17, 13:28

Hi @all,

Under widelands biuld 15 i´on a 64 bit Linux System I get this Error: SDL_VIDEODRIVER=& Graphics: Trying Video driver: 0 x11 SDL_VIDEODRIVER=x11 * GRAPHICS REPORT VIDEO DRIVER x11 hw surface possible 0 window manager available 1 blitz_hw 0 blitz_hw_CC 0 blitz_hw_A 0 blitz_sw 0 blitz_sw_CC 0 blitz_sw_A 0 blitz_fill 0 video_mem 0 vfmt 0x2c27a20 size 800 600 * END GRAPHICS REPORT

hw avail:0Graphics: flags: 0 Speicherzugriffsfehler (Speicherabzug geschrieben)

Under the rc2 from build 15 this erreor doesnt come and I can play it.


Top Quote
timowi

Joined: 2009-11-01, 23:08
Posts: 146
Ranking
At home in WL-forums
Location: Germany
Posted at: 2010-04-17, 18:17

Hi,

which version do you run? The static binary from the widelands Download Page?

which Linux Version do you run? Graphic drivers and settings are interesting too.

Timo


Top Quote
ModellbahnerTT

Topic Opener
Joined: 2009-07-19, 11:58
Posts: 70
Ranking
Likes to be here
Posted at: 2010-04-17, 18:28

I run Kernel Version 2.6.32 with the orginal Nvidia Driver from rpmfusion. The Version is the static binary from the downloadpage in both falls. My Linux is at the moment Fedora 12.


Top Quote
timowi

Joined: 2009-11-01, 23:08
Posts: 146
Ranking
At home in WL-forums
Location: Germany
Posted at: 2010-04-17, 18:40

Hi,

thats bad :(. I have build the static binary and I thought it would work even better than the rc2 one. Unfortunately I am not at my 64Bit system before Monday.

Can you please try to start wideland with --nosound? Would be nice to know if this helps.

The difference between rc2 and this on is that I also linked in static libpthread, libm, libc and libgcc. I think this can be a libc or libpthread related problem.

Timo


Top Quote
ModellbahnerTT

Topic Opener
Joined: 2009-07-19, 11:58
Posts: 70
Ranking
Likes to be here
Posted at: 2010-04-17, 20:12

With the option nosound it work but after close I see this Error in the Console:

LANG de, LANGUAGE de:de Sound_Handler closing times 0, freq 4203759, format 0, chan 0 Speicherzugriffsfehler (Speicherabzug geschrieben)

The next Problem which does in the rc2 work and in the final not is the choose of the Language.


Top Quote
timowi

Joined: 2009-11-01, 23:08
Posts: 146
Ranking
At home in WL-forums
Location: Germany
Posted at: 2010-04-17, 20:58

Many thanks for your report and sorry for the inconvenience. The static linking is a quite complex process and I had not enough time to really test this. It will investigate some more time and will provide a new executable as soon as possible. As I said this will not happen before Monday. My x86_64 system is just too far away. I think the locale problem is caused by the linked in glibc.

Timo


Top Quote
ModellbahnerTT

Topic Opener
Joined: 2009-07-19, 11:58
Posts: 70
Ranking
Likes to be here
Posted at: 2010-04-17, 21:07

What is the matter that the 64 bit version is not dynamic linked like the 32 bit version?


Top Quote
timowi

Joined: 2009-11-01, 23:08
Posts: 146
Ranking
At home in WL-forums
Location: Germany
Posted at: 2010-04-17, 22:11

The dynamic linked executable runs on even less systems the the static one. And for b15 final the is also a static 32 bit one. To run a dynamically linked executable you need exactly the same versions of the libraries as the one who build it. If I for example linked it against libjpeg-v7 and you have v6 or v8 (which are both common now) you can not start it. A statically linked on should ideally run on every system. But some libraries rely heavily on the system so it is better to link the statically. And some libraries have a stable api and there is only one api version out there. One example for this is libpthread.

Timo


Top Quote
ixprefect

Joined: 2009-02-27, 14:28
Posts: 367
Ranking
Tribe Member
Posted at: 2010-04-18, 12:24

I believe that statically linking libraries like glibc and libpthread is actually counter-productive. For example, I believe glibc uses some kind of plugin system for hostname lookup, and so using a statically linked version may cause incompatibilities. Statically linking SDL should be fine in theory.


Top Quote
timowi

Joined: 2009-11-01, 23:08
Posts: 146
Ranking
At home in WL-forums
Location: Germany
Posted at: 2010-04-19, 10:30

Here is a new one

http://home.arcor.de/wingender/widelands-build15-x86_64-static-v2.bz2

This is the executable only. Copy it to the original buil15 folder. This should be work just like the rc2 one.

@ixprefect: I have written a too long mail about this already on the mailinglist. But I think nobody will ever read it :). Not only glibc but also the SDL libraries use a plugin system. The plugin system from glibc is no problem. It is not incompatible but it requires a glibc at runtime. I think the problem here (the segfault) was libpthread. I have already warned before that this is possible. Maybe this was the proof. Some libraries are compiled different and threads (under linux) are know not to be portable.

It sometimes is just better to link dynamically as this respects how libraries were compiled for the destination system. These may be system path and differences of the system. This is why I do not compile in libX11, libGL etc in the SDL libs statically.

Glibc seems to be a good candidate to be linked statically. Now this one is linked against glibc2.8. The target system needs glibc2.8 to run this executable. If I link glibc statically it needs glibc2.6 or glibc2.8 (maybe even earlier versions work) at runtime for the hostname plugin system. But I think the different locale behaviour is caused by the static glibc version. As far as I know gettext comes from glibc for us. This may be configured different on my system and a target system.

It's quite difficult to build the perfect binary.

Timo


Top Quote