BSA Archive Error

Support for running, installing or compiling OpenMW
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

BSA Archive Error

Post by lgromanowski » 15 Aug 2011, 12:49

EmbraceUnity wrote: Hello,

I am trying to compile 0.8

I am running 64 bit Kubuntu Maverick. I am using this Ogre 3D repo for 1.7.1 support. I manually compiled the latest CEGUI. I have the latest libOIS etc from the ubuntu repos.

I am thinking that OGRE repo might be messed up. Should I compile it from scratch?

I am getting the following error during compilation:

Code: Select all

[ 54%] Building CXX object apps/openmw/CMakeFiles/openmw.dir/__/__/components/bsa/bsa_archive.cpp.o
In file included from /home/edward/openmw-0.08/components/bsa/bsa_archive.cpp:30:                        
/home/edward/openmw-0.08/./libs/mangle/stream/clients/ogre_datastream.hpp: In member function â??void Mangle::Stream::Mangle2OgreStream::init()â??:
/home/edward/openmw-0.08/./libs/mangle/stream/clients/ogre_datastream.hpp:29: error: â??mAccessâ?? was not declared in this scope
/home/edward/openmw-0.08/./libs/mangle/stream/clients/ogre_datastream.hpp:29: error: â??WRITEâ?? is not a member of â??Ogre::DataStreamâ??
/home/edward/openmw-0.08/components/bsa/bsa_archive.cpp: In member function â??virtual Ogre::Archive* BSAArchiveFactory::createInstance(const Ogre::String&)â??:
/home/edward/openmw-0.08/components/bsa/bsa_archive.cpp:142: error: cannot allocate an object of abstract type â??BSAArchiveâ??
/home/edward/openmw-0.08/components/bsa/bsa_archive.cpp:37: note:   because the following virtual functions are pure within â??BSAArchiveâ??:
/usr/local/include/OGRE/OgreArchive.h:131: note:        virtual Ogre::DataStreamPtr Ogre::Archive::open(const Ogre::String&) const
make[2]: *** [apps/openmw/CMakeFiles/openmw.dir/__/__/components/bsa/bsa_archive.cpp.o] Error 1
make[1]: *** [apps/openmw/CMakeFiles/openmw.dir/all] Error 2
make: *** [all] Error 2
nicolay wrote: That is strange, it looks like the Ogre API in your /usr/local/include dir is different from mine. I also have a manually installed 1.7.1 so this shouldn't happen. You are sure the files in /usr/local/ are from Ogre 1.7.1 right?

(I'm using the release not the repo though so there might be differences there?)
EmbraceUnity wrote: I can't tell just by looking at my /usr/local/include/OGRE directory whether it is 1.7.1

All the last modified dates are from this February.

In my package manager, it says the version is 1.7.1.

Is there a command to find out? I know WINE uses "wine --version"
nicolay wrote: Hmm wait, could you check if you have both /usr/include/OGRE and /usr/local/include/OGRE? It's not normal for package managers to install things in /usr/local/ (that's meant for things you install manually).

You should also be able to get some useful info by running:

Code: Select all

pkg-config --modversion --cflags OGRE
EmbraceUnity wrote: The output was:

Code: Select all

~/openmw-0.08$ pkg-config --modversion --cflags OGRE
1.6.2
-DOGRE_GUI_GLX -DOGRE_CONFIG_LITTLE_ENDIAN -I/usr/local/include -I/usr/local/include/OGRE  
I'm assuming this means I have the wrong version. Probably because I almost certainly had tried to install versions of OGRE before.

I seem to have an entirely different version of OGRE at /usr/include/OGRE with Last Modified dates from April.

This looks like the ones I just downloaded since it contains all the different components like Terrain, Paging, RTShaderSystem, etc.

EDIT: I took the initiative and cleared out the old /usr/local/include/OGRE folder and copied the one in /usr/include over to /usr/local/include and the error is gone.

I am going to try recompiling with the /usr/local/include directory totally gone, to see how that goes.

If it breaks, then we have a problem since the OGRE repos default to /usr/include
EmbraceUnity wrote: I tried recompiling after deleting the /usr/local/include/OGRE directory, and the compilation threw an error immediately. Looks like that is the issue.

It would be really nice if we could check either directory for the proper OGRE version.
nicolay wrote: Sounds like you got it then, it was compiling against and old version. CMake (which is responsible for picking the dirs here) shouldn't have a problem finding OGRE in /usr/include. I guess when you have both it prefers to use /usr/local/.
EmbraceUnity wrote: Though, since it failed when I deleted out /usr/local/include/OGRE there seems to be a bit more to the story.

I think perhaps during my second compilation which threw and error immediately, it could have been because I didn't also delete /usr/local/lib/OGRE

