Re: [wsjt-devel] wsjt-x build problem on OS X
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,
Re: [wsjt-devel] wsjt-x build problem on OS X
Bill, Thanks for your reply. This is strange because I finally was able to get wsjtx to compile, but gave up on clang and used gcc for the whole process. After editing the hamlib autogen and configure scripts to get rid of an old no-precomp flag, things went smoothly. After the fact, while looking into why I still don't have any pulseaudio devices (posted a new message to the list on this last night) I found the notes on the libstdc++ and libc++ incompatibility. I think I should have received a linking error complaining about missing objects, but the build finished. The build failures I received with clang+gfortran were listed in the wsjtx-stamp/configure-error.log and had to do with missing openmp libs. I tried installing several different variants of gcc49 in macports, but got the same error every time. As a side note to my missing pulseaudio devices, I found that qt5-mac from macports is not building the pulse plugin, despite having selected the pulseaudio variant. I don't understand why, at this time. Eric KM4DSJ On Aug 27, 2015 9:43 AM, Bill Somerville g4...@classdesign.com wrote: 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 --
Re: [wsjt-devel] wsjt-x build problem on OS X
On 27/08/2015 19:02, Eric Thornton wrote: Bill, Hi Eric, Thanks for your reply. This is strange because I finally was able to get wsjtx to compile, but gave up on clang and used gcc for the whole process. After editing the hamlib autogen and configure scripts to get rid of an old no-precomp flag, things went smoothly. After the fact, while looking into why I still don't have any pulseaudio devices (posted a new message to the list on this last night) I found the notes on the libstdc++ and libc++ incompatibility. I think I should have received a linking error complaining about missing objects, but the build finished. AFAIK g++ builds of Qt5 are not supported and can only be done by doing some hacking of the mkspecs provided by the Qt team. Because of this I chose to use Clang++ from the Apple dev tools and gfortran from MacPorts with some special treatment in the CMake script to allow for the lack of OpenMP support in CLang++ and to ensure that the correct support libraries are linked. This has worked well so far and allows us to distribute a single DMG installer that works on 10.7 through 10.10. The build failures I received with clang+gfortran were listed in the wsjtx-stamp/configure-error.log and had to do with missing openmp libs. I tried installing several different variants of gcc49 in macports, but got the same error every time. Those errors should be non-fatal configuration errors and subsequent builds should work. Are you basing your WSJT-X build on the instructions in: https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/INSTALL As a side note to my missing pulseaudio devices, I found that qt5-mac from macports is not building the pulse plugin, despite having selected the pulseaudio variant. I don't understand why, at this time. Problems like that are usually due to missing dependencies at configure time. You probably need to check the configure log from Qt to see if the pulseaudio-dev package was detected at configure time. Eric KM4DSJ 73 Bill G4WJS. On Aug 27, 2015 9:43 AM, Bill Somerville g4...@classdesign.com mailto:g4...@classdesign.com wrote: 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 -
Re: [wsjt-devel] wsjt-x build problem on OS X
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
Re: [wsjt-devel] wsjt-x build problem on OS X
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? Also what does: $ nm -gU /opt/local/lib/gcc49/libgomp.1.dylib | grep parallel print? ... 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
Re: [wsjt-devel] wsjt-x build problem on OS X
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 ... 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
Re: [wsjt-devel] wsjt-x build problem on OS X
Steve, I had a look at your output but in cases like this, Bill is the expert. Does seem to be an omp problem. Your compiler picks out the same minor problems in wsprd.c as mine: in readwavfile unsigned long i, j, npoints might better be defined as int i, j, npoints to get rid of compiler warnings. --- John G4KLA -- 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
Re: [wsjt-devel] wsjt-x build problem on OS X
Bill, 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!! Also what does: $ nm -gU /opt/local/lib/gcc49/libgomp.1.dylib | grep parallel and just for completeness, and future reference: $ nm -gU /opt/local/lib/gcc49/libgomp.1.dylib | grep parallel 9732 T _GOACC_parallel 32aa T _GOMP_parallel 3240 T _GOMP_parallel_end 256c T _GOMP_parallel_loop_dynamic 24ba T _GOMP_parallel_loop_dynamic_start 2599 T _GOMP_parallel_loop_guided 24d0 T _GOMP_parallel_loop_guided_start 25c6 T _GOMP_parallel_loop_runtime 24e6 T _GOMP_parallel_loop_runtime_start 253f T _GOMP_parallel_loop_static 24a4 T _GOMP_parallel_loop_static_start 3619 T _GOMP_parallel_sections 359d T _GOMP_parallel_sections_start 320e T _GOMP_parallel_start 3432 T _omp_in_parallel 713e T _omp_in_parallel_ Thanks again! Steve k9an print? ... 73 Bill G4WJS. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the
Re: [wsjt-devel] wsjt-x build problem on OS X
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.
