On 09/08/2015 17:00, Eric Thornton wrote:
Hello all,
Hi Eric,
firstly, sorry for the delayed response as I have been off the grid for
a few weeks enjoying some holiday time.
I've run into the same (or similar issue) compiling on OSX. I need to
compile my own version since I'm using pulse audio as my sound server.
I've already compiled QT from macports with pulse audio support.
If I use CC=gcc and CXX=g++, ham lib won't compile. I have been unable
to work around the "-no-cpp-precomp" error. Anyway, I'm pretty sure my
macports libs and QT are build with clang (the default) anyway.
If I use the default clang compilers, ham lib compiles fine (after
pointing it to glibtoolize), but then wsjtx won't compile because of
the openmp errors. I am using FC=gfortran-mp-4.9 from macports.
There should be no fatal errors with those tools if you use the CMake
build script. What make you think the build fails?
I don't have a good understanding of openmp. Is this error because
clang and gfortran are not compatible? I tried downloading a native
gfortran compiler but got the same result.
Using CLang/Clang++ combined with gfortran from MacPorts is a valid
combination and is the only one supported. The reason for this is that
Qt only supports compilation with CLang++ on OS X. Clang/Clang++ have no
OpenMP support but since our code only uses OpenMP in Fortran modules we
are able to get away with the mixed compiler support. The CMake build
script does what is necessary to make this apparently incompatible tool
set work. It does report the OpenMP availability issues but they can be
safely ignored for WSJT-X builds.
Thanks,
Eric
KM4DSJ
73
Bill
G4WJS.
-- Building for for: Darwin-x86_64
-- ******************************************************
-- Try OpenMP C flag = [ ]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-Qopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-xopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [+Oopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-qsmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP C flag = [-mp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [ ]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-Qopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-xopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [+Oopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-qsmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Try OpenMP CXX flag = [-mp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
-- Could NOT find OpenMP (missing: OpenMP_C_FLAGS OpenMP_CXX_FLAGS)
On Mon, Jun 29, 2015 at 6:12 PM, Bill Somerville
<g4...@classdesign.com <mailto:g4...@classdesign.com>> wrote:
On 29/06/2015 22:58, Steven Franke wrote:
> Bill,
Hi Steve,
>> On Jun 29, 2015, at 4:43 PM, Bill Somerville
<g4...@classdesign.com <mailto:g4...@classdesign.com>> wrote:
>>
>> On 29/06/2015 22:30, Steven Franke wrote:
>>> Bill,
>> Hi Steve,
>>>> On Jun 29, 2015, at 4:26 PM, Bill Somerville
<g4...@classdesign.com <mailto:g4...@classdesign.com>> wrote:
>>>>
>>>> On 29/06/2015 22:17, Steven Franke wrote:
>>>>> Bill,
>>>>>
>>>>>> On Jun 29, 2015, at 3:57 PM, Bill Somerville
<g4...@classdesign.com <mailto:g4...@classdesign.com>> wrote:
>>>>>>
>>>>>> On 29/06/2015 21:34, Steven Franke wrote:
>>>>>>> Bill,
>>>>>>>> On Jun 29, 2015, at 9:00 AM, Bill Somerville
<g4...@classdesign.com <mailto:g4...@classdesign.com>> wrote:
>>>>>>>>
>>>>>>>> On 28/06/2015 22:08, Steven Franke wrote:
>>>>>>>>> Thanks Bill,
>>>>>>>> Hi Steve,
>>>>>>>>> For what it’s worth, here a link to the VERBOSE build
capture:
>>>>>>>>>
https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt
>>>>>>>>>
>>>>>>>>> Here’s the CMakeCache.txt:
>>>>>>>>> https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt
>>>>>>>> OK, the problem wasn't quite what I thought. It is an
include directive
>>>>>>>> ordering issue but it stems from the use of FFTW3 from
MacPorts, this in
>>>>>>>> itself is not an issue but it has the side effect of
picking up the Qt4
>>>>>>>> headers as well. Unfortunately I can't find an easy way
of ensuring the
>>>>>>>> -I/opt/local/include is after the includes for Qt5. That
would solve the
>>>>>>>> issue but the way that the Qt includes are detected by
CMake doesn't
>>>>>>>> seem to have a way to change the ordering. I have posted
a question to
>>>>>>>> the CMake ML but for now you should be able to build by
deactivating
>>>>>>>> qt4-mac before building WSJT-X. It would be wise to add a
>>>>>>>> '--clean-first' to the CMake build for the first time to
ensure any
>>>>>>>> incorrectly built object files are discarded. Something like:
>>>>>>>>
>>>>>>>> $ sudo port deactivate qt4-mac
>>>>>>>> $ cmake --build ~/Builds/wsjtx --clean-first --target
install -- -j
>>>>>>>> $ sudo port activate qt4-mac
>>>>>>>> $ open ~/Builds/wsjtx_install/wsjtx.app
>>>>>>> This got me past the incorrect headers issue, but now it
dies because of an OpenMP problem. I’ve placed the VERBOSE build
capture here:
>>>>>>>
https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt
>>>>>>>
>>>>>>> and the CMakeCache.txt here:
>>>>>>> https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt
>>>>>> Is your OS X 32-bit or 64-bit?
>>>>>>
>>>>>> https://support.apple.com/en-gb/HT201948
>>>>> My processor is 64-bit:
>>>>>
>>>>> Hardware Overview:
>>>>>
>>>>> Model Name: MacBook Air
>>>>> Model Identifier: MacBookAir5,2
>>>>> Processor Name: Intel Core i7
>>>>> Processor Speed: 2 GHz
>>>>> Number of Processors: 1
>>>>> Total Number of Cores: 2
>>>>> L2 Cache (per Core): 256 KB
>>>>> L3 Cache: 4 MB
>>>>> Memory: 8 GB
>>>>> Boot ROM Version: MBA51.00EF.B02
>>>>> SMC Version (system): 2.5f9
>>>>> Serial Number (system): C02J401ADRVG
>>>>> Hardware UUID: 1F7ABB4C-7FB0-5918-8AE6-0CA0AB789A89
>>>>>
>>>>> and I am running the 64-bit kernel:
>>>>> $ uname -a
>>>>> Darwin Stevens-MacBook-Air.local 14.3.0 Darwin Kernel
Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015;
root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64
>>>> OK, looks like the MacPorts libgcc is 32-bit only for some
reason. What
>>>> do the following print:
>>>>
>>>> $ grep build_arch /opt/local/etc/macports/macports.conf
>>> $ grep build_arch /opt/local/etc/macports/macports.conf
>>> #build_arch i386
>>>
>>>> and:
>>>>
>>>> $ grep universal /opt/local/etc/macports/macports.conf
>>> $ grep universal /opt/local/etc/macports/macports.conf
>>> # CPU architectures to use for Universal Binaries (+universal
variant)
>>> universal_archs x86_64 i386
>>>
>>>> and:
>>>>
>>>> $ file /opt/local/lib/gcc49/libgomp.1.dylib
>>> $ file /opt/local/lib/gcc49/libgomp.1.dylib
>>> /opt/local/lib/gcc49/libgomp.1.dylib: Mach-O 64-bit
dynamically linked shared library x86_64
>> Hmm, that is all as expected. I think that means the link is
picking up
>> another libgomp from somewhere outside of MacPorts. The only
other path
>> that seems likely is /usr/local/lib is there an old libgomp
there from
>> some prior build of gcc/gfortran?
> You’re a wizard! That was the problem. Moved the old libraries
out of the way and compile completed. Running it now.
> Thanks!!
Good, that was my last guess at a solution.
This is related to the liberties we take with OpenMP I mentioned
further
up this thread. Normally if you use gfortran you would link with
the gcc
compiler driver or gfortran itself, these know exactly were to get he
matching libgcc supporting libraries like libgomp and libgcc_1.
Because
we have to use the clang++ compiler driver to link since Qt uses that
for its C++, we have to manually add the gcc/gfortran support
libraries
to the link command line. Perhaps I should use the gcc/gfortran
compiler/linker driver to discover the correct paths to avoid this
kind
of issue.
It is a PITA that Apple and LLVM don't have a Fortran compiler nor
OpenMP support in clang/clang++.
...
73
Bill
G4WJS.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
