I am currently in the process of compiling graph-tool v1.13 from the Git version. I have managed to generate the configure file from autogen.sh but am now running into trouble.
Running ./configure I receive the message:
checking whether g++ supports C++14 features by default... no
checking whether g++ supports C++14 features with -std=gnu++14... no
checking whether g++ supports C++14 features with -std=gnu++0x... no
configure: error: *** A compiler with support for C++14 language features is required.
I have checked gcc -v and g++ -v and receive the response gcc version 4.9.3 (Ubuntu 4.9.3-8ubuntu2~14.04). To my knowledge this should support C++14 so where am I going wrong? I am running Ubuntu 14.04.
Try perhaps
./configure CXX='g++-5'
after having installed some GCC 5
gcc 4.9.3 supports C++14, but the correct compiler flag is '-std=c++14'
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.
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 compiled and installed GCC 4.5.1 via MacPorts in my installation of Mac OS X 10.6.4. When trying to ./configure software (such as, but not limited to: Wine 1.3.0, libjpeg, etc.), I set the compiler flag to CFLAGS = "-arch x86_64 -m64" to make sure that the compiled program will be 64-bit enabled. But I got an error during configure saying:
"checking whether the C compiler works... no"
This does not occur if I remove "-arch x86_64" from CFLAGS. Is there a solution to this? Or have I set the flags incorrectly?
Thanks!
-arch is a flag only in Apple's version of gcc. Since you built from source that didn't come from Apple, your new gcc doesn't have that flag. Check its man page for what flag you should be passing to make it generate 64-bit code.
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