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 - 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
