Dependencies for OGRE 1.7/1.8 [Last updated: 19 Aug 2012]

[djs78]

Hi all, new to OGRE here. I'm trying to build on OS X 10.6.3. It seems that the regular i386 libraries in the dependencies package won't cut it anymore, as the following shows up at the beginning a long list of errors:

ld: warning: in /Users/dsmith/Library/ogre/Dependencies/lib/debug/libfreetype.a, missing required architecture x86_64 in file
ld: warning: in /Users/dsmith/Library/ogre/Dependencies/lib/debug/libfreeimage.a, missing required architecture x86_64 in file
ld: warning: in /Users/dsmith/Library/ogre/Dependencies/lib/debug/libzzip.a, missing required architecture x86_64 in file

Has anyone created an x86_64 version of the dependencies? Just want to check before I go trying to do it myself

-Don

[djs78]

Well, I changed ARCHS to just i386 and things appear to be going more smoothly... no errors yet anyway. Should I pursue x86_64 libraries for the dependencies? I'd imagine 64-bit code might benefit a 3D library.

[sinbad]

The main problem with x86_64 on OS X is that our main window interface is still Carbon, which doesn't have a 64-bit equivalent. There's an experimental Cocoa back-end in the source code but it's not enabled by default and not really finished. Apple made it tricky for us here since Cocoa generally requires a different way of running your app loop (although see the iPhone code for that, it's likely to be much the same).

[masterfalcon]

Sinbad's right on there. I've played around with the cocoa backend and it works well except for no keyboard input. I've contemplated something like deprecating the older Carbon stuff but it might be better to wait for Apple to officially deprecate Carbon. Also, Carbon/Cocoa are only used for rendering in a window. Fullscreen is handled with CoreGraphics which is fully 64-bit compatible. But in order to compile Ogre as a 64 bit framework you'd need to remove everything Carbon related.

[Assaf Raman]

I updated the first post, I added Visual Studio 2010 project files.

[jacmoe]

You are my hero, Assaf

[Assaf Raman]

I needed to fix the 2010 project files by hand - there is a new field in the config: "Target Name" under the general tab.
The problem I needed to fix was that all the post build events used the var "$(TargetName)" - until 2010 the var value was extracted from the "Output File" field in the config, in 2010 - the value of "$(TargetName)" if the new field "Target Name".
Now it is all fixed (I hope).
I attached a screenshot of the new config dialog in 2010.

I am working on building the 2010 SDK - I hope to finish it today.

[jacmoe]

I noticed that they now call it Configuration and not ConfigurationName - that broke my app wizard - but I wasn't aware of the Target Name field.

[Assaf Raman]

I am getting some link error with free image - I will fix and update the file.

[Assaf Raman]

When I link OgreMain in debug mode with 2010 - I get linkage errors for all the free image dependencies.
No clue why this happen...

[Assaf Raman]

Seems that the LinkLibraryDependencies flag isn't working for me for free image...

I will be happy for some help with this...

[Assaf Raman]

Found it! I needed to remove then re-add all the free image dependencies, now it works. I guess this was a project upgrade problem of some sort.
I will update the file later today.

[Assaf Raman]

Updated the file. Now it should work.

[sinbad]

Just started playing with VS 2010 today - the 'link library dependencies' still doesn't work properly with FreeImage, it's picking up the debug versions of EXR, JPG etc in the release configuration of FreeImage, which means when you try to link FreeImage in release mode in OgreMain, it fails like this:

Code: Select all

