Hello all, 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. 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. Thanks, Eric KM4DSJ -- 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> 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> > 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> > wrote: > >>>> > >>>> On 29/06/2015 22:17, Steven Franke wrote: > >>>>> Bill, > >>>>> > >>>>>> On Jun 29, 2015, at 3:57 PM, Bill Somerville <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> 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. > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
------------------------------------------------------------------------------
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
