Blender compile issues

[Mind_eyes]

I hope others find this helpfull,

I was haveing an awfull time compiling blender on my new linux os, (built myself), I coudn't use the precompiled binary for some reason "glibc ver dif?" so I had to compile myself, but I kept running into dependancy issues with static open gl libs, libGL.a libGLU.a? something like that anyway. O I was using the make form not Scons. So I was looking though the docs and the nan_definitions.mk file and found this at the bottum

# Don't want to build the gameengine?
ifeq ($(NAN_NO_KETSJI), true)
export NAN_JUST_BLENDERDYNAMIC=true
export NAN_NO_OPENAL=true
endif

so since I didn't want the game engine anyway I put "NAN_NO_KETSJI" at the begining of the source/nan_definitions.mk file and presto no longer needed the static gl libs all I had to do.

recap, to compile blender under linux, dl blender source, unpack, cd to blender/source/, change blender/source/nan_definitions.mk, make. and if all goes well you will have your blender binary in the blender source tree someware, I forget where it was I had to "find /home/sambo/blender -name blender" to find the binary.

I don't mean to crit such an awsome program but the compile docs and prosses are a little rocky

Just out of intrest, any hardcore linux programer/compiler out there? Why coudn't a person just build there program with all the dependancys (exept hardware api's eg, opengl/d3d) like the glibc deps and static mesa gl libs staticaly linked to a lib thats included with the binary? I don't know a whole lot about this I just dable in c++ programing.

[artless]

I am trying ( and tired from) building blender on a x86_64 PC ( with linux mandriva2006), either with make or SCOns.
I have installed a lot of x86_64 lib ( I guess it goes to /usr/lib64 ).
I am very surprise by the big among of time of compiling (8-10mn) before it stops on error :

Code: Select all

source/blender/imbuf/intern/openexr/openexr_api.cpp:66:26: error: OpenEXR/half.h: Aucun fichier ou répertoire de ce type

it means : ( traduction from french) => no file or directoy of this type
=>follows a few hundreds of errors lines

I have already modified the linux2-config.py in order to de-activate openal which have made a something-like problem.

Openexr is the source of the actual problem ( what is this for , can i de-activate it?)
so I tried to fix the problem with : (in linux2-config.py)

WITH_BF_OPENEXR = 'true'
BF_OPENEXR = '/usr/lib64'
BF_OPENEXR_INC = '${BF_OPENEXR}'
BF_OPENEXR_LIB = 'Half IlmImf Iex Imath '

with no effect at all !What can I do to fix this problem with openexr ?

Another much more important question :
I want to make a direct link between blender's sources and the (x86_64) libraries already installed. Is it possible to do such a thing ?
With great thanks for all kind of opinions.

[stiv]

BF_OPENEXR_INC = '${BF_OPENEXR}'

This should point to something like /usr/include or wherever the OpenEXR includes live on your system. You have it pointing to /usr/lib64 which is wrong.
The 'no such file' message always means either something is not installed or the path is wrong.

If you don't want OpenEXR, simply set
WITH_BF_OPENEXR = 'false'

[artless]

