views:

114

answers:

4

I'm compiling a branch of the Blender 3D modeling program from source (using SCONS), on a Fedora 8 box, and am running into an error that I didn't encounter compiling the same source on a CentOS 5 box, and I'm thinking it has to do with the variable definition. The error is:

source/blender/blenkernel/intern/implicit.c: In function ‘mul_bfmatrix_lfvector’:
source/blender/blenkernel/intern/implicit.c:592: error: ‘CLOTH_OPENMP_LIMIT’ undeclared (first use in this function)
source/blender/blenkernel/intern/implicit.c:592: error: (Each undeclared identifier is reported only once
source/blender/blenkernel/intern/implicit.c:592: error: for each function it appears in.)
source/blender/blenkernel/intern/implicit.c: In function ‘cloth_calc_force’:
source/blender/blenkernel/intern/implicit.c:1700: error: ‘CLOTH_OPENMP_LIMIT’ undeclared (first use in this function)

The file implicit.c does define that variable; here's the first few lines of the file:

#include "MEM_guardedalloc.h"

#include "BKE_cloth.h"

#include "DNA_object_force.h"

#include "BKE_effect.h"
#include "BKE_global.h"
#include "BKE_utildefines.h"

#include "BLI_threads.h"

#define CLOTH_OPENMP_LIMIT 25

#ifdef _WIN32
#include <windows.h>
static LARGE_INTEGER _itstart, _itend;
static LARGE_INTEGER ifreq;

the two lines that are throwing an error are:

#pragma omp parallel sections private(i) if(vcount > CLOTH_OPENMP_LIMIT)

and

#pragma omp parallel for private(i) if(numverts > CLOTH_OPENMP_LIMIT)

I'm guessing the error is due to the compiler and how it handles when in the compilation that variable gets defined, and since Fedora 8 is a bit outdated, it might have an older version of some compiler that's messing it up. Anyone have an idea how I can get around this variable showing up as "undeclared"?

A: 

Hard to say, but either :

  1. Change the define CLOTH_OPENMP_LIMIT to it's numeric value and recompile
  2. Check your include statements to ensure that CLOTH_OPENMP_LIMIT is actually being defined correctly.

If that still does not work, then the OpenMP API on your compiler is out-of-date, not installed, or not working.

0A0D
I believe it's already set to a numeric value (25), and it's part of the same file, so it's not needing any additional include statements, I think...
MidnightLightning
A: 

It looks like for some reason CLOTH_OPENMP_LIMIT is not in fact being defined. You can test this right before the lines that generate the error:

#ifndef CLOTH_OPENMP_LIMIT
#error "Ooops, CLOTH_OPENMP_LIMIT not defined!"
#endif

Common reasons would be that it depends on OTHER preprocessor defines being defined, or a header isn't included when expected.

Mark B
I added this set of three lines to the source file, and saw no change in the error output (other than the line numbers shifted 3 higher)
MidnightLightning
A: 

I guess that OpenMP in gcc was still quite experimental in the old days when 4.1 came out. What happens if you replace the macro name in the OpenMP pragma by the numerical constant? I am not quite sure what the standards say about macro replacements inside pragmas, maybe this older version of gcc has a different strategy for that than newer ones.

Jens Gustedt
+1  A: 

That compiler doesn't support OpenMP. This is the first mention of OpenMP and GCC

March 9, 2006

... so starting with GCC 4.2 the compiler supports the OpenMP v2.5 specification.

The tip off here is that quite clearly the value is defined, yet the #pragma ... line can't find the definition, according to the pre-processor error. Once you realize that the code is using a non-standard #pragma compiler directive, the compiler becomes the prime suspect.

jdu.sg
Huh, I'll give that a try, though I find it odd that a CentOS box with the same gcc version (4.1.2) didn't have this problem, but the Fendora box is (and both are VirtualBox virtual machines with the same "hardware")
MidnightLightning
Let me know what happens. OpenMP states that you have to use a supporting / supported compiler, so that needs to be verified first.I think the basic issue is that #pragma is (in this case) compiler-dependent, so if the #pragma is not supported, you could be witnessing a preprocessor/compiler disagreement.
jdu.sg
I compiled gcc 4.2.4 from source on this Fedora box, and compiled Blender with that, and it compiled with the OpenMP statements intact, but then the final binary wouldn't launch, complaining that GLIBC wasn't high enough version. So, I've either got to compile without OpenMP support (there is a flag for that at compile time in Blender), or upgrade GLIBC too...
MidnightLightning