Wesnoth on Irix

[silene]

Code: Select all

ld32: ERROR   33 : Unresolved text symbol "image::locator::locator(const image::locator&)" -- 1st referenced by variable.o.

I'm sorry, I can't help you here, I'm at loss. This file should not need this symbol. If you are couragous, you can take a look at the assembly output the compiler creates and find in which functions this symbol is used. Maybe it will give us a clue as to why this symbol appears.

[Joerg]

Is there any reason why the irix related fixes reverted from todays cvs?
mapgen.cpp and sdl_utils.cpp doesnt contain the std::floor entries anymore which are needed for compiling with the mips cc compiler.

regards
Joerg

[Dave]

Is there any reason why the irix related fixes reverted from todays cvs?
mapgen.cpp and sdl_utils.cpp doesnt contain the std::floor entries anymore which are needed for compiling with the mips cc compiler.

Because VC++6 requires floor instead of std::floor. Can you tell us if changing #include <cmath> to #include <math.h> at the top of the file fixes the problem in Irix?

David

[Joerg]

Is there any reason why the irix related fixes reverted from todays cvs?
mapgen.cpp and sdl_utils.cpp doesnt contain the std::floor entries anymore which are needed for compiling with the mips cc compiler.

Because VC++6 requires floor instead of std::floor. Can you tell us if changing #include <cmath> to #include <math.h> at the top of the file fixes the problem in Irix?

David

This was my first solutionen to pass the problem when i remember correctly. But i w'll check this again.
Whats about with some #ifdefine __sgi to wrap around the problem?

regards
Joerg

[Dave]

There are a few possible solutions we can use if #include <math.h> doesn't work.

Since it's really VC++ that exhibits non-conforming behavior, I guess it should be the compiler that is 'special cased'.

One possible solution is to have a header file of our own, "cmath.hpp", which is defined as #include <cmath> on all systems, except for VC++, on which it is defined as,

Code: Select all

namespace std {
#include <cmath>
}

which I believe would work...

David

[silene]

Since it's really VC++ that exhibits non-conforming behavior, I guess it should be the compiler that is 'special cased'.

One possible solution is to have a header file of our own, "cmath.hpp", which is defined as #include <cmath> on all systems, except for VC++, on which it is defined as,

Code: Select all

namespace std {
#include <cmath>
}

Here is another proposal. No idea if it will work correctly though. In global.hpp for example.

Code: Select all

#ifdef _MSC_VER
#include <cmath>
namespace std {
  using ::floor;
  using ::sqrt;
};
#endif

As a side note, I see that global.hpp uses _WIN32, I think it would be better if we were using _MSC_VER, so that the pragmas don't prevent compilation on any other compiler on Windows.

[Joerg]

When runing wesnoth on irix machine which have 2 GFX boards that using the xinerama feature to span the desktop over both screens the game wont start. A message like is shown. It also dont work when use the '-w' flag.

Code: Select all

[user@chainsaw:/usr/people/user$/usr/nekoware/bin/wesnoth 
started game: 892796734
   X Error of failed request:  BadRequest (invalid request code or no such operation)
   Major opcode of failed request:  128 (XINERAMA)
   Minor opcode of failed request:  4 ()
   Serial number of failed request:  10
   Current serial number in output stream:  10
  user@chainsaw:/usr/people/user$

It works when xinerama is disabled.

regards
Joerg

[silene]

When runing wesnoth on irix machine which have 2 GFX boards that using the xinerama feature to span the desktop over both screens the game wont start. A message like is shown.

Hmm... except for clipboard handling, we never mess directly with X. So I would say it is a SDL issue. Are you able to run any other SDL program on this machine when Xinerama is enabled?

[Joerg]

When runing wesnoth on irix machine which have 2 GFX boards that using the xinerama feature to span the desktop over both screens the game wont start. A message like is shown.

Hmm... except for clipboard handling, we never mess directly with X. So I would say it is a SDL issue. Are you able to run any other SDL program on this machine when Xinerama is enabled?

Yes.... other programms have the same problem . I take further information to find out whats going wrong. But its good to know that the error is not in wesnoth. Thank you.

regards
Joerg

[sirtobi]

Yes.... other programms have the same problem . I take further information to find out whats going wrong. But its good to know that the error is not in wesnoth.
Joerg

Have you got wesnoth to work with Xinerama now?
I'd like to have a solution, i have the same problems with Solaris/Sparc....

wys

SirTobi

[Joerg]

Yes.... other programms have the same problem . I take further information to find out whats going wrong. But its good to know that the error is not in wesnoth.
Joerg

Have you got wesnoth to work with Xinerama now?

No.

I'd like to have a solution, i have the same problems with Solaris/Sparc....

I havent the 2 gfx setup anymore so the problem went away . But maybe its time to kick the libSDL guys.

regards
Joerg