Page 1 of 1

Linux library installation

Posted: Wed Sep 05, 2007 3:14 pm
by shiftless
Hi, on Linux when one compiles the source and does a 'make install', I see that libOgreMain.so is made a symlink to libOgreMain-1.4.4.so, which is correct.

However, there should also be a libOgreMain-1.4.so symlink to libOgreMain-1.4.4.so. (Same thing for the other libraries.) This way, I can link to -1.4 if my game is built for 1.4.x. Later when someone installs 1.4.37, my application will automatically use it and hopefully gain performance, and not break cause all 1.4.x series should be interface-compatible. But if someone installs 1.5.x, it will sit alongside the existing 1.4.x version, and my application won't even notice it.

This is a bit confusing to explain so here is a picture showing how it should be laid out:

Code: Select all

-rwxr-xr-x 1 root root  1164660 2007-09-04 15:42 libCEGUIOgreRenderer-1.4.4.so
lrwxrwxrwx 1 root root       29 2007-09-05 18:53 libCEGUIOgreRenderer-1.4.so -> libCEGUIOgreRenderer-1.4.4.so
-rwxr-xr-x 1 root root   978076 2007-09-05 18:32 libCEGUIOgreRenderer-1.5.0.so
lrwxrwxrwx 1 root root       29 2007-09-05 18:53 libCEGUIOgreRenderer-1.5.so -> libCEGUIOgreRenderer-1.5.0.so
-rwxr-xr-x 1 root root      905 2007-09-05 18:32 libCEGUIOgreRenderer.la
lrwxrwxrwx 1 root root       29 2007-09-05 18:32 libCEGUIOgreRenderer.so -> libCEGUIOgreRenderer-1.5.0.so
-rwxr-xr-x 1 root root 41187576 2007-09-04 15:42 libOgreMain-1.4.4.so
lrwxrwxrwx 1 root root       20 2007-09-05 18:46 libOgreMain-1.4.so -> libOgreMain-1.4.4.so
-rwxr-xr-x 1 root root 38672130 2007-09-05 18:32 libOgreMain-1.5.0.so
lrwxrwxrwx 1 root root       20 2007-09-05 18:47 libOgreMain-1.5.so -> libOgreMain-1.5.0.so
-rwxr-xr-x 1 root root     1612 2007-09-05 18:32 libOgreMain.la
lrwxrwxrwx 1 root root       20 2007-09-05 18:32 libOgreMain.so -> libOgreMain-1.5.0.so
drwxr-xr-x 2 root root     4096 2007-09-05 18:32 OGRE

Posted: Wed Sep 05, 2007 7:31 pm
by Game_Ender
I don't think 1.SomeNumber.x releases are link compatible.

Posted: Fri Sep 07, 2007 9:52 am
by shiftless
Are you sure about that? If the class interfaces don't change, the only problem I could see would be with the C++ name mangling. But that doesn't seem to be a problem, as I've changed and recompiled the various libraries a ton of times over the past few days and the application still runs fine.

I don't think it works ...

Posted: Fri Sep 07, 2007 10:11 am
by Shadow007
The 1.X releases are "source compatible" in that no "previous" feature/function/Macro etc is missing. The community ensures that a source compiled with 1.x.0 will still compile (and get the same results) in 1.x.25

BUT it does not mean they are "binary compatible" : optional arguments may have been added to a function, new functions may have been added to a class, and methods may for example become virtual etc...

As the later versions are mostly bug fixes, these "binary incompatible" changes are not frequen,t, but they exist. That's why your solution may/may not work, depending on the versions ... and won't (I think) be applied.

Posted: Fri Sep 07, 2007 12:59 pm
by sinbad
Yes, this is correct. We previously tried to maintain binary compatibility but there are such subtle things (e.g. const correction) that can change it that it became far too much hassle. Source compatibility is all we aim for. Keeping binary compatibility is unfortunately harder with C++ than C because of the amount of symbol mangling.

Other platforms (Win32, OSX) deploy the Ogre libs locally with apps anyway so there's no need for strict binary compatibility.

Posted: Fri Sep 07, 2007 1:30 pm
by shiftless
Alright, thanks guys.