CFD Online URL
[Sponsors]
Home > Forums > OpenFOAM Installation

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

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   December 12, 2011, 11:03
Default Compile error from gmake: target pattern contains no `%'
  #1
New Member
 
Gavin J. Pringle
Join Date: Apr 2009
Location: Edinburgh, UK
Posts: 4
Rep Power: 7
Gavin is on a distinguished road
Send a message via Skype™ to Gavin
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
Gavin is offline   Reply With Quote

Old   December 12, 2011, 16:47
Default
  #2
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 7,511
Blog Entries: 33
Rep Power: 74
wyldckat is a jewel in the roughwyldckat is a jewel in the roughwyldckat is a jewel in the roughwyldckat is a jewel in the rough
Greetings Gavin,

Quote:
Originally Posted by Gavin View Post
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)
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
wyldckat is offline   Reply With Quote

Old   January 18, 2012, 12:34
Default
  #3
New Member
 
Gavin J. Pringle
Join Date: Apr 2009
Location: Edinburgh, UK
Posts: 4
Rep Power: 7
Gavin is on a distinguished road
Send a message via Skype™ to Gavin
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).
Gavin is offline   Reply With Quote

Old   January 18, 2012, 12:35
Default
  #4
New Member
 
Gavin J. Pringle
Join Date: Apr 2009
Location: Edinburgh, UK
Posts: 4
Rep Power: 7
Gavin is on a distinguished road
Send a message via Skype™ to Gavin
Hi Bruno,

Many thanks for your rapid response.

Cheers,
Gavin
Gavin is offline   Reply With Quote

Reply

Tags
gmake 3.81

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Building OpenFOAM1.7.0 from source ata OpenFOAM Installation 42 May 14, 2012 21:48
Running mapFields with Parallel Source and Parallel Target RDanks OpenFOAM Mesh Utilities 2 June 6, 2011 08:56
Can someone PLEASE document the development version installation bernd OpenFOAM Installation 76 November 14, 2008 22:51
OpenFOAM14 for Mac OSX Darwin 104 gschaider OpenFOAM Installation 118 July 20, 2008 06:19


All times are GMT -4. The time now is 23:52.