I am trying to build the Trilinos library on Mac OS X 10.6.8, basically following the instructions on this page and the CMake Quickstart document included with Trilinos.
In order to build it with CMake, the instructions recommend setting up a directory, e.g. /usr/local/trilinos, creating a ./do-configure script in it and running it. My script is:
EXTRA_ARGS=$#
cmake \
-D CMAKE_BUILD_TYPE:STRING=DEBUG \
-D Trilinos_ENABLE_TESTS:BOOL=ON \
$EXTRA_ARGS \
${TRILINOS_HOME}
Running this script starts the configuration, until an error appears. The verbose output can be found here: http://pastebin.com/abrEghD7
I think the relevant part of the message is:
-- Verifying Fortran/CXX Compiler Compatibility - Failed
CMake Error at /usr/local/Cellar/cmake/2.8.7/share/cmake/Modules/FortranCInterface.cmake:284 (message):
The Fortran compiler:
/usr/local/bin/gfortran
and the CXX compiler:
/usr/bin/c++
failed to compile a simple test project using both languages. The output
was:
However, I cannot explain why the script blames the Fortran and C++ compilers. I have tested the Fortran compiler with "Hello World", and used the C++ compiler of OS X for entire projects. As far as I can tell, both compilers work properly.
Can anyone guess what might be wrong?
EDIT: Seems like it is some compatibility issue, not a problem with the indivual compilers.
When I compile paraview. I set my CXX compiler to g++ and not the standard c++ as cmake does. Because otherwise I see a similar error.
Where did you get gfortran from? Builds from most sources don't support mac specific extensions like -arch which might make problems trying to combine both of them. Or they might just be different versions (if you're gfortran is much newer than your g++ they might be trying to pull in incompatible runtime versions).
In the numerical python community (which depends a lot on fortran) the recommended source for OS X is the binary from here. This is matched to the XCode gcc version and supports the Mac specific extensions.
Related
When I went to try to use the debugger in Clion, I got the following Error:
Error running 'array_practice': Debugger executable is incorrect
I have a debugger configured. It looks like it should work:
I downloaded gdb-10.2.tar.gz & gdb-10.2.tar.xz
files (as seggested in the jetbrains manual)
But I have no real clue as for what should I do with these files.
[![I installed MSYS2 by the instructions, TBH I didn't understand this part:
and from then on the GSL library will be automatically found by your compiler!
Make sure any compilers and libraries you install have this package prefix (mingw-w64-x86_64- for 64-bit or mingw-w64-i686- for 32-bit). Only use unprefixed packages for misc command-line utilities (such as grep, sed, make, etc), unless you know what you're doing.
]4]4
Anyway, Clion does not detect the c compiler :
(this question similar to this one but is not the same)
I'm using QtCreator on Windows platform, usually with vc toolchain.
sometimes with MinGW-W64, so for now, I'd like to try clang for some reasons.
unlike the post above - I don't use Qt library , just qtcreator as IDE, so I suppose I don't need to re-build it and QtCreator for a using clang kit, is it correct?
there are a few questions about that:
CLang distribution doesn't contain platform or even c/c++ runtime library, should i use it from vc kit? or/and MinGW runtime? how to switch between?
Correct my understanding please if it's wrong - for Win platform, clang has two options to use: 1) normal use - clang.exe ,as on any other platform 2) clang-cl.exe - additional layer which "looks like" cl.exe, and just parses cl command line keys and calls normal clang.
as I understand there is no LLDB for Windows platform , can I use GDB or CDB depends of the used runtime lib and binary format of the executable?
and finally - how to configure all this in qtcreator?
The following steps apply only to MSYS2 64-bit installation of QT Creator 4.5.1 (install instructions here), where you also have MinGW-w64 and mingw32-make installed on MSYS2; and you are building a non-QT C or C++ application.
These instructions use QMake, because QBS doesn't support MSYS2 clang. Well, QMake doesn't support it either, but I did figure out how to add support to QMake and I didn't figure out QBS.
There is QMake support for MSVC-clang but it outputs MSVC makefiles, so you can't build it with MSYS2 make. So that does not apply to us.
Install clang with pacman. I used pacman -Ss mingw-w64-x86_64-clang, your flavour may vary.
Add support for clang to QMake:
In the MSYS2 shell, go into /msys64/mingw64/share/qt5/mkspecs/
Do cp -a win32-g++ win32-clang-msys
Edit win32-clang-msys/qmake.conf and change gcc to clang, and g++ to clang++ (2 places each)
In the same file, take out -fno-keep-inline-dllexport -mthreads which are not supported by clang.
In QT Creator, set up a new Kit:
Go to Manage Kits.
Add a Custom Compiler for C and browse to the installed path (/mingw64/bin/clang.exe under your MSYS2 install).
Add a Custom Compiler for C++ as clang++.exe in the same place)
Add a manual Kit called Clang and set those two compilers as its compilers.
In the manual kit config set "Qt mkspec" as win32-clang-msys
Set "QT Version" to something. Even though I am using a non-QT project, the IDE doesn't like using the kit if "Qt version" is set to None.
Now you can attempt to build your project with the Clang kit and QMake.
I initially tried with QBS and the build failed due to this bug . But the build commands do succeed if I copy-paste them and cut out the bogus -target switch. So for QBS users I guess you have to switch to QMake in the meantime until they fix that bug.
Troubleshooting: I sometimes got an error Project ERROR: failed to parse default search paths from compiler output. This is a problem with QMake's lack of support for clang. The error tended to not occur if I built in a subdirectory of the .pro file, but did occur if I built in a sibling directory.
As a workaround: go back into win32-clang-msys/qmake.conf. Change the first clang back to g++. Then "Run Qmake" (from QT creator or commandline), then change it back. The first time you run QMake it writes the file .qmake.stash and then does not need to generate it again. The contents of this file were bogus for me but building seemed to work anyway.
Undefined references: I found that linking with -static produced a bunch of undefined references to __imp__cxa_ names. Not sure what the problem is here but maybe related to the bug with generating .qmake.stash. I guess the Qt developers would need to officially add non-MSVC Clang support to QMake.
Multiple definitions: The CLang linker gave multiple definitions for inline DLLexport functions. I found no workaround yet for this; g++ has -fno-keep-inline-dllexport to avoid this problem but CLang 5 does not support that flag.
I am using ubuntu 14.04, cmake 2.8.12.2, Qt5.6.2 (a built version), GNU make 3.81
After I run cmake with cmake PathToSource -G "Eclipse CDT4 - Unix Makefiles"
I do make. I get #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)."
# error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\
I then download source file of Qt5.7.0, build and install it without problem. I do again cmake PathToSource -G "Eclipse CDT4 - Unix Makefiles", make it. I get many errors, such as /home/sflee/Documents/Software_dev/3rd_party/Qt5.7.0/include/QtCore/qhash.h:957:10: error: ‘pair’ does not name a type
auto pair = qAsConst(*this).equal_range(akey); and /home/sflee/Documents/Software_dev/3rd_party/Qt5.7.0/include/QtCore/qbasicatomic.h:285:14: error: ‘Ops’ has not been declared
{ return Ops::fetchAndAddRelease(_q_value, valueToAdd); }
How to solve it?
Qt 5.7 requires C++11 compiler. If you get that kind of error from auto pair, it sounds like your compiler is not compiling C++11 code. There are two possible reasons:
You just need to pass -std=c++11 to your compiler, as explaned under this question.
You have too old compiler. However, since you compiled Qt 5.7 itself with the same compiler, this shouldn't be the problem for you.
Edit/Update/Note: Just let clang use libstdc++. Has been working really well for me so far.
===============================
In the past I have been able to succeed by doing something with cmake, but just now I discovered a buildit script inside the lib directory of the http://llvm.org/svn/llvm-project/libcxx/trunk project tree.
This buildit script appears to not make use of libsupc++ which is what the cmake approach that I took earlier used. For instance, this guide shows one cmake incantation to produce a makefile for libc++, which will be able to take care of compiling and installation.
My question is what is the difference between these different ways to produce the LLVM-libc++ and which one should be used? Will they behave differently?
The buildit script does not appear to provide any help for installation. Are there directions anywhere for how to properly install the library? With my previous libc++ built with cmake, I had to always add -lc++ to the linker flags (and the path with -L), which is not necessary in my OS X makefiles.
The libc++ website has a nice overview of the possible ways to build libc++.
I suggest using CMake + libc++abi.
Also see the Arch Linux User Repository build script, which uses the buildit script. I installed libc++ from that and used it with the Arch Linux Clang package succesfully by using
clang++ -std=c++11 -stdlib=libc++ -lc++abi
I recently switched back to Windows7 (x64) because of perfomance issues with my graphics card on linux but i miss the abilty to easily compile open source software on Windows. I have a copy of the intel c compiler which is somewhat better than the gnu c compiler and i would like to use it to compile software written for linux.
I've already installed cygwin and managed to compile something. The 'make-install' didn't work though but that's another issue. Now my question is, how can i tell 'make' to use the windows intel compiler?
Most of the configure scripts you'll find in OSS have probably been created by the Autotools. Those should, basically, support the icc. To use it, although you may have GCC installed side-by-side, it would be necessary to set the environment variable CC to the (cygwin) path to Intel's C compiler and CXX to Intel's C++ compiler prior to running configure.
You may run into trouble with software packages that unconditionally set compiler flags that only GCC understands. I have heard, though, that, by now, icc actually implements most of these.
Update
Something similar has been asked before.