CMake build system for Cthugha *looking for testers*

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Locked
ender
Halfling
Posts: 99
Joined: Sat May 24, 2008 6:46 am

Re: CMake build system for Cthugha *looking for testers*

Post by ender »

I'm getting the very same error as aguru above and not sure how to get past this.

How do we build ogre dynamically (not well versed w/ cmake).

Code: Select all

...
Scanning dependencies of target Sample_TextureFX
[ 94%] Building CXX object Samples/TextureFX/CMakeFiles/Sample_TextureFX.dir/src/TextureFX.cpp.o
Linking CXX shared library ../../lib/Sample_Smoke.so
[ 94%] Built target Sample_Smoke
Scanning dependencies of target Sample_Transparency
[ 95%] Building CXX object Samples/Transparency/CMakeFiles/Sample_Transparency.dir/src/Transparency.cpp.o
Linking CXX shared library ../../lib/Sample_Terrain.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ld: ../../lib/libOgreTerrain.a(OgreTerrain.cpp.o): relocation R_X86_64_32 against `Ogre::StringUtil::BLANK' can not be used when making a shared object; recompile with -fPIC
../../lib/libOgreTerrain.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [lib/Sample_Terrain.so] Error 1
make[1]: *** [Samples/Terrain/CMakeFiles/Sample_Terrain.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Linking CXX shared library ../../lib/Sample_Transparency.so
[ 95%] Built target Sample_Transparency
Linking CXX shared library ../../lib/Sample_TextureFX.so
[ 95%] Built target Sample_TextureFX
make: *** [all] Error 2

hd_
Gnoblar
Posts: 9
Joined: Sat Oct 24, 2009 2:12 pm

Re: CMake build system for Cthugha *looking for testers*

Post by hd_ »

I am slowly getting Ogre compiled, one step at a time :P I must be the only person who uses mingw+codeblocks or something, because I had to change some things in source to get it going- those things were:
OgrePlatform.h - comment out a section as follows:

Code: Select all

// Disable unicode support on MingW at the moment, poorly supported in stdlibc++
// STLPORT fixes this though so allow if found
// MinGW C++ Toolkit supports unicode and sets the define __MINGW32_TOOLKIT_UNICODE__ in _mingw.h
#if defined( __MINGW32__ ) && !defined(_STLPORT_VERSION)
/*#   include<_mingw.h>
#   if defined(__MINGW32_TOOLBOX_UNICODE__)
#	    define OGRE_UNICODE_SUPPORT 1
#   else
#       define OGRE_UNICODE_SUPPORT 0
#   endif
#else*/
#	define OGRE_UNICODE_SUPPORT 1
#endif
In one of sinbads forum posts, he seems to have said new versions of mingw have no problems with unicode- commenting out seems to have no ill effects.

OgreWin32Prerequisites.h - add define as following:

Code: Select all

#define WINVER 0x500
#include <windows.h>
The window headers that I have conditionally include some needed defines on "if (_WIN32_WINNT >= 0x0500 || _WIN32_WINDOWS >= 0x0490)", (my WINVER is set to 0x403). It seems to be ok to override WINVER in the manner I have, according to my version of windef.h. Maybe I just have some old windows header files or something ? (I'm on vista by the way)

CMake doesn't seem to find ois in the dependencies folder if it's a dll? I had to compile a static library. Then I had to add -ldinput8 -ldxguid to samplebrowser in link.txt to get that one working.

I keep getting these kinds of errors when compiling the samples:
Linking CXX shared library ..\..\bin\Sample_SkyDome.dll
C:\MinGW\bin\g++.exe -shared -o ..\..\bin\Sample_SkyDome.dll -Wl,--out-implib,..\..\lib\libSample_SkyDome.dll.a -Wl,--major-image-version,0,--minor-image-version,0 CMakeFiles\Sample_SkyDome.dir\src\SkyDome.cpp.obj -LC:\Boost\lib ..\..\lib\libOgreMain.dll.a ..\..\..\Dependencies\lib\release\libOIS.a ..\..\..\Dependencies\lib\release\libzlib.a ..\..\..\Dependencies\lib\release\libzziplib.a ..\..\..\Dependencies\lib\release\libFreeImage.a ..\..\..\Dependencies\lib\release\libfreetype235.a C:\Boost\lib\libboost_thread-mgw44-mt-1_39.lib C:\Boost\lib\libboost_date_time-mgw44-mt-1_39.lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
Error running link command: The system cannot find the file specified
mingw32-make.exe[2]: *** [bin/Sample_SkyDome.dll] Error 2
mingw32-make.exe[1]: *** [Samples/SkyDome/CMakeFiles/Sample_SkyDome.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2
Info: resolving Ogre::Vector3::ZERO by linking to __imp___ZN4Ogre7Vector34ZEROE (auto-import)
Info: resolving Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME by linking to __imp___ZN4Ogre20ResourceGroupManager27DEFAULT_RESOURCE_GROUP_NAMEE (auto-import)
Info: resolving Ogre::Quaternion::IDENTITY by linking to __imp___ZN4Ogre10Quaternion8IDENTITYE (auto-import)
Info: resolving vtable for Ogre::Exception by linking to __imp___ZTVN4Ogre9ExceptionE (auto-import)
Info: resolving Ogre::Math::fDeg2Rad by linking to __imp___ZN4Ogre4Math8fDeg2RadE (auto-import)
Info: resolving Ogre::Vector3::UNIT_Y by linking to __imp___ZN4Ogre7Vector36UNIT_YE (auto-import)
Info: resolving Ogre::StringUtil::BLANK by linking to __imp___ZN4Ogre10StringUtil5BLANKE (auto-import)
Info: resolving Ogre::ResourceGroupManager::AUTODETECT_RESOURCE_GROUP_NAME by linking to __imp___ZN4Ogre20ResourceGroupManager30AUTODETECT_RESOURCE_GROUP_NAMEE (auto-import)
Info: resolving Ogre::Vector3::UNIT_Z by linking to __imp___ZN4Ogre7Vector36UNIT_ZE (auto-import)
Creating library file: ..\..\lib\libSample_SkyDome.dll.a
Process terminated with status 2 (1 minutes, 7 seconds)
0 errors, 605 warnings
The dlls get created, and they work- but this seems to happen after make checks to find them. Basically I have to compile each individually :|

I haven't gotten a FreeImage version working yet, I will try that again soon.


Overall, nice work with this ;)

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by sinbad »

Yes, we don't have a MinGW maintainer right now, my personal view is that I can't understand why people would want to use it now that MSVC++ is free in Express form, which tends to produce smaller binaries and is a really nice tool, but that's just my opinion ;) MinGW gets little regular testing but if we can support it for the people that want to use it, great. Patches are welcome :)

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by sinbad »

ender wrote:How do we build ogre dynamically (not well versed w/ cmake).
The main Ogre & plugins is built dynamically by default. The small feature components (everything in the Components subfolder), however, are not, because it gets very messy to include all the dlls for every small component - particularly on OS X because of the way you have to configure the loading paths. Our MIT license makes dynamic linking unnecessary for legal reasons now so there's really no reason to amke every tiny piece dynamically linked, in fact the opposite is far better. As we go forward I expect that we'll be adding more components rather than less (an OgreMath component is a regular request).

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by CABAListic »

Ok, well, mixing static and dynamic linking apparently has some sort of problem on 64bit Linux platforms, so we need to sort this out one way or another. The correct way seems to add the -fPIC flag as suggested by the compiler, but I haven't had time to investigate the actual reasoning or purpose behind that flag, so...
I really need to get a 64bit Ubuntu system going; I have a brand new 1 TB hard drive waiting to be put in and filled :) Only I really don't have the time right now, so it will have to wait until mid of November, approximately.

In the meantime, anyone with a 64bit Linux system should try to add the -fPIC flag to CMake. As a first step, only to the Sample_Terrain plugin, if that is not enough, possibly OgreMain and all the plugins, too. Or perhaps the flag needs to be set for the components instead, I really have no idea :)

ender
Halfling
Posts: 99
Joined: Sat May 24, 2008 6:46 am

Re: CMake build system for Cthugha *looking for testers*

Post by ender »

wished I knew where to add the -fPIC flag. I add it to cmake_c_flags and nothing is changing for me.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by CABAListic »

Try CMAKE_CXX_FLAGS.

ender
Halfling
Posts: 99
Joined: Sat May 24, 2008 6:46 am

Re: CMake build system for Cthugha *looking for testers*

Post by ender »

Sorry, had my head up my tail on this one. Removing.
Last edited by ender on Sun Oct 25, 2009 4:50 am, edited 1 time in total.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by CABAListic »

Huh? Why is it referencing a libOgreTerrain in /usr/local during linking? Or are you already at the make install step?
If not, this looks as if there is a mix-up with the libraries to link against. You might want to restart with a fresh build directory.

User avatar
aguru
Goblin
Posts: 236
Joined: Tue Feb 26, 2008 5:48 pm
x 3

Re: CMake build system for Cthugha *looking for testers*

Post by aguru »

Is there a way to force the Components to be compiled as dynamic linked libraries?
All the libs in the builddir/lib directory are .so files, except for the components. It compiled without errors on my x64 linux before, so I think something was changed lately.

User avatar
aguru
Goblin
Posts: 236
Joined: Tue Feb 26, 2008 5:48 pm
x 3

Re: CMake build system for Cthugha *looking for testers*

Post by aguru »

Ok, so for now I just changed line 59 of the main CMakeLists.txt file from

Code: Select all

add_definitions(-msse)
to

Code: Select all

add_definitions(-msse -fPIC)
cleaned and recompiled and everything seems to work.

ender
Halfling
Posts: 99
Joined: Sat May 24, 2008 6:46 am

Re: CMake build system for Cthugha *looking for testers*

Post by ender »

Should there be a "make uninstall" target? I think my problem is that I need to clean up previous builds for which I did not clean up before I installed the latest 'svn update'.

How do I uninstall what's been installed in default /usr/local?

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by CABAListic »

CMake does not generate a 'make uninstall' target, they have some reason or other, I don't remember. Try and check the CMake site, in the FAQ or the wiki there is some information on this along with an alternative. Basically CMake generates a text file containing the names of all installed files, so you can do something like

Code: Select all

rm `cat InstalledFiles.txt`
(I just don't remember the actual filename, sorry.)

Enrico
Gnoblar
Posts: 20
Joined: Thu Jun 07, 2007 12:44 pm

Re: CMake build system for Cthugha *looking for testers*

Post by Enrico »

Hi,

I just made an svn update and now get when running cmake:
CMake Error at Samples/CMakeLists.txt:41 (include):
include could not find load file:

OgreConfigTargets


CMake Error at Samples/CMakeLists.txt:65 (find_package):
Could not find module FindOGRE.cmake or a configuration file for package
OGRE.

Adjust CMAKE_MODULE_PATH to find FindOGRE.cmake or set OGRE_DIR to the
directory containing a CMake configuration file for OGRE. The file will
have one of the following names:

OGREConfig.cmake
ogre-config.cmake



CMake Error at Samples/CMakeLists.txt:66 (find_package):
Could not find module FindOIS.cmake or a configuration file for package
OIS.

Adjust CMAKE_MODULE_PATH to find FindOIS.cmake or set OIS_DIR to the
directory containing a CMake configuration file for OIS. The file will
have one of the following names:

OISConfig.cmake
ois-config.cmake



CMake Error at /usr/share/cmake-2.6/Modules/CPack.cmake:686 (message):
CPack license resource file:
"/home/enrico/projekte/ogre-trunk/Samples/COPYING" could not be found.
Call Stack (most recent call first):
/usr/share/cmake-2.6/Modules/CPack.cmake:691 (cpack_check_file_exists)
CMake/Packaging.cmake:28 (include)
CMakeLists.txt:268 (include)
Any ideas? OIS is definitely installed...

System:
- Debian testing AMD64
- cmake 2.6-patch 4

ender
Halfling
Posts: 99
Joined: Sat May 24, 2008 6:46 am

Re: CMake build system for Cthugha *looking for testers*

Post by ender »

Is Samples/Media/packs/OgreCore.zip no more?

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by sinbad »

Yes, it is replaced with SdkTrays.zip for the new samples system.

User avatar
aguru
Goblin
Posts: 236
Joined: Tue Feb 26, 2008 5:48 pm
x 3

Re: CMake build system for Cthugha *looking for testers*

Post by aguru »

Just a thought - I noticed that on linux plugins are installed in /usr/lib/OGRE while components are in /usr/lib - maybe it would be better to put all of them into OGRE/? Or am I missing something?

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by CABAListic »

Well, components need to be linked against, and such link libraries generally reside in $PREFIX/lib on Unix systems, so putting them into OGRE would seem arbitrary to me. (Plugins, on the other hand, are specifically not meant to be linked against, so they are stored separately. I don't know if this is a common rule, but it seems sensible enough to me.)

User avatar
aguru
Goblin
Posts: 236
Joined: Tue Feb 26, 2008 5:48 pm
x 3

Re: CMake build system for Cthugha *looking for testers*

Post by aguru »

Ah, that sounds right. Thanks for the explanation.

User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Re: CMake build system for Cthugha *looking for testers*

Post by xavier »

Could someone on the dev team who understands cmake have it make the Terrain and RTShader libraries create .so on Linux? TIA...

[NM -- figured it out -- clearly someone got bit by the copy/paste bug with the CMakeLists.txt files in the Components tree...]
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by CABAListic »

Originally it created .so files, but I think sinbad decided to have components create static libraries as a general rule.

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by jacmoe »

It's definitely a nice change, at least on Windows.. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

dermont
Orc Shaman
Posts: 783
Joined: Thu Dec 09, 2004 2:51 am
x 35

Re: CMake build system for Cthugha *looking for testers*

Post by dermont »

CABAListic wrote:Originally it created .so files, but I think sinbad decided to have components create static libraries as a general rule.
Don't really understand why this was changed for Linux, is there not already a Static build setting for CMake? The Sample_*.so's built against static RtShaderSystem are 300MB (6MB with a dynamic build). Also the SampleBrowser crashes on exit but exits fine when the demos are built against the dynamic RtShaderSystem library.

Code: Select all

Plugin successfully uninstalled
Unloading library ../lib/OGRE/Samples/Sample_BezierPatch
Uninstalling plugin: BSP Sample
Plugin successfully uninstalled
Unloading library ../lib/OGRE/Samples/Sample_BSP
Uninstalling plugin: Camera Tracking Sample
Plugin successfully uninstalled
Unloading library ../lib/OGRE/Samples/Sample_CameraTrack
*** glibc detected *** ./SampleBrowser: double free or corruption (fasttop): 0x094b34a8 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xf89ff1]
/lib/tls/i686/cmov/libc.so.6[0xf8b6f2]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xf8e79d]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xa0c6f1]
/usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d)[0x9ea35d]
../lib/OGRE/Samples/Sample_CameraTrack.so[0x74e53d7]
/lib/tls/i686/cmov/libc.so.6(__cxa_finalize+0xb8)[0xf4e428]
../lib/OGRE/Samples/Sample_CameraTrack.so[0x748a734]
../lib/OGRE/Samples/Sample_CameraTrack.so[0x7503260]
/lib/ld-linux.so.2[0xa964de]
/lib/ld-linux.so.2[0xa96f47]
/lib/tls/i686/cmov/libdl.so.2[0x923ca4]
/lib/ld-linux.so.2[0xa914e6]
/lib/tls/i686/cmov/libdl.so.2[0x92409c]
/lib/tls/i686/cmov/libdl.so.2(dlclose+0x2a)[0x923cda]
/media/sda7/usr/local/lib/libOgreMain.so.1(_ZN4Ogre6DynLib6unloadEv+0x73)[0x394303]
/media/sda7/usr/local/lib/libOgreMain.so.1(_ZN4Ogre13DynLibManager6unloadEPNS_6DynLibE+0x107)[0x394ec7]
/media/sda7/usr/local/lib/libOgreMain.so.1(_ZN4Ogre4Root12unloadPluginERKSs+0xb5)[0x5416f5]
./SampleBrowser(_ZN9OgreBites13SampleBrowser13unloadSamplesEv+0x35)[0x805d635]
./SampleBrowser(main+0x1d2)[0x8058d72]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xf35b56]
./SampleBrowser[0x8057741]
======= Memory map: ========
00110000-00124000 r-xp 00000000 08:05 562        /lib/libz.so.1.2.3.3
00124000-00125000 r--p 00013000 08:05 562        /lib/libz.so.1.2.3.3
00125000-00126000 rw-p 00014000 08:05 562        /lib/libz.so.1.2.3.3
00126000-001a0000 r-xp 00000000 08:05 4376       /usr/lib/libfreetype.so.6.3.20
001a0000-001a4000 r--p 00079000 08:05 4376       /usr/lib/libfreetype.so.6.3.20
001a4000-001a5000 rw-p 0007d000 08:05 4376       /usr/lib/libfreetype.so.6.3.20
001a5000-001ac000 r-xp 00000000 08:05 4062       /usr/lib/libSM.so.6.0.0
001ac000-001ad000 r--p 00006000 08:05 4062       /usr/lib/libSM.so.6.0.0
001ad000-001ae000 rw-p 00007000 08:05 4062       /usr/lib/libSM.so.6.0.0
001ae000-001bc000 r-xp 00000000 08:05 4083       /usr/lib/libXext.so.6.4.0
001bc000-001bd000 r--p 0000d000 08:05 4083       /usr/lib/libXext.so.6.4.0
001bd000-001be000 rw-p 0000e000 08:05 4083       /usr/lib/libXext.so.6.4.0
001be000-001d3000 r-xp 00000000 08:05 133084     /lib/tls/i686/cmov/libpthread-2.10.1.so
001d3000-001d4000 r--p 00014000 08:05 133084     /lib/tls/i686/cmov/libpthread-2.10.1.so
001d4000-001d5000 rw-p 00015000 08:05 133084     /lib/tls/i686/cmov/libpthread-2.10.1.so
001d5000-001d7000 rw-p 00000000 00:00 0 
001d8000-001d9000 r-xp 00000000 00:00 0          [vdso]
001d9000-00730000 r-xp 00000000 08:07 272872     /media/sda7/usr/local/lib/libOgreMain.so.1.7.0
00730000-00743000 r--p 00556000 08:07 272872     /media/sda7/usr/local/lib/libOgreMain.so.1.7.0
00743000-0074a000 rw-p 00569000 08:07 272872     /media/sda7/usr/local/lib/libOgreMain.so.1.7.0
0074a000-00751000 rw-p 00000000 00:00 0 
00751000-0087b000 r-xp 00000000 08:05 4064       /usr/lib/libX11.so.6.2.0
0087b000-0087c000 ---p 0012a000 08:05 4064       /usr/lib/libX11.so.6.2.0
0087c000-0087d000 r--p 0012a000 08:05 4064       /usr/lib/libX11.so.6.2.0
0087d000-0087f000 rw-p 0012b000 08:05 4064       /usr/lib/libX11.so.6.2.0
0087f000-00880000 rw-p 00000000 00:00 0 
00880000-008cf000 r-xp 00000000 08:05 4109       /usr/lib/libXt.so.6.0.0
008cf000-008d0000 r--p 0004f000 08:05 4109       /usr/lib/libXt.so.6.0.0
008d0000-008d3000 rw-p 00050000 08:05 4109       /usr/lib/libXt.so.6.0.0
008d3000-008e5000 r-xp 00000000 08:07 270982     /media/sda7/usr/local/lib/libboost_thread.so.1.41.0
008e5000-008e6000 r--p 00011000 08:07 270982     /media/sda7/usr/local/lib/libboost_thread.so.1.41.0
008e6000-008e7000 rw-p 00012000 08:07 270982     /media/sda7/usr/local/lib/libboost_thread.so.1.41.0
008e7000-008f6000 r-xp 00000000 08:07 270976     /media/sda7/usr/local/lib/libboost_date_time.so.1.41.0
008f6000-008f7000 r--p 0000e000 08:07 270976     /media/sda7/usr/local/lib/libboost_date_time.so.1.41.0
008f7000-008f8000 rw-p 0000f000 08:07 270976     /media/sda7/usr/local/lib/libboost_date_time.so.1.41.0
008f8000-0091c000 r-xp 00000000 08:05 133066     /lib/tls/i686/cmov/libm-2.10.1.so
0091c000-0091d000 r--p 00023000 08:05 133066     /lib/tls/i686/cmov/libm-2.10.1.so
0091d000-0091e000 rw-p 00024000 08:05 133066     /lib/tls/i686/cmov/libm-2.10.1.so
0091e000-00921000 r-xp 00000000 08:05 555        /lib/libuuid.so.1.3.0
00921000-00922000 r--p 00002000 08:05 555        /lib/libuuid.so.1.3.0
00922000-00923000 rw-p 00003000 08:05 555        /lib/libuuid.so.1.3.0
00923000-00925000 r-xp 00000000 08:05 133064     /lib/tls/i686/cmov/libdl-2.10.1.so
00925000-00926000 r--p 00001000 08:05 133064     /lib/tls/i686/cmov/libdl-2.10.1.so
00926000-00927000 rw-p 00002000 08:05 133064     /lib/tls/i686/cmov/libdl-2.10.1.so
00927000-00929000 r-xp 00000000 08:05 4070       /usr/lib/libXau.so.6.0.0
00929000-0092a000 r--p 00001000 08:05 4070       /usr/lib/libXau.so.6.0.0
0092a000-0092b000 rw-p 00002000 08:05 4070       /usr/lib/libXau.so.6.0.0
0092b000-00932000 r-xp 00000000 08:05 133088     /lib/tls/i686/cmov/librt-2.10.1.so
00932000-00933000 r--p 00006000 08:05 133088     /lib/tls/i686/cmov/librt-2.10.1.so
00933000-00934000 rw-p 00007000 08:05 133088     /lib/tls/i686/cmov/librt-2.10.1.so
00934000-00952000 r-xp 00000000 08:06 49         /usr/local/lib/libOIS-1.2.0.so
00952000-00953000 r--p 0001d000 08:06 49         /usr/local/lib/libOIS-1.2.0.so
00953000-00954000 rw-p 0001e000 08:06 49         /usr/local/lib/libOIS-1.2.0.so
00954000-00a3a000 r-xp 00000000 08:05 5005       /usr/lib/libstdc++.so.6.0.13
00a3a000-00a3e000 r--p 000e6000 08:05 5005       /usr/lib/libstdc++.so.6.0.13
00a3e000-00a3f000 rw-p 000ea000 08:05 5005       /usr/lib/libstdc++.so.6.0.13
00a3f000-00a46000 rw-p 00000000 00:00 0 
00a46000-00a62000 r-xp 00000000 08:05 460        /lib/libgcc_s.so.1
00a62000-00a63000 r--p 0001b000 08:05 460        /lib/libgcc_s.so.1
00a63000-00a64000 rw-p 0001c000 08:05 460        /lib/libgcc_s.so.1
00a64000-00a80000 r-xp 00000000 08:05 5102       /usr/lib/libxcb.so.1.1.0
00a80000-00a81000 r--p 0001c000 08:05 5102       /usr/lib/libxcb.so.1.1.0
00a81000-00a82000 rw-p 0001d000 08:05 5102       /usr/lib/libxcb.so.1.1.0
00a82000-00a83000 r-xp 00000000 08:05 1082       /usr/lib/tls/libnvidia-tls.so.190.42Aborted


User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

Re: CMake build system for Cthugha *looking for testers*

Post by sinbad »

I changed it because the components differ greatly from the plugins - they are directly linked, not plugged in at runtime via an abstract interface. Particularly on OS X having a ton of separate dylibs is a PITA, but even on Windows I find it convenient for components to be different.

Yes, in the specific case of our samples it increases the size, which is a downside. But most end-user apps don't distribute ~30 different executables so it's not an issue - the size overheads are identical. Of course, prior to the RTShader system only certain components were used in certain demos.

300MB for Samples_*.so? Is this yet another example of gcc creating the most obese binaries known to man? ;) VC produces 16MB of Sample_*.dlls in release mode, 55MB in debug. But yeah, that's still not ideal - I hadn't notice it grow since RTShader was enabled on every demo.

I suspect the RTShader crash issue is there regardless, it's probably just not getting caught the same way with a dylib.

I guess we could add another OGRE_STATIC_COMPONENTS option, or maybe build 2 different targets, one dynamic and one static, using the dynamic one for the samples but offering the static ones for end-user apps - I don't think it's appropriate to use the same OGRE_STATIC option because it has a completely different kind of impact (plugins are no longer swappable etc). That's why I decoupled these in the first place, they're not actually the same thing.

dermont
Orc Shaman
Posts: 783
Joined: Thu Dec 09, 2004 2:51 am
x 35

Re: CMake build system for Cthugha *looking for testers*

Post by dermont »

The Samples_*.so 300MB is with a "RelWithDebInfo" build, the corresponding "Release" build is only 36MB. With regards to the "OGRE_STATIC_COMPONENTS" option, everyone else appears happy with the Linux build the way it is and I'm sure you have better things to do. It's pretty trivial for me to change to build dynamically if I need to.

Locked