I want to embed the Python 3.3 interpreter into Mac OS 10.9 Cocoa app to add some Python functionality. From what I've read from another StackOverflow Q&A, it would be best to create a static library (references in footer) than a dynamic library.
Here is what I've tried to create a static library (.a file) out of the Python interpreter:
I've downloaded the Python 3.3 (CPython) source code from here.
I've added *static* inside the Modules/Setup.dist file
I've entered the following to compile the source in the Terminal:
./configure LDFLAGS="-static -static-libgcc" CPPFLAGS="-static"
The result I get is the following:
checking build system type... x86_64-apple-darwin13.1.0
checking host system type... x86_64-apple-darwin13.1.0
checking for --enable-universalsdk... no
checking for --with-universal-archs... 32-bit
checking MACHDEP... darwin
checking for --without-gcc... no
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/Path/To/My/Source/Python-3.3.4':
configure: error: C compiler cannot create executables
See `config.log' for more details
My understanding is that gcc is actually replaced by Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) in Mavericks.
Also, I found the following in the config.log...
configure:3914: checking whether the C compiler works
configure:3936: clang -static conftest.c >&5
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Question: How can I compile Python 3.3 using Apple LLVM so I have a static library such as libpython3.3.a?
Reference 1:
Getting Python to work in Cocoa App
Reference 2:
Compile the Python interpreter statically?
I think it defaults to building a static library, on Unix based platforms, including OSX. That is, just plain configure, make, make install. It worked for me and built libpython3.4m.a. But you might consider using --prefix and read about installing multiple versions of Python on OSX.
The thread you referenced is old?
Embedding is not so strange, otherwise Python documents and books wouldn't discuss it in depth.
As of python 3.5, no need to use the LDFLAGS nor CPPFLAGS at configure time.
With the configure --disable-shared flag, it will build a static library.
With the configure --enable-shared flag, it will build a dynamic library.
Combining with --prefix, you can setup you own python distribution with all the packages you want. You can have both a static python library to incorporate to your applications, and a dynamic library to let the interactive python launch properly.
Related
I have followed instructions provided in other articles to fix the below issue but still doesn't appear to work for my system. I am trying to upgrade glibc to v2.27 on my CentOS 7.3 machine. I downloaded the package and running into the below compiler dependency during the configure script execution:
../configure --prefix=/opt/glibc-2.27
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... gcc
...
...
checking if gcc is sufficient to build libc... no
checking for nm... nm
checking for python3... no
checking for python... python
configure: error:
*** These critical programs are missing or too old: compiler
*** Check the INSTALL file for required versions.
So I upgraded my gcc and verified the upgraded version:
gcc --version
gcc (GCC) 8.2.0
I also have the following environment variable set in my bashrc:
export CC=/usr/local/bin/gcc
For some reason, the configure script still throws the same error based on which it appears that the upgraded gcc version isn't being used.
What am I missing?
I have installed fftw and boost with conda;
conda install -c https://conda.anaconda.org/anaconda boost
conda install -c https://conda.anaconda.org/nlesc fftw
tmv with scons
tmv0.72){58}> scons install PREFIX=/home/rgm/local
the scons with the various variables specified earlier as shown below:
scons
scons: Reading SConscript files ...
SCons is version 2.3.5 using python version 2.7.10
Python is from /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
Using the following (non-default) scons options:
PREFIX = /home/rgm/local/
TMV_DIR = /Users/rgm/local
FFTW_DIR = /Users/rgm/anaconda/
BOOST_DIR = /Users/rgm/anaconda/
These can be edited directly in the file gs_scons.conf.
Type scons -h for a full list of available options.
Using python = /home/rgm/anaconda/bin/python
Using default PYPREFIX = /home/rgm/anaconda/lib/python2.7/site-packages
Using compiler: /home/rgm/anaconda/bin/g++
compiler version: 4.8.5
Determined that a good number of jobs = 4
Checking for C++ header file fftw3.h... yes
Checking for correct FFTW linkage... yes
Checking for boost header files... yes
Boost version is 1.57.0
Checking for C++ header file TMV.h... yes
TMV version is 0.72
Using TMV_LINK file: /Users/rgm/local/share/tmv/tmv-link
-L/home/rgm/local/lib -ltmv -lblas -lpthread -fopenmp
Mac version is 10.10.5
XCode version is 7.2
Checking for correct TMV linkage... (this may take a little while)
Checking for correct TMV linkage...
Error: TMV file failed to link correctly
Check that the correct location is specified for TMV_DIR
looking in config.log there are lines like:
Undefined symbols for architecture x86_64:
"_fftw_destroy_plan", referenced from:
_main in conftest_2.o
The proximate problem here is that it cannot find the OpenMP library (libgomp.1.dylib) at runtime. Here are the relevant lines from the config.log:
g++ -o .sconf_temp/conftest_16 -fopenmp .sconf_temp/conftest_16.o -Llib -L/Users/rgm/anaconda/lib -L/Users/rgm/local/lib -L/home/rgm/local/lib -ltmv_symband -lfftw3 -lpthread -ltmv -lblas -lpthread
.sconf_temp/conftest_16 > .sconf_temp/conftest_16.out
dyld: Library not loaded: #rpath/./libgomp.1.dylib
Referenced from: /data/vault/rgm/soft/MACOS/GalSim/.sconf_temp/conftest_16
Reason: image not found
sh: line 1: 20592 Trace/BPT trap: 5 .sconf_temp/conftest_16 > ".sconf_temp/conftest_16.out"
I've had similar troubles with Anaconda before on Macs. They seem to try to force the Mac to use Unix-style run-time library resolution, rather than follow the normal way Macs do it, which is fundamentally different. In particular, this #rpath thing works really nicely on Linux/Unix systems, but not so much on Macs. I guess with their own conda-installed libraries, they have a way to make it all work correctly , but it doesn't mesh very well with outside libraries that are installed in the normal Mac way.
Anyway, since it's just the OpenMP stuff in TMV, and the matrix operations in GalSim are never time critical, your easiest option is probably to install TMV without OpenMP support using scons install WITH_OPENMP=false.
Then try installing GalSim again.
I am trying to build GraphChi on OS X Yosemite but get the following error:
fatal error: 'omp.h' file not found
From this question - How to include omp.h in OS X? - I learned that Yosemite uses Clang instead of gcc, which does not include omp.h.
$ which gcc
/usr/bin/gcc
$ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
Next, I installed gcc via Homebrew
$ brew info gcc
gcc: stable 4.9.2 (bottled)
http://gcc.gnu.org
/usr/local/Cellar/gcc/4.9.2_1 (1092 files, 177M)
Built from source with: --without-multilib
and updated $PATH to include the path to the new gcc version
$ echo $PATH
/usr/local/Cellar/gcc/4.9.2_1:usr/local/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin
however, gcc -v and which gcc still point to the old version, and building GraphChi still doesn't work due to the missing omp.h file
Does anyone know what else I need to do?
Update
locate omp.h returned:
/usr/local/Cellar/apple-gcc42/4.2.1-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/include/omp.h
/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/gcc/x86_64-apple-darwin14.1.0/4.9.2/include/omp.h
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/include/omp.h
my ~/.profile:
export PATH=/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/gcc/x86_64-apple-darwin14.1.0/4.9.2/include:/usr/local/Cellar/gcc/4.9.2_1/bin:usr/local/bin:/opt/local/bin:/opt/local/sbin:$PATH
I solved this with installing gcc with homebrew:
brew install gcc --without-multilib
and then building the source code with
CC=gcc-5 CXX=g++-5 cmake ..
CC=gcc-5 CXX=g++-5 make -j7
Once you have installed gcc-4.9 with homebrew, it will automatically be in your path. To use OpenMP, you just need to make sure you are using the newly installed gcc-4.9, and it will be able to find omp.h.
In the case of GraphChi, you will have to go change line 3 of the Makefile to be gcc-4.9. From there, running make should just work. They describe this in their README, but at least the version they describe is out of date https://github.com/GraphChi/graphchi-cpp#problems-compiling-on-mac.
clang does not support OpenMP yet. Also gcc by default links to Apple's LLVM clang compiler (not the GCC installed from brew).
Instead gcc-4.9 would link to GCC. I think if -fopenmp is specified omp.h is included automatically.
It is possible to manually build a version of clang with OpenMP support, see http://clang-omp.github.io
You shouldn't add the include path to PATH; instead, specify it as CFLAGS, including the -I option. You can export the CFLAGS variable, or set it on the fly.
Depending on how you compile things, you could do
CFLAGS=-I/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/gcc/x86_64-apple-darwin14.1.0/4.9.2/include/omp.h gcc <whatever>
Of course, in this case you can specify it directly on the gcc command (as -I/usr/local/....), but the CFLAGS variable also works with configure (as configure often won't have an option to specify where it should look for specific include files); probably with make, or even for those installing a Python package: CFLAGS=-I... pip install <some-package>.
Other flags to consider are
CXXFLAGS: C++ specific pre-processor flags
LDFLAGS: linker specific flags (e.g. LDFLAGS=-L/some/path/... for linking with dynamic libraries).
CC: specify the C compiler to use. This is an easy way to avoid the built-in gcc alias for clang on OS X. Just use CC=/usr/local/bin/gcc-4 make or similar.
CXX: specify the C++ compiler to use.
I am trying to set up a completely recent and up to date gcc environment... basically gcc 4.6.3 and binutils 2.22. Not the fairly old gcc 4.2.1 (llvm) that comes with Xcode 4.2.1. My problem is not with compiling (for now, at least). I can compile binutils, gcc, and both at the same time perfectly. However each time I try to compile I find something like this appear at the end of configure's output
checking where to find the target ar... just compiled
checking where to find the target as... host tool
checking where to find the target cc... just compiled
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
checking where to find the target dlltool... just compiled
checking where to find the target gcc... just compiled
checking where to find the target gcj... just compiled
checking where to find the target gfortran... just compiled
checking where to find the target gccgo... host tool
checking where to find the target ld... host tool
checking where to find the target lipo... host tool
checking where to find the target nm... just compiled
checking where to find the target objdump... just compiled
checking where to find the target ranlib... just compiled
checking where to find the target strip... just compiled
checking where to find the target windres... just compiled
checking where to find the target windmc... just compiled
I made a symlinks for ld, opcodes, bfd, gas, gprof, and binutils in the gcc source folder to get this output... (if that helps)
As you can see I can get a "just compiled" version of most software, by I just can't figure out how to compile as and ld. I have read the README file in the ld folder (which in the the binutils package) and it says to execute:
make all-ld
I do and being that I already "made" the source, it tells me nothing is left to do...
The only thing I can think of now is to temporally modify my path to not include ld. This would be pretty easy...
aka a quick check with
whereis ld
anyway immediately after thinking of this I relized it would be stupid being now I would have nothing to link gcc (or even a new version of ld (if I got to work at all))
So, in conclusion, I am trying to compile a new copy of ld and as...
The facts:
I am running Mac OS X Lion.
I am trying to compile gcc 4.6.3 using the default gcc that comes with Mac OS X Lion (gcc 4.2.1).
The configure scripts seem to think I do not want to compile a new linker and assembler.
I have successfully built a working gcc and binutils but without a new linker and assembler.
I have tried to compile binutils and gcc with the --with-ld=yes and --with-gold=no option, they didn't seem to do anything.
I built gmp v5.0.4, mpfr v3.1.0, and mpc v0.9 using gcc v4.2.1, installing them in the same prefix as used in the gcc and binutils configure.
For each configure I am explicitly stating the locations of gmp, mpfr, and mpc.
I built gmp, mpfr, and mpc separately from gcc (doing so, resulted in some build errors).
gcc, binutils, gmp, mpfr, and mpc are all build in a separate directory which is not a subdirectory of the source directory (as recommended by the gcc installation instructions).
I am compiling gcc with the following options:
../gcc-4.6.3/configure --prefix=$PREFIX --with-gmp=$PREFIX --with-mpfr=$PREFIX --with-mpc=$PREFIX --enable-checking=release --program-suffix=-4.6.3 --enable-ld=yes --enable-gold=no
I mainly followed this tutorial.
Because I have no other compiler on my computer I am forced to use the mac os x default llvm compiler (what I described earlier as gcc 4.2.1) which I read here doesn't work, however I don't have gcc-4.2 on my computer.
Compiling gcc-4.7.0 (the very recent snapshot) using the new version of gcc I just compiled (gcc-4.6.3) results in compiler errors (I set the environment variables CC and CXX).
I have tried compiling gcc first, than binutils, and the other way around, eventually I decided building gcc with binutils was the way to go. The output above you was with both compiled at once
I read this little post on gold, and tried adding --enable-gold and --enable-ld. They changed nothing
The order in which I did things:
Compile gmp.
Install it.
Compile mpfr.
Install it.
Compile mpc.
Install it.
Make symlinks to the main gcc src directory for ld, gas, binutils, opcodes, gprof, bfd.
Configure gcc.
Find that "status report."
Think of another way to possibly build ld and as.
Fail at that.
Go on Stack Overflow.
as "fazo" said, I am not really telling anyone much about how I compiled binutils... so here it is...
I tried first compiling gcc, than building binutils using gcc, that compiled fine, but no ld, as, or even gold. Then I tried using the llvm compiler to build binutils then gcc. It also worked fine, but still no ld, as, or gold. Finally, I read here that I could make symlinks to some items in binutils and gcc would detect and build them... I did. and gcc found most of them (as stated before I put symlinks in the gcc directory for ld, opcodes, bfd, gas, gprof, and binutils) My actual problem here is telling the configure script to compile a new assembler and linker. Also, what boggles me, is in the binutils README folder it says that a mere ./configure make make install will build and install all the tools, I am trying to figure out why this is not the case.
The final command comes out to be:
../binutils-2.22/configure --prefix=$PREFIX --with-gmp=$PREFIX --with-mpfr=$PREFIX --with-mpc=$PREFIX --program-suffix=-4.6.3 --enable-ld --with-gnu-as --with-gnu-ld
yet I still get no ld and no gas.
Any help is greatly appreciated! (also if you want some info I haven't supplied, just ask)
thanks... :)
Afaik with standard builds (configure;make), the results are named differently. gas-new and gld-new or so.
Note that OS X doesn't normally use binutils but Apple's own Mach-O linker (cctools). Even if you succeeded, it might not lead to a workable solution
Binutils does not support an assembler or linker on OS X, see the binutils configure script:
case "${target}" in
*-*-chorusos)
;;
aarch64-*-darwin*)
noconfigdirs="$noconfigdirs ld gas gdb gprof"
noconfigdirs="$noconfigdirs sim target-rda"
;;
arm-*-darwin*)
noconfigdirs="$noconfigdirs ld gas gdb gprof"
noconfigdirs="$noconfigdirs sim target-rda"
;;
powerpc-*-darwin*)
noconfigdirs="$noconfigdirs ld gas gdb gprof"
noconfigdirs="$noconfigdirs sim target-rda"
;;
i[3456789]86-*-darwin*)
noconfigdirs="$noconfigdirs ld gprof"
noconfigdirs="$noconfigdirs sim target-rda"
;;
x86_64-*-darwin[912]*)
noconfigdirs="$noconfigdirs ld gas gprof"
noconfigdirs="$noconfigdirs sim target-rda"
;;
*-*-darwin*)
noconfigdirs="$noconfigdirs ld gas gdb gprof"
noconfigdirs="$noconfigdirs sim target-rda"
;;
For any darwin (i.e. OS X) target, this adds ld and gas to the noconfigdirs list. That means those directories will be skipped during the build.
To build GCC on OS X you need to use the native OS X assembler and linker (which are part of the "Xcode Command Line Tools" package, from the App Store).
I realized, that it was basically a mac issue. After installing and getting Ubuntu it built the linker and assembler just fine... still having a bit of trouble compiling gcc, but that is because of Debian's new multi architecture support... but this is another issue... Thanks for your help Marco van de Voort
I am attempting to compile gcc 4.4.0 on opensolaris 2009.6
Currently in the box (which is a AMD 64bit machine), I have the gcc 3.4.6 installed.
I unpacked the gcc 4.4.0 tarball.
I set the following env variables:
export CXX=/usr/local/bin/g++
export CC=/usr/local/bin/gcc
Then I ran "configure && make" and this is the error message that I got:
checking for i386-pc-solaris2.11-gcc... /export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64
checking for suffix of object files... configure: error: in `/export/home/me/wd/gcc/gcc-4.4.0/i386-pc-solaris2.11/amd64/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Anyone has any suggestion as to how to work around this error message?
/Edit:
Content of the config.log is posted here: link text
Normally the GCC build is bootstrapped, i.e. first it uses the system compiler to build GCC C compiler, and then it uses the freshly built compiler to recompile GCC once again (and then even once more time again). The configure line shows that it is not the system compiler but the already-built GCC compiler which is used for configure test there.
Since it fails, the problem is that the freshly-built GCC is somehow "stillborn" here. If config.log will not help you, I'd suggest to ask at gcc-help#gcc.gnu.org.
EDIT: Ah-ha, I think it is the assembler. You are using GNU assembler, but the unsupported options look like they were meant for Sun assembler. This should be solved by adding --with-gnu-as configure option (and then possibly having to specify its path explicitly with --with-as=/usr/gnu/bin/as)
You can also take a look at Solaris-specific GCC build instructions.
There's a readily available build for gcc4, which you can try updating. Its current version is 4.3.3. To get started, install pkg-get from OpenCSW and check out the build from the subversion repository:
svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/trunk/ gcc4
cd gcc4
gmake package