[demichie]

Originally Posted by podallaire

Hi there,

update: Using the following worked for me
LINKLIBSO = $(cc) -dynamiclib -flat_namespace -undefined suppress
LINKEXE = $(cc) -Xlinker -z -Xlinker nodefs

Where have you used these?

Thank you
Mattia

[podallaire]

Hi !

I modified wmake/rules/darwin64Clang/c and "recycled" the settings suggested by Bernhard on a previous patch.

Cheers

PO

[alexeym]

Hi,

Rules from wmake/rules/darwin64Clang/c are used during compilation of C code, for C++ rules from wmake/rules/darwin64Clang/c++ are used. This part of change

-Xlinker -z -Xlinker nodefs

does not have meaning as ld on OS X does not have -z flag.

So basically it is unknown what helped you with compilation.

[alexeym]

Hi,

I have made alternative patch for 3.0.1 - https://raw.githubusercontent.com/mr...AM-3.0.1.patch. wmake rules in this patch do not rely on dynamic_lookup functionality and are more similar to the rules used in earlier versions of patches.

I have tested the patch on my laptops, though it seems this does not guarantee anything

[alexeym]

@demichie and @o.kotsur:

Just to clarify (and for the future reference), finally by accident I was able to reproduce your error, and a reason for the error is in this part of $FOAM_SRC/OpenFOAM/Make/files:

#if defined(__APPLE__) && defined(__clang__)
$(ints)/long/long.C
$(ints)/long/longIO.C
$(ints)/ulong/ulong.C
$(ints)/ulong/ulongIO.C
#endif

So if __APPLE__ or __clang__ symbols are not defined during cpp run, source files are not added to compilation and as a result __ZN4FoamlsERNS_7OstreamEl symbol is undefined. I do not know why your cpp does not define either __APPLE__ or __clang__, mine does:

$ cpp -dM /dev/null | grep -E '(__APPLE__|__clang__)'
#define __APPLE__ 1
#define __clang__ 1

[demichie]

Thank you for your efforts! This is the output on my computer:

cpp -dM /dev/null | grep -E '(__APPLE__|__clang__)'

#define __APPLE__ 1

As you see __APPLE__ seems to be defined, but not __clang__.
I will try to investigate.

Thank you
Mattia

[alexeym]

Hi,

Surely you can investigate (and maybe find that you have installed cpp from somewhere else), one way to solve the problem is to remove __clang__ condition (since your cpp is from somewhere else), i.e. change above fragment to:

#if defined(__APPLE__)
$(ints)/long/long.C
$(ints)/long/longIO.C
$(ints)/ulong/ulong.C
$(ints)/ulong/ulongIO.C
#endif

or it would be more OpenFOAM like (to force instead of check):

#if defined(darwin64)
$(ints)/long/long.C
$(ints)/long/longIO.C
$(ints)/ulong/ulong.C
$(ints)/ulong/ulongIO.C
#endif

in the first case you just check if you are on Darwin (yet omit clang check, maybe cpp was just copied into /usr/bin from elsewhere). In the latter case you agree with definition passed through -D compiler flag (since any way you are using wmake and it uses flags from rules/darwin64Clang/c++, and they include -Ddarwin64 flag).

[demichie]

It worked! Now I finally have 3.0.1 compiled on my Macbook Pro.

Thank you!!!

[jjstickel]

I've modified the mrklein 3.0.1 patch for MacPorts installed libraries, but using apple clang for compilation. I am hopeful it should work, but I get this immediate error when trying to build:

$ ./Allwmake 2>&1 | tee build.log
dyld: Symbol not found: _CGLGetCurrentContext
  Referenced from: /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
  Expected in: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
 in /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
xcrun: error: unable to lookup item 'Path' in SDK '/'
xcrun cc -arch x86_64  -Wall -O3   -fPIC -isysroot  -Wno-unneeded-internal-declaration -Wno-unused-function dirToString.c -o /Users/jstickel/OpenFOAM/OpenFOAM-3.0.1/wmake/platforms/darwin64Clang/dirToString
clang: warning: no such sysroot directory: '-Wno-unneeded-internal-declaration'
dirToString.c:43:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
         ^
1 error generated.
make: *** [/Users/jstickel/OpenFOAM/OpenFOAM-3.0.1/wmake/platforms/darwin64Clang/dirToString] Error 1

A bit of google indicates this may be related to xcode upgrade (now xcode 7.2 on OS X 10.10.5). Anyone else seen this problem? Do I need to setup xcode/clang somehow?

[alexeym]

Hi,

xcrun cc -arch x86_64  -Wall -O3   -fPIC -isysroot ?

Your -isysroot (or OSX_SDK_PATH, which is equal to output of xcrun --show-sdk-path) is empty. Why it is empty? You could start by posting output of the following commands:

$ xcrun --show-sdk-path
$ xcrun cc --version
$ make --version

Though SDK could just be missing.

[jjstickel]

Originally Posted by alexeym

Hi,

xcrun cc -arch x86_64  -Wall -O3   -fPIC -isysroot ?

Your -isysroot (or OSX_SDK_PATH, which is equal to output of xcrun --show-sdk-path) is empty. Why it is empty? You could start by posting output of the following commands:

$ xcrun --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
 $ xcrun cc --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
 $ make --version
GNU Make 3.81
<snip>

Sot that's OK. But I am finding parts of xcode get broke after sourcing the openfoam bashrc:

 $ xcodebuild -version
Xcode 7.2.1
Build version 7C1002
 $ source etc/bashrc
clang: error: unsupported option '--showme:link'

Please download binary Paraview release from
http://paraview.org and install it in /Applications
folder.

 $ xcodebuild -version
