I've been trying to build Python from source on my mac with the Intel compiler suite (Intel Parallel Studio) and link it against Intel's MKL.
The reason for that is that I want to use the exactly the same environment on my mac for developing Python code as on our linux cluster.
As long as I am not telling the configure script to use Intel's parallel studio, Python builds fine (configure and make: ./configure --with(out)-gcc). But as soon as I include --with-icc, or if I set the appropriate environment variables, mentioned in ./configure --help, to the Intel compilers and linkers, make fails with:
icc -c -fno-strict-aliasing -fp-model strict -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Python/getcompiler.o Python/getcompiler.c
Python/getcompiler.c(27): error: expected a ";"
return COMPILER;
^
compilation aborted for Python/getcompiler.c (code 2)
make: *** [Python/getcompiler.o] Error 2
I've searched everywhere, but nobody seems to be interested in building Python on a mac with intel compilers, or I am the only one who has problems with it. I've also configured my environment according to Intel's instructions: source /opt/intel/bin/compilervars.sh intel64, in ~/.bash_profile.
In any case, my environment is:
OS X 10.11.6
Xcode 8.1 / Build version 8B62
Intel Parallel Studio XE 2017.0.036 (C/C++, Fortran)
Thanks,
François
You could edit the line in getcompiler.c that it is complaining about:
e.g. to
return "[Intel compiler]";
If you wanted to get fancier you could add in the compiler version, using e.g. the __INTEL_COMPILER macro.
Related
We are currently building our Go executables for several platforms including Solaris 64-bit. We have requests for a 32-bit Solaris executable version as well and I am unable to get this to work (the person who setup the Solaris 64-bit cross compiler is gone and unreachable).
I tried just setting -m32 flag on go build using our existing solaris cross compilation, but that didn't work, so I am attempting to build a Solaris 32-bit specific cross compiler.
I googled and found some vague examples, so I am following this process:
Copy headers and libraries from a 32-bit Solaris machine to my Linux build machine.
D/L and build binutils and gcc pointing SYSROOT to the downloaded 32-bit Solaris headers and libraries where:
$TARGET=sparc-sun-solaris2.10
$SYSROOT=/path/to/solaris32/includes
$PREFIX=/path/to/gcc-output
binutils-2.31/configure -target=$TARGET --prefix=$PREFIX -with-sysroot=$SYSROOT -v
gcc-8.2.0/configure --target=$TARGET --with-gnu-as --with-gnu-ld --prefix=$PREFIX -with-sysroot=$SYSROOT --disable-libgcj --enable-languages=c,c++,go -v
Create a symlink to gogcc and put GCC on the path
Compile a trivial test go program like this:
go build --compiler gccgo --gccgoflags "-m32 -O3 -static-libgo -Wl,-dy -lnsl -lsocket -lrt -lsendfile" -o ${GOTOOLS}/${BINARIES}/${PROJECT_NAME}/test/solaris_sparc32 test/main.go
This fails as follows:
go build: when using gccgo toolchain, please pass compiler flags using -gccgoflags, not -gcflags
command-line-arguments
gccgo: error: may not use both -m32 and -m64
Clearly I don't know what I'm doing. Can anyone point me in the right direction?
Solaris 32-bit does not appear to be supported, according to the list of supported OS/arch targets:
The valid combinations of $GOOS and $GOARCH are:
$GOOS $GOARCH
...
solaris amd64
...
That is, Solaris 64-bit is explicitly listed as a supported platform but Solaris 32-bit is not listed.
As such, there is good reason to believe that go programs will not run reliably on Solaris 32-bit systems and you probably should not agree to support that platform (if you do happen to get that cross compilation working) mainly because the go team itself does not support it!
I'm been attempting to compile an open-source C++ library (QuantLib-1.7) on my mac for several days but I seem to be encountering some kind of C++11 compatibility issue.
When I run make && sudo make install from the terminal the compilation seems to work except for a bunch of errors of the form
Making all in BermudanSwaption
g++ -DHAVE_CONFIG_H -I. -I../../ql -I../.. -I../.. -I/opt/local/include -g -O2 -MT BermudanSwaption.o -MD -MP -MF .deps/BermudanSwaption.Tpo -c -o BermudanSwaption.o BermudanSwaption.cpp
In file included from BermudanSwaption.cpp:22:
In file included from ../../ql/quantlib.hpp:43:
In file included from ../../ql/experimental/all.hpp:25:
In file included from ../../ql/experimental/volatility/all.hpp:21:
In file included from ../../ql/experimental/volatility/zabr.hpp:31:
In file included from ../../ql/math/statistics/incrementalstatistics.hpp:35:
In file included from /opt/local/include/boost/accumulators/statistics/stats.hpp:14:
In file included from /opt/local/include/boost/accumulators/statistics_fwd.hpp:12:
/opt/local/include/boost/mpl/print.hpp:50:19: warning: in-class initialization
of non-static data member is a C++11 extension [-Wc++11-extensions]
const int m_x = 1 / (sizeof(T) - sizeof(T));
^
1 warning generated.
I'm guessing this has something to do with g++ not being correctly configured for C++11. I'm familiar with the fact that C++11 can be invoked by compiling with g++ -std=c++11. However, despite a lot of googling I can't find a way to modify the makefile such that -std=c++11 is called when I run make && sudo make install.
Any help would be greatly appreciated.
Here is the section of the makefile which I believe is relevant:
BOOST_INCLUDE = -I/opt/local/include
BOOST_LIB = -L/opt/local/lib
BOOST_THREAD_LIB =
BOOST_UNIT_TEST_DEFINE = -DQL_WORKING_BOOST_STREAMS
BOOST_UNIT_TEST_LIB = boost_unit_test_framework-mt
BOOST_UNIT_TEST_MAIN_CXXFLAGS = -DBOOST_TEST_DYN_LINK
CC = gcc
CCDEPMODE = depmode=gcc3
CFLAGS = -g -O2
CPP = gcc -E
CPPFLAGS = -I/opt/local/include
CXX = g++
CXXCPP = g++ -E
CXXDEPMODE = depmode=gcc3
CXXFLAGS = -g -O2
Here is the output from running "g++ -v":
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
Makefile.am: https://www.dropbox.com/s/v5j7qohwfup81od/Makefile.am?dl=0
Makefile.in: https://www.dropbox.com/s/t92hft9ea2ar1zw/Makefile.in?dl=0
QuantLib-1.7 directory: https://www.dropbox.com/sh/ulj0y68m8x35zg8/AAA-w7L2_YWIP8_KnwURErzYa?dl=0
Full error log: https://www.dropbox.com/s/g09lcnma8skipv7/errors.txt?dl=0
Add something like
CXXFLAGS += -std=c++11
to your Makefile. This will work regardless of the Darwin-specific munging of the g++ executable---it's really clang++.
References:
https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/C_002b_002b-Dialect-Options.html#C_002b_002b-Dialect-Options
https://gcc.gnu.org/projects/cxx0x.html
http://clang.llvm.org/cxx_status.html
https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
As you already have, and are familiar with homebrew, my suggestion would be to use that to install and manage quantlib like this:
brew install quantlib
That will then build and put all the files in /usr/local/Cellar/quantlib under some version number that is not of importance. The important thing is the the tools are then linked into /usr/local/bin so all you need to do is make sure that /usr/local/bin is in your PATH.
That gives you access to the tool quantlib-config which is always linked to the latest version and it knows which version that is. So, if you run:
quantlib-config --cflags
it will tell you what the correct path is for your includes like this:
-I/usr/local/Cellar/quantlib/1.6.1/include
Likewise, if you run:
quantlib-config --libs
it will tell you the correct linking directories and libraries for your latest version.
In short, all you need to do to compile is:
g++ $(quantlib-config --cflags --libs)
and it will always pull in the version you are using.
Note that if you use a Makefile, you will need to double the dollar signs.
This is how I eventually managed to compile the Quantlib library for future reference. It is probably not the most efficient/elegant method but it appears to work.
I followed the steps given in http://quantlib.org/install/macosx.shtml and found that running make && sudo make install led to the error reported in the OP.
Create a new static library C++ project in Eclipse called 'Quantlib'
Copy the ql directory located in the .tar file to the Quantlib Eclipse workspace
Right-click Quantlib > Properties > C/C++ Build > Settings > Cross G++ Compiler: Change the Language standard to ISO C++ 11 (-std=c++0x)
Right-click Quantlib > C/C++ General > Paths and Symbols: Add the following include directories for GNU C++
opt/local/include
/Quantlib (check "Is a workspace directory")
/opt/local/include/boost.
Build the Quantlib project (around 34 min on MacBook Air 1.8 GHz Intel Core i7)
Create a new C++ executable project (e.g. BermudanSwaption) and copy the BermudanSwaption.cpp into the BermudanSwaption Eclipse workspace
Repeat steps 4. and 5. for the BermudanSwaption Eclipse project
Right-click BermudanSwaption > Properties > C/C++ General > Paths and Symbols > References: check Quantlib (the Library Paths tab should now contain the entry '/Quantlib/Debug')
Build and run the BermudanSwaption executable project
QuantLib-1.7
OSX Yosemite 10.10.5
Eclipse C/C++ Development Tools Version: 8.8.0.201509131935
Xcode Version 7.1 (7B91b)
xcode-select version 2339.
I'm trying to compile a C program that has some inline assembly code in Intel format. I'm using GCC 4.9 (installed via Homebrew) on Mac 10.9, and the compiler flags:
gcc-4.9 -m32 -masm=intel -std=gnu99 get_rating.c
Unfortunately I get an error:
error: -masm=intel not supported in this configuration
I've tried many different combinations of the flags, but I keep getting that error. I can't leave out the -masm=intel flag, because the code I'm trying to compile uses Intel.
How can I compile the program? Is it at all possible on my Mac (version 10.9) or do I need to run a virtual machine?
The GCC docs state that Darwin does not support intel, so it seems you are out of luck with the direct approach. Virtual machine as you suggested, cross compiling, converting the assembler to att, and replacing the assembler with C are among your options - which is best for you you'll have to figure out.
HTH
One of my users is getting an error message when trying to compile a C part of our mixed C/C++ codebase on ubuntu 12.04 with gcc 4.8.1
We have a library in C++ with some C-linkage functions in, and want to compile a C program linking to it. The library is compiled with g++ and builds fine. The c program fails like this:
> gcc -O3 -g -fPIC -I/media/Repo/lcdm/code/cosmosis/ -Wall -Wextra -pedantic -Werror -std=c99 -o c_datablock_t c_datablock_test.c -L . -lcosmosis
cc1plus: error: command line option ‘-std=c99’ is valid for C/ObjC but not for C++ [-Werror]
The program has a lower case .c file suffix, so why does gcc try to compile it as c++ ? We have not seen this on other OSes.
(I know we could kick the problem down the road by removing -Werror or handle this particular file with -x c but I'd like to solve the real problem.)
why does gcc try to compile it as c++
I can think of only two plausible explanations, and they both are end-user's fault.
It could be that the user transferred sources via Windows, and the file is really called C_DATABLOCK_TEST.C, and the user is misleading you.
It could also be that the user overwrote his gcc with g++ (surprisingly many people believe that gcc and g++ are the same thing, but they are not).
To disprove the first possibility, ask the user to execute his build commands under script, and send you resulting typescript.
To disprove the second, ask the user to add -v to the compile command.
This look like GCC Bug 54641, which has been fixed in a later release of GCC. It is only a warning, but your compile flags are causing GCC to treat all warnings as errors.
I want to generate the assembly file of my code oriented to the AVR architecture, I am using gcc version 4.7.2 with the following arguments:
g++ -O3 -Wall -S -Wp,-mmcu=atmega8 -o "src\Compression.o" "..\src\Compression.cpp"
but I am getting the following error:
cc1plus.exe: error: unrecognized command line option '-mmcu=atmega8'
But I got the command options from the gcc website:
http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gcc/AVR-Options.html#AVR-Options
There should be something that I am missing, could you help me with this please!
If gcc does not accept -mmcu, you are probably not using a gcc with support for the AVR architecture.
It's normally used like this:
avr-gcc -mmcu=atmega328p
because it's not only the preprocessor, it's actually other tools as well which require this setting (linker, assembler).
Normally the architecture gcc is compiled for is indicated by a prefix, in this case it's avr- by convention.
So the solution is to get a toolchain with AVR support. You can download it from Atmel's web site, even for Linux.
Update
If you like to check the configuration of your gcc, you can use -dumpmachine to check for the target processor
$ gcc -dumpmachine
i486-linux-gnu
$ arm-none-eabi-gcc -dumpmachine
arm-none-eabi
$ avr-gcc -dumpmachine
avr
If you look at the target specific options using --target-help
$ gcc --target-help | grep march
-march= Generate code for given CPU
you can see that the Linux gcc does accept -march as well. It probably fails later.
gcc is a very complex piece of software, because it just supports so many different architectures. From that perspective it works amazingly well.
Another interesting option is -v
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
[...]
to see how that gcc has been built.
And there could be another trap down the road (multi-libs), as you can see here