FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  


FIFE 0.4.0 has been released on 15th of January, 2017!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - vtchill

Pages: [1]
Framework development / proposed changes for external dependency build
« on: December 21, 2009, 03:08:59 pm »
The fife team is currently working on revamping the build system to add more features and support more targets. We are looking into the external dependency building process on linux and are trying to make this as painless as possible until we can completely remove the need for the ext/ directory.

In the build rework branch on linux we currently build local versions of guichan and png libraries as shared objects and then have to insert an rpath command into the fife shared object to link correctly to these locally build libraries. This is not an ideal solution because it hard codes the path at compile time and it is generally looked down upon by those who review packages for linux distribution repositories. In the ideal situation we would not have to rely on locally built copies of these libraries and we are working on removing the need for this, but for now we need them for various reasons (a bug in guichan, and a problem with setjmp and png).

some information on rpath can be found here:

For the short term we can think of 3 options:

(1) continue the build process as we always have and use the rpath to hard code the path in the fife shared object
(2) build the libraries as shared objects and install them somewhere on the users path (such as /usr/lib)
(3) build the libraries in ext/ as static libraries and link with fife statically so the fife executable would contain these directly preventing the need for rpath.

option 1 is the current method that the build system uses but has problems as stated above

option 2 is not ideal because we do not want to overwrite any previously installed versions of the software or have them overwrite it at a later date

option 3 I can't think of many downsides to this approach except for the fact that the size of the fife executable will increase.

If you have any opinions or would like to suggest another approach please reply. Also please indicate which option you think makes the most sense. It would be helpful to hear from current fife clients on this matter.

Help and troubleshooting / runtime error handling keyboard input
« on: November 19, 2008, 09:49:30 pm »
I am running the latest FIFE trunk code with the 2008.0-r4 SDK and I noticed the error inside of Key::getAsString() function. It happens in any python script that uses the function. The scripts usually use the function like this:  evt.getKey().getAsString().lower() and perform actions based on which key was pressed.

The error line in the output window in visual studio says:
HEAP[python.EXE]: Invalid Address specified to RtlFreeHeap( 00E20000, 0D0C5858 )

The python scripts seem to run fine and the correct key is detected, but the error occurs on the SDL_free call inside of getAsString(). I have been looking at the problem for a day or so and I think it could be a problem with an external DLL and the main executable not being linked to the same common runtime library. I am linking FIFE to the multithreaded DLL version of the runtime by default using the generated solution file from the SDK. Are all the DLLs that come with the SDK linked to the multithreaded DLL version also?

Also I found a post at the boost::python wiki talking about a very similar error:

I also found a post regarding a change in python 2.5 and I started looking into the generated swig code and from what I can tell they match PyObject_New with PyObject_Free so that should not be the problem but here is the post if anyone wants to take a look

Has anyone else seen this problem on windows or could someone test this really quick on a windows machine?

Pages: [1]