dyld: Symbol not found: _CGLGetCurrentContext
  Referenced from: /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
  Expected in: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
 in /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
Trace/BPT trap: 5

Maybe a path issue. I'll try to hunt it down, but I will be grateful for any hints.

[alexeym]

Hi,

To have more hints, one needs to know what modifications you have made.

This part is rather funny:

$ source etc/bashrc
clang: error: unsupported option '--showme:link'

For some reason mpicc wrapper passes flag directly to clang. [RANT]Macports openmpi package is something very strange, it pull gcc5 for gfortran and has no option to disable this, it installs man pages from mpich, it ignores installed gcc5 and uses clang and clang++ for mpicc and mpicxx. At this point I have decided that it was enough and uninstalled Macports.[/RANT]

This

$ xcodebuild -version
dyld: Symbol not found: _CGLGetCurrentContext
  Referenced from: /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
  Expected in: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
 in /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
Trace/BPT trap: 5

could be caused by wrong DYLD_LIBRARY_PATH variable content.

Again, since you have modified patch I do not have any more comments. I have Xcode 7.2.1 and OpenFOAM compiles smoothly with unmodified patch.

[jjstickel]

Originally Posted by alexeym

Hi,

To have more hints, one needs to know what modifications you have made.

This part is rather funny:

<snip>

[RANT]Macports openmpi package is something very strange, it pull gcc5 for gfortran and has no option to disable this, it installs man pages from mpich, it ignores installed gcc5 and uses clang and clang++ for mpicc and mpicxx. At this point I have decided that it was enough and uninstalled Macports.[/RANT]

<snip>

Again, since you have modified patch I do not have any more comments. I have Xcode 7.2.1 and OpenFOAM compiles smoothly with unmodified patch.

I fixed the mpi error. I needed to specify MPICH rather SYSTEMOPENMPI in the bashrc (I am using macports mpich).

I've made some progress. Indeed, having "/opt/local/lib" in DYLD_LIBRARY_PATH is causing my xcode symbol error. I'll see if I can figure out why the entire path is being added. What I have changed from your patch is essentially just the modifications of CGAL.sh, metis.sh, and scotch.sh (i.e., the parts that specifically called out "brew"). I'll attach those sections.

Regarding your rant, my understanding is that (for the default variant) gcc5 is installed as dependency only to support fortran with mpich (or openmpi); clang is used for the c/c++ parts. It should not cause a problem for openfoam. BTW, previously I did successfully compile openfoam-2.4 with apple clang. Now I am trying to do the same with 3.0. I only mention this as a point of clarification, not to stir the homebrew vs macports waters!

[alexeym]

DYLD_LIBRARY_PATH is filled by config/settings.sh and config/CGAL.sh (via _foamAddLib call). Since all your third-party libraries are in /opt/local/lib, it is added there.

In fact, since library paths are compiled into executables:

$ pwd
/Users/.../platforms/darwin64ClangDPInt64Opt/bin
daphne:bin$ otool -L mapFields
mapFields:
	/Users/.../lib/libsampling.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/.../lib/libmeshTools.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/.../lib/liblagrangian.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/.../lib/libfiniteVolume.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/.../lib/libgenericPatchFields.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/..../lib/libOpenFOAM.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)

These _foamAddLib calls could be skipped except one place:

_foamAddLib  $FOAM_USER_LIBBIN:$FOAM_SITE_LIBBIN:$FOAM_LIBBIN:$FOAM_LIBBIN/dummy

Adding $FOAM_LIBBIN before $FOAM_LIBBIN/dummy allows executables to find parallel libPStream.dylib instead of dummy one, since (man dyld):

DYLD_LIBRARY_PATH
       This  is  a  colon separated list of directories that contain libraries. The
       dynamic linker searches these directories before  it  searches  the  default
       locations  for  libraries.  It  allows  you to test new versions of existing
       libraries.

[alexeym]

Additions concerning your patch:

- What if Macports are installed somewhere else (you know, /opt/local is just DEFAULT prefix)?
- What if someone does not want CGAL-dependent functionality (even Scotch and METIS are somewhat optional)?

[jjstickel]

Originally Posted by alexeym

DYLD_LIBRARY_PATH is filled by config/settings.sh and config/CGAL.sh (via _foamAddLib call). Since all your third-party libraries are in /opt/local/lib, it is added there.

In fact, since library paths are compiled into executables:
<snip>
These _foamAddLib calls could be skipped except one place:

_foamAddLib  $FOAM_USER_LIBBIN:$FOAM_SITE_LIBBIN:$FOAM_LIBBIN:$FOAM_LIBBIN/dummy

Adding $FOAM_LIBBIN before $FOAM_LIBBIN/dummy allows executables to find parallel libPStream.dylib instead of dummy one, since (man dyld):
<snip>

OK, thanks. I borrowed some lines from the Macports-supported 2.4 patch to exclude the inclusion of /opt/local/lib in DYLD_LIBRARY_PATH.

Anyway, success! I had some problems with macports mpich that went away when I switch to openmpi. I'll post more, including a patch, on the "... 3.0.x with MacPorts" thread. That's probably where this discussion should have been, but I wasn't sure you would be monitoring that thread. Thanks for your help, Alexey. I'd be amenable to upload my patch and add to the wiki on your git repo (but only if you are interested). BTW, I worked from your "alternative" patch for 3.0.1.

[jjstickel]

Originally Posted by alexeym

Additions concerning your patch:

- What if Macports are installed somewhere else (you know, /opt/local is just DEFAULT prefix)?
- What if someone does not want CGAL-dependent functionality (even Scotch and METIS are somewhat optional)?

Sure, what I've done needs improvement, especially for it to apply across multiple use cases. Let's discuss on the the other thread. I'll upload my full patch there shortly.