Compile error from gmake: target pattern contains no `%'
 

Hi,
When installing 2.0.0 on HECToR (www.hector.ac.uk), which requires the gnu compilers, I find the following in the compiler's std out:

wmakeLnInclude: linking include files to OpenFOAM/lnInclude
+ wmakeLnInclude OSspecific/POSIX
wmakeLnInclude: linking include files to OSspecific/POSIX/lnInclude
+ Pstream/Allwmake
+ wmake libso dummy
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file UPstream.C
Making dependency list for source file UIPread.C
Making dependency list for source file UOPwrite.C
UPstream.dep:42: *** target pattern contains no `%'. Stop.
and line 42 of UPstream.dep reads
UPstream.dep: $(WM_PROJECT_DIR)/src/Open$(OBJECTS_DIR)/UPstream.o: $(EXE_DEP)

A 'google' suggests to me that gmake v3.81 no longer supports Window's PATHs and that any path+filename cannot have a ':' in the string; however, WM_PROJECT_DIR does not contain any offending characters, whilst OBJECTS_DIR and EXE_DEP appear to be blank.

I couldn't see this mentioned in the v2.0.1 release.

Apart from switching to gmake v3.80, any clues?
Cheers,
Gavin

Greetings Gavin,

Something very strange is going on there. gmake shouldn't be the one to blame. I've been using 3.81 for quite sometime in several Linux distros and right now I can't remember of any problems related to OpenFOAM. Although, using 3.82 shouldn't hurt either. 3.80 on the other hand, I vaguely remember of something about it going wrong...

Anyway, the following details come to mind:

• That error message that I quoted, there are two details that imply that something very wrong is going on:
  • "%" shouldn't appear at all.
  • "Open$(OBJECTS_DIR)" - this implies that something very wrong is going on! It should either read "Pstream/dummy" or "OpenFOAM"!
• Did you open the file that has the error, namely "src/Pstream/dummy/UPstream.dep"? It should indicate more details about it.
• You didn't specify if you are building OpenFOAM with a single core or if you are using multi-core building. In other words, is "WM_NCOMPPROCS" set to any value?
• Are you using Gcc or Icc? And which version are you using?
• Which architecture are you building? I ask this because I'm not very familiar with HECToR's infrastructure. Is it x86, x86_64, PowerPC, Itanium... ?
• Are you positive that you are using gmake and not simply make? In other words, is make symbolically linked to gmake... or maybe a copy of it?
• Did you check the md5sum of the 2 downloaded packages?

Best regards,
Bruno

Hi,

The issue is now resolved: the problem was that I was making OF on the front-end of an HPC system to be run on the back-end of the same system and, as such, had set the target arch to be the back-end.

Now, tthe two ends do not share the same arch and, as such, the 3 wmake tools where made with the back-end as the target archetecture; however, they must be run on the front-end as they are part of the compilation procedure.

The solution is to either make them separately or 'hack' the file wmake/src/Makefile by specifying the compilers to be employed.

For our case, after the lines
include $(RULES)/generalinclude $(RULES)/$(WM_LINK_LANGUAGE)
we added the following two new lines
cc = gccCC = g++This forces the associated wmake binaries, required during installation, to be compatible with the front end nodes, whilst keep all other binaries compatible with the target architecture (either the front- or back-end).

Hi Bruno,

Many thanks for your rapid response.

Cheers,
Gavin