Shared libraries problem (linux).

Ok, so I’m trying to use one of Zanqdos Linux builds from - the two most recent ones from Sept 14. But I can’t get the links to the shared libraries to work it seems. I type in the ln -s as instructed, but it doesn’t work.

Following Squarelines instructions:

if missing the or , you should link to, or other missing libs

cd /usr/lib
sudo ln -s
sudo ln -s
sudo ln -s
sudo ln -s

So, doing that (no sudo as I don’t have that installed):

[[email protected] lib]# ln -s
ln: creating symbolic link `./': File exists

But on trying to run blender again after making, the link, I still get the same message that it can’t find it…

[[email protected] linux2]$ ./blender
./blender: error while loading shared libraries: cannot open shared object file: No such file or directory

So I am officially confused.

i didnt follow squares instructions, i just opened synaptic in ubuntu and searched for those files(basically the thing is that you have older files, you need to get the newer ones, or well thats what i had to do) :stuck_out_tongue:

Well I have no idea where to get them.

Symlinking libraries is always a bad idea. And the three AV* files belong to FFMPEG which has gone through quite a few changes lately. Since Blender is a self contained program, maybe you should build your own to be optimized for your system.

yep maybe I need to try that. Maybe it’s because the build is 32bit and my system is 64bit?

If you run Blender from the command line, do you get 'Wrong ELF class" errors? If so, then yes.

No I don’t get that kind of error. I would like to figure out why I can’t use these premade builds on linux when other people can though. I mean, am I missing those files, or what? I can’t find them in the fedora repos it seems…

64bit libraries won’t help you anything when trying to run a 32bit application, AFAIR they are simply ignored by the dynamic linker in most cases.

In the meantime, you could’ve compiled blender yourself a dozen times… :wink:

yes, compiling with make on linux is actually quite easy and fast, as ive found out myself :slight_smile:
i wouldn’t know about optimizing though…

Yeh, the optimizations were the main reason I wanted to try the build - one was optimized with sse3 in mind. So does that mean the builds on graphicall are 32bit only? I notice that it says they are i386.

If you have GCC 4.2 or above on your system, I would only use these flags:

-march=native -mtune=native -O2 -pipe -msse3

I’ve found no other optimizations that work better, and this is stable. -mtune and -march will optimize to your processor automatically. -O2 (letter O) is considered very tested and stable. -msse3 will optimize for SSE3. That flag may not be necessary on Intel machines, but for AMD it is (if your processor supports it). You can check by:

cat /proc/cpuinfo

hmm, I’m also a little uncertain as to where to enter these flags. and are mentioned on Are the flags entered in one of these files?

Also, I have GCC version 4.1.2-12. Is it worth it to install a higher version? This is the best available in the Fedora repos.

edit: just trying to make a normal build of blender. Tried scons and gcc, but get the same string of errors in each when it gets to OpenAL:

Compiling ==> ‘SND_DummyDevice.cpp’
Compiling ==> ‘SND_Scene.cpp’
Compiling ==> ‘SND_WaveCache.cpp’
Compiling ==> ‘SND_DeviceManager.cpp’
Compiling ==> ‘SND_CDObject.cpp’
Compiling ==> ‘SND_C-api.cpp’
Compiling ==> ‘SND_SoundListener.cpp’
Compiling ==> ‘SND_IdObject.cpp’
Compiling ==> ‘SND_SoundObject.cpp’
Compiling ==> ‘SND_Utils.cpp’
Compiling ==> ‘SND_AudioDevice.cpp’
Compiling ==> ‘SND_WaveSlot.cpp’
Compiling ==> ‘pthread_cancel.cpp’
Compiling ==> ‘SND_OpenALDevice.cpp’
intern/SoundSystem/openal/SND_OpenALDevice.cpp:51:19: error: AL/al.h: No such file or directory
intern/SoundSystem/openal/SND_OpenALDevice.cpp:52:20: error: AL/alc.h: No such file or directory
intern/SoundSystem/openal/SND_OpenALDevice.cpp:53:21: error: AL/alut.h: No such file or directory
intern/SoundSystem/openal/SND_OpenALDevice.cpp:72: error: ‘ALvoid’ does not name a type

That continues with a bunch of similar error messages and stops the compile. No info via googling. anyway, if anyone has any ideas, otherwise I guess that’s it for my compilation attempt.

Install the openal development packages. In debian they are called for example libopenal-dev. Maybe something like this
or for x86_64

intern/SoundSystem/openal/SND_OpenALDevice.cpp:51:19: error: AL/al.h: No such file or directory
There may other .h files be missing which results in a similar error. You have to install the missing source/development packages.

Ok I installed the openal-dev libraries, but still get errors on compiling, same files, but now a different type of error.

Compiling ==> 'SND_OpenALDevice.cpp'
intern/SoundSystem/openal/SND_OpenALDevice.cpp:53:21: error: AL/alut.h: No such file or directory
intern/SoundSystem/openal/SND_OpenALDevice.cpp: In member function ‘virtual SND_WaveSlot* SND_OpenALDevice::LoadSample(const STR_String&, void*, int)’:
intern/SoundSystem/openal/SND_OpenALDevice.cpp:439: error: ‘alutLoadWAVMemory’ was not declared in this scope
intern/SoundSystem/openal/SND_OpenALDevice.cpp:454: error: ‘alutLoadWAVFile’ was not declared in this scope
intern/SoundSystem/openal/SND_OpenALDevice.cpp:482: error: ‘alutUnloadWAV’ was not declared in this scope
scons: *** [/storage/blenderfiles/svncheckout/build/linux2/intern/SoundSystem/openal/SND_OpenALDevice.o] Error 1
scons: building terminated because of errors.

You can turn off the OpenAL stuff. This needs to be done in the same terminal session that you’re building from:

export NAN_NO_OPENAL=true

I do recommend upgrading GCC to 4.2. It makes optimizing for your processor much easier. It’s not real hard to do anyway, but it’s easier. If you don’t want to upgrade, see this page for compiler options. Replace the mtune and march flags below appropriately:

As for as passing flags to the compiler goes (assuming GCC 4.2), do this from the same terminal session that you’re building with:

export CFLAGS="$CFLAGS -march=native -mtune=native -O2 -pipe -msse3"

If anyone cares, the rendering on my box with my own home built 64 bit Blender are exactly the same as the pre-built binary from

The development files for alut/libalut are missing. You can search the internet howto install them.
The next time when there is an “error: foo/bar.h” is missing install the development packages.

Thanks, both those comments help a bunch. Will be well on my way to fixing some of these compile errors myself.

Dan, for you and everyone else, I highly recommend learning to build actual packages for whatever distro you’re on. It makes sharing and removing stuff much more clean. But, if you’re using GCC 4.2 and you want to share, you should use ‘generic’ instead of ‘native’ as compiler flags. It will produce code that is usable on other machines that have different processors than yours.

I was trying to compile blender last night - had someone in the blender irc room helping me out, but we still hit a brick wall in the compile - couldn’t find python.h.

He told me that it’s because of Fedora, and that a lot of other users have been having problems compiling Blender on Fedora.

Install the development package for the python version you want to use, i.e. python2.5 or python2.4.
Goto: search for python.h. Which Fedora version do you use?