OK, OpenExr is an image format from ILM. (http://www.openexr.com/)
It's simple to de-activate OpenEXR: USE_OPENEXR = 'false'

Dispite of some posts saying that this file is no longer used ( is-it true ? ) we can do something for this.
From : http://www.openexr.com/ + download:OpenEXR-1.2.2.tar.gz
an : defrag => open a console on the OpenEXR-1.2.2 directory

Code: Select all

# cd /home/cesar/Desktop/OPENEXR/OpenEXR-1.2.2
# ./configure
# make
# make install

unfortunately : an errors in the make step stops this effort...
first of plenty of errors :

Code: Select all

./Image.h:59: error: expected `)' before '&' token

return to my first empty-head solution : USE_OPENEXR = 'false'
Too Bad

[artless]

"errare humanum est sed persaverare diabolicum"
mistakes are human, but to continue making mistakes is the sign of devil

OK OK, with the package manager from Mandriva it's possible to download the X86_64 package of OPENEXR.

And what ? As stiv say OPENEXR is landing in /usr/lib64/OPENEXR ! nan_definitions.mk become :

Code: Select all

export NAN_OPENEXR ?= /usr/lib64
export NAN_OPENEXR_INC ?= /usr/include/OpenEXR
export NAN_OPENEXR_LIBS ?= $(NAN_OPENEXR)/libIlmImf.a $(NAN_OPENEXR)/libHalf.a $(NAN_OPENEXR)/libIex.a

Wich makes errors (With make )

Code: Select all

Compiling ==> 'openexr_api.cpp'
In file included from source/blender/imbuf/intern/openexr/openexr_api.cpp:68:
/usr/include/OpenEXR/ImathBox.h:65:22: error: ImathVec.h: no file or directory of this type

I find this a bit strange because because each 3 files exists

• blender/source/blender/imbuf/intern/openexr/openexr_api.cpp
  /usr/include/OpenEXR/ImathBox.h
  /usr/include/OpenEXR/ImathVec.h

But on ligne 65 from ImathBox.h I have a commented line !

Code: Select all

#include <ImathVec.h>

is "65" the line number without comments ?
By the way I was not able to "make" in( /intern or /extern or /source) I just use the make in the blender directory...
The reason is that inclusion ( include ) are not aware of the relative position of files.
Are those Makefile useful ?
With scons : modifying: blender/config/linux2-config.py

Code: Select all

WITH_BF_OPENEXR = 'true'
BF_OPENEXR = '/usr/lib64'
BF_OPENEXR_INC = '/usr/include/OpenEXR'
BF_OPENEXR_LIB = 'Half IlmImf Iex Imath '

phew ! no more Openexr errors..
But ...

Code: Select all

Compiling ==> 'buildinfo.c'
Linking program ==> 'blender'
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: cannot find -lGL
collect2: ld returned 1 exit status
scons: *** [/home/mikael/cvs-blender/build/linux2/bin/blender] Error 1
scons: building terminated because of errors.

Abstract : errors on make
errors on scons
What a bad luck ! ...Keep trying....

[stiv]

But on ligne 65 from ImathBox.h I have a commented line !

Code: Select all

#include <ImathVec.h>

Heh. Not a comment. The #include <> is a command to insert a file into the source code.

I can see this is going to be a long process for you. As for me, I need more coffee to look at this stuff.

[artless]

#include => option of pre-compilation or something like that to import source...( I have forgotten that...)
I have forgotten to say that the "missing file" : ImathVec.h exists at the same level that ImathBox.h (wich call it by include). The only difference between this two files is that one is called by another....

So, is the following true ?
The source (ImathBx.h) is copying in the cpp file, thanks to the NAN_OPENEXR_INC parameter with no problems

Code: Select all

export NAN_OPENEXR_INC ?= /usr/include/OpenEXR

and then the source ImathBox.h is called but not found ?!
Why ? is the parameter NAN_OPENEXR_LIBS to be modified ?

Code: Select all

export NAN_OPENEXR_LIBS ?= $(NAN_OPENEXR)/libIlmImf.a $(NAN_OPENEXR)/libHalf.a $(NAN_OPENEXR)/libIex.a

So it's maybe some of the nan_definitions.mk parameters to be change:

Code: Select all

export NAN_OPENEXR_LIBS ?= 'Half IlmImf Iex Imath '

in order to fit a scons-like way ( in blender/config/linux2-config.py )

I am puzzled by this behaviour because I don't know exactly what those parameters are used for.

[artless]

again and again the same errors occur near the end ( as far as I can hope)

• Compiling ==> 'buildinfo.c'
  Linking program ==> 'blender'
  /usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
  /usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
  /usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
  /usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
  /usr/bin/ld: cannot find -lGL
  collect2: ld returned 1 exit status
  scons: *** [/home/artless/cvs-blender/build/linux2/bin/blender] Error 1
  scons: building terminated because of errors.

What does it means ? Have you any piece of advice ?

[stiv]

/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz

This looks like a 32 bit vs 64 bit problem. All libraries used must be one type or the other. No mixing.

[SirDude]

The -lz messages may not actually be the issue. But basically
its saying that those libraries do not match your code. (32bit and your compling
for 64bit or the other way around, could also be different versions of gcc were used to compile them)

The biggest error though is this one:
/usr/bin/ld: cannot find -lGL

You probably need to modify your build system so it knows where to locate
the GL lib....

[epat]

I use mandriva 2006 too - not the 64bit one though, but from my experience it shouldn't be neccesary to modify linux2-config.py to tell scons which is what I use where all the librarys it needs are. But first looking at your output, it sounds like you haven't got the gl-devel librarys installed on your system - you might need to use the mesaGL-devel librarys if you haven't got openGL hardware acceleration(I'm not sure); either that, or like stiv says, you'll have to modify the build system so it knows where to locate them. Anyway, back to scons - if you have a problem with some library or other not being located properly, there's actually no need to modify linux2-config.py - though it could be useful if you want to compile again - but you can pass options to scons itself when you execute it - type "scons --help" to see all the available options for the program you're building. -epat

[stiv]

Don't modify config/linux2-config.py. Follow the instructions in the doc/blender-scons.txt file and copy it up one directory to user-config.py. Make your changes to that file.

[artless]

Yes it must be a conflct 32 versus 64 bit libs. It's not obvious to find the parameters involved in this behaviour. During a week I have tried to modify the different scons config file, ( or the make files...). I will try to modify only the user-config.py thanks to stiv, (Garfield or Detroit ?) add the mesaGL-devel librarys and use the command "scons --help".

I was wondering if there is a python script available, to see and modify the differents values, constants, path or parameters build by the different scons parametric files ( Sconstruct Sconscript).
It could be a good way to save time if there were such a way of editing/modifying those parameters before the pre-compile/compile/link process starts.

[stiv]

I was wondering if there is a python script available, to see and modify the differents values, constants, path or parameters build by the different scons parametric files

Not sure I understand this. All the paths and flags for things other than normal system components are in the user-config.py file.

[winfried]

I'm also having this kind of issues when trying to compile on Suse 10.1 64bit.

I have modified or added the BF_xxx_LIBPATH variables in linux2-config.py (I just now read that I am supposed to copy this to a userconfig...).

When I run scons --help I can see that scons uses these vars indeed, for example for libjpeg:

BF_JPEG: JPEG base path
default:
actual: /usr

BF_JPEG_INC: JPEG include path
default:
actual: /usr/include

BF_JPEG_LIB: JPEG library
default:
actual: jpeg

BF_JPEG_LIBPATH: JPEG library path
default:
actual: /usr/lib64

However during linking I still get the following errors:/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching for -ljpeg

For some other libraries I was able to get rid of similar errors by uninstalling the 32bit libraries in /usr/lib. However package libjpeg-devel-32bit is needed by a bunch of other programs, so I can't uninstall that one.

Same problem for libpng libfreetype libGL and more.

Anyone know how to get around this?