FreeImage.lib(libraw_cxx.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification
FreeImage.lib(IexBaseExc.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in OgreAlignedAllocator.obj
FreeImage.lib(half.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in OgreAlignedAllocator.obj
...

You can see the problem if you look at the greyed-out details of the Framework and References page, which has no configuration selector but yet points at the Debug libraries only. Also, if you look at the Librarian > Command-Line property section in Release mode you can see it pulling in the Debug libraries of EXR et al.

From the looks of it, this automatic linking feature is designed for .Net and doesn't do a very good job of managing multiple configurations with C++, I suggest going back to the manual linking.

[imi]

Just started playing with VS 2010 today - the 'link library dependencies' still doesn't work properly with FreeImage, it's picking up the debug versions of EXR, JPG etc in the release configuration of FreeImage, which means when you try to link FreeImage in release mode in OgreMain, it fails like this:

Code: Select all

FreeImage.lib(libraw_cxx.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification
FreeImage.lib(IexBaseExc.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in OgreAlignedAllocator.obj
FreeImage.lib(half.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in OgreAlignedAllocator.obj
...

I got similar output if (and only if) I didn't compile a release-version of all dependencies (including FreeImage) before running CMake. Then again - I didn't have problems compiling the release version of the dependencies.

After compiling every dependency library in Release mode and a regeneration of the solution file with CMake, the _ITERATOR_DEBUG_LEVEL stuff vanished. Still not nice. I would have expected an error from CMake like: "Library xxx and yyy are not found".

Ciao, Imi.
Edit: I am not speaking of the latest 1.7.1 - trunk (whatever its called ) of the dependencies but of a version I converted some days ago. Just want to point out that it seems for me CMake had problems and choosen the wrong library versions.

[sinbad]

No, that's not it. Not building both dependency configurations is one way of getting that same error yes, but that's not the case here. I had built all the dependencies first, and the release and debug versions were definitely getting picked up. Besides, I can see the problem in the dependencies projects themselves, debug OpenEXR etc are being linked into Release FreeImageLib because of the project-to-project references.

This is definitely an error with the VS 2010 dependencies projects as of 1 May, and it's a problem others have encountered outside Ogre too, see the comments: http://blogs.msdn.com/vcblog/archive/20 ... ences.aspx . It appears that project-to-project references, as used in the VS 2010 dependencies project on 1 May, do not work properly with multiple configurations in C++.

[sinbad]

Having checked, the other projects also appear to suffer from the same problem. The 'Link Library Dependencies' option is being used to pull in FreeImage's dependencies but Librarian > Command Line shows that the debug libraries for EXR et al are being used for the release build of FreeImage. I assume it's just not complaining because they don't have that same link-time check.

[sinbad]

Ok, strangely some combination of removing and adding the framework references locally and fiddling with the options seemed to solve the problem. I'm trying to figure out why. I must say I don't like this 'magic' way of linking at all.

[sinbad]

Just removing and re-adding the FreeImage references, as Assaf did earlier, fixed the cross-wired linking. Looks like a 2010 bug to me.

Seems you can't trust what it says in the Librarian > Command Line property area, because that doesn't change reliably when you switch configurations. The best way to check is to read the lib.command.1.tlog files in the build directories to check the right configurations are used.

[Assaf Raman]

Any idea how to fix this permanently?
Did I miss adding any file or the sort?

[imi]

Just removing and re-adding the FreeImage references, as Assaf did earlier, fixed the cross-wired linking. Looks like a 2010 bug to me.

Seems you can't trust what it says in the Librarian > Command Line property area, because that doesn't change reliably when you switch configurations. The best way to check is to read the lib.command.1.tlog files in the build directories to check the right configurations are used.

Maybe it's just a display bug? Because: Simple reopening of the properties dialog "fixes" it for me as well and the Release libs are displayed in the command line tab again.

Ciao, Imi.

[jesko]

Hello,

currently I am trying to buld OGRE 1.7 under VS2008 for EM64T.
After having buld some dependencies (not boost so far) I get OGRE compiled.
Unfortunately I get an error on start on the 64-bit machine telling me it cannot read a .zip file:

OGRE EXCEPTION(7:InternalErrorException): D:\... some path .../Media/samples/pack/SdkTrays.zip

This path is only valid on my source system (a W32 machine)! The destination machine has no drive d: ...

Ok I made a "subst d: c:\" and created the path on c:, but I think this has to be corrected ...

Do someone has a valid(!) pointer for me how to build boost for EM64T machines in a cross compiling environment ?

Thanks!

/Jesko

[CABAListic]

The path is written in the resources.cfg, you can change it there. However, that path is only used as a full path in the build directory which shouldn't be shared with another machine directly. Execute the INSTALL step in the Visual Studio solution; this will create an 'sdk' directory inside your build directory. There you should have a clean Ogre package which should work on a different machine just fine.

[jesko]

Hello CABAlistic,
thanks for the quick answer. I have produced now the SDK. Everything works fine!

/Jesko

Boost ==> W64 ?

[jacmoe]

/* Topic about building Ogre under CentOS 64 bit moved here: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=57856 */