I will do yet another compile in a bit to test that.
nicolay wrote:
EmbraceUnity wrote:I tried recompiling after deleting the /usr/local/include/OGRE directory, and the compilation threw an error immediately. Looks like that is the issue.

It would be really nice if we could check either directory for the proper OGRE version.
Hmm, ok. Then CMake might be using your pkgconfig settings (which still thinks you have Ogre in /usr/local/.) Try deleting /usr/local/lib/pkgconfig/OGRE*
nicolay wrote: In fact, go to /usr/local/ and type find -iname *ogre*, and delete everything it lists :)
EmbraceUnity wrote: I deleted out /usr/local/lib/pkgconfig/OGRE.pc

And I deleted the directories /usr/local/include/OGRE and /usr/local/lib/OGRE

And I did your find -iname suggestion and found the following results

Code: Select all

./share/CEGUI/imagesets/OgreTray.imageset
./share/CEGUI/imagesets/OgreTrayImages.png
./share/CEGUI/looknfeel/OgreTray.looknfeel
./share/CEGUI/schemes/OgreTray.scheme
./lib/libOgreMain.la
./lib/libOgreMain.so
./lib/libOgreMain-1.6.2.so
./lib/pkgconfig/CEGUI-OGRE.pc
./lib/libCEGUIOgreRenderer-0.7.2.so
./lib/libCEGUIOgreRenderer.so
./lib/libCEGUIOgreRenderer.la
./include/MYGUI/MyGUI_Progress.h
./include/MYGUI/MyGUI_ProgressFactory.h
./include/CEGUI/elements/CEGUIProgressBar.h
./include/CEGUI/elements/CEGUIProgressBarProperties.h
./include/CEGUI/WindowRendererSets/Falagard/FalProgressBar.h
./include/CEGUI/WindowRendererSets/Falagard/FalProgressBarProperties.h
./include/CEGUI/RendererModules/Ogre
./include/CEGUI/RendererModules/Ogre/CEGUIOgreTexture.h
./include/CEGUI/RendererModules/Ogre/CEGUIOgreRenderer.h
./include/CEGUI/RendererModules/Ogre/CEGUIOgreTextureTarget.h
./include/CEGUI/RendererModules/Ogre/CEGUIOgreResourceProvider.h
./include/CEGUI/RendererModules/Ogre/CEGUIOgreImageCodec.h
./include/CEGUI/RendererModules/Ogre/CEGUIOgreRenderTarget.h
./include/CEGUI/RendererModules/Ogre/CEGUIOgreWindowTarget.h
./include/CEGUI/RendererModules/Ogre/CEGUIOgreGeometryBuffer.h
./bin/OgreXMLConverter
./bin/OgreMaterialUpgrade
./bin/OgreMeshUpgrade
So I also went ahead and deleted /usr/local/lib/libOgreMain.la and /usr/local/lib/libOgreMain.so and /usr/local/lib/libOgreMain-1.6.2.so

I didn't want to touch too much else in there.

Nevertheless, when compiling, I received the following compilation error immediately:

Code: Select all

~/openmw-0.08$ make
[  0%] Building CXX object extern/caelum/CMakeFiles/caelum.dir/src/CloudSystem.cpp.o
In file included from /home/edward/openmw-0.08/extern/caelum/src/CloudSystem.cpp:21:                                                 
/home/edward/openmw-0.08/extern/caelum/include/CaelumPrecompiled.h:24: fatal error: Ogre.h: No such file or directory
compilation terminated.
make[2]: *** [extern/caelum/CMakeFiles/caelum.dir/src/CloudSystem.cpp.o] Error 1
make[1]: *** [extern/caelum/CMakeFiles/caelum.dir/all] Error 2
make: *** [all] Error 2
EmbraceUnity wrote: But it completely compiles when I copy back in the folders from /usr/lib and /usr/include into their analogous /usr/local/ locations
nicolay wrote:
EmbraceUnity wrote:But it completely compiles when I copy back in the folders from /usr/lib and /usr/include into their analogous /usr/local/ locations
Oh well :|. Good that it works at least. I'm not proficient enough with CMake to understand why one works and not the other in this case. FWIW, if you do a cp -l (make links) instead of just a copy you'll at least save about 100mb of space.
EmbraceUnity wrote: Good call
Chris wrote:
nicolay wrote:
EmbraceUnity wrote:But it completely compiles when I copy back in the folders from /usr/lib and /usr/include into their analogous /usr/local/ locations
Oh well :|. Good that it works at least. I'm not proficient enough with CMake to understand why one works and not the other in this case.
CMake likely cached the flags and stuff it detected from the old /usr/local install, so it was still looking for the headers in /usr/local/include/OGRE. You'd need to wipe OpenMW's build directory (you are building in an empty subdir, right? ;)) and re-run cmake.
EmbraceUnity wrote: damn, you're good
best regards,
Lukasz

Locked