I was following this guide:
When I ran:
make -f makefile.osx USE_UPNP=-
here is what I got in the terminal:
/bin/sh ../share/genbuild.sh obj/build.h
fatal: bad default revision 'HEAD'
llvm-g++ -c -g -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -DMAC_OSX -DMSG_NOSIGNAL=0 -DBOOST_SPIRIT_THREADSAFE -DUSE_IPV6 -DUSE_UPNP=- -DHAVE_BUILD_INFO -I"/Users/Bob/mycoin/src" -I"/Users/Bob/mycoin/src"/obj -I"/opt/local/include" -I"/opt/local/include/db48" -MMD -MF obj/version.d -o obj/version.o version.cpp
/bin/sh: llvm-g++: command not found
make: *** [obj/version.o] Error 127
Since Xcode 5 doesn't ship with llvm-g++ anymore, you need to install it manually. One of the possible ways is to install command-line tools.
Another option is to just set CXX to g++ in makefile.osx.
Related
I am getting the following error when I try to build gcc 8.2.0 on OpenBSD 6.3:
/bin/sh ./libtool --tag=CC --mode=compile /home/shane/gcc-8.2.0/host-i386-unknown-openbsd6.3/gcc/xgcc -B/home/shane/gcc-8.2.0/host-i386-unknown-openbsd6.3/gcc/ -B/opt/gcc-8.2.0/i386-unknown-openbsd6.3/bin/ -B/opt/gcc-8.2.0/i386-unknown-openbsd6.3/lib/ -isystem /opt/gcc-8.2.0/i386-unknown-openbsd6.3/include -isystem /opt/gcc-8.2.0/i386-unknown-openbsd6.3/sys-include -DHAVE_CONFIG_H -I../.././libatomic/config/x86 -I../.././libatomic/config/posix -I../.././libatomic -I. -march=i486 -mtune=i386 -fomit-frame-pointer -Wall -Werror -pthread -g -O2 -MT fence.lo -MD -MP -MF .deps/fence.Tpo -c -o fence.lo ../.././libatomic/fence.c
libtool: compile: /home/shane/gcc-8.2.0/host-i386-unknown-openbsd6.3/gcc/xgcc -B/home/shane/gcc-8.2.0/host-i386-unknown-openbsd6.3/gcc/ -B/opt/gcc-8.2.0/i386-unknown-openbsd6.3/bin/ -B/opt/gcc-8.2.0/i386-unknown-openbsd6.3/lib/ -isystem /opt/gcc-8.2.0/i386-unknown-openbsd6.3/include -isystem /opt/gcc-8.2.0/i386-unknown-openbsd6.3/sys-include -DHAVE_CONFIG_H -I../.././libatomic/config/x86 -I../.././libatomic/config/posix -I../.././libatomic -I. -march=i486 -mtune=i386 -fomit-frame-pointer -Wall -Werror -pthread -g -O2 -MT fence.lo -MD -MP -MF .deps/fence.Tpo -c ../.././libatomic/fence.c -fPIC -DPIC -o .libs/fence.o
../.././libatomic/fence.c:26:10: fatal error: stdatomic.h: No such file or directory
#include <stdatomic.h>
^~~~~~~~~~~~~
compilation terminated.
gmake[4]: *** [Makefile:491: fence.lo] Error 1
gmake[4]: Leaving directory '/home/shane/gcc-8.2.0/i386-unknown-openbsd6.3/libatomic'
gmake[3]: *** [Makefile:524: all-recursive] Error 1
gmake[3]: Leaving directory '/home/shane/gcc-8.2.0/i386-unknown openbsd6.3/libatomic'
gmake[2]: *** [Makefile:360: all] Error 2
gmake[2]: Leaving directory '/home/shane/gcc-8.2.0/i386-unknown-openbsd6.3/libatomic'
gmake[1]: *** [Makefile:21680: all-target-libatomic] Error 2
gmake[1]: Leaving directory '/home/shane/gcc-8.2.0'
gmake: *** [Makefile:943: all] Error 2
My process:
Install OpenBSD (using defaults)
Run syspatch
Add some packages:
# pkg_add wget
# pkg_add gmp mpfr libmpc
# pkg_add gmake
Get the source:
$ wget ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-8.2.0/gcc-8.2.0.tar.gz
$ tar xzf gcc-8.2.0.tar.gz
$ cd gcc-8.2.0
Build:
$ ./configure --prefix=/opt/gcc-8.2.0 --with-gmp=/usr/local --enable-languages=c,c++
$ gmake
This also fails with gcc 8.1.0 in a similar way.
I also tried using clang rather than gcc to build, like this:
$ CC=cc CXX=c++ ./configure --prefix=/opt/gcc-8.2.0 --with-gmp=/usr/local --enable-languages=c,c++
That made no difference, which makes some sense as apparently it is failing in stage 3 (gcc compiling itself again for a final check).
Annoyingly, there is a stdatomic.h file in the tarball:
$ find gcc-8.2.0 -name stdatomic.h
gcc-8.2.0/gcc/ginclude/stdatomic.h
So I have no idea what I am missing.
Has anyone successfully built this? How?
I am now installing a code on my mac.
The code is from here. Look for "Benchmark and Boundary Detection Code" in this page.
In the readme file, it says:
(1) For the image and segmentation reading routines in the Dataset
directory to work, make sure you edit Dataset/bsdsRoot.m to point to
your local copy of the BSDS dataset.
(2) Run 'gmake install' from this directory to build everything. You
should then probably put the lib/matlab directory in your MATLAB path.
(3) Read the Benchmark/README file.
For the 1st step, I did as suggested.
For the 2nd step, I am pretty confused. I ran command gmake install in MATLAB, however, I got:
gmake
Undefined function or variable 'gmake'.
Actually, before running MATLAB, I installed gmake port through macports.
I just did it in terminal, however, this is what I got...
hou229:segbench yaozhongsong$ cd /Users/yaozhongsong/Documents/MATLAB/segbench
hou229:segbench yaozhongsong$ sudo gmake install
gmake[1]: execvp: ../Util/gethosttype: Permission denied
gmake[1]: Entering directory `/Users/yaozhongsong/Documents/MATLAB/segbench/Util'
GNUmakefile-library:26: *** mexSuffix not defined. Stop.
gmake[1]: Leaving directory `/Users/yaozhongsong/Documents/MATLAB/segbench/Util'
hou229:segbench yaozhongsong$
In MATLAB, I also did like this:
!gmake install
/bin/bash: gmake: command not found
How to do the 2nd step in readme file?
Thanks in advance!
#Amro
hou229:segbench yaozhongsong$ cd /Users/yaozhongsong/Documents/MATLAB/segbench
hou229:segbench yaozhongsong$ sudo gmake install
Password:
gmake[1]: execvp: ../Util/gethosttype: Permission denied
gmake[1]: Entering directory `/Users/yaozhongsong/Documents/MATLAB/segbench/Util'
mkdir -p ../lib/matlab
g++ -g -Wall -fPIC -I../include -O3 -DNOBLAS -c Exception.cc -o build//Exception.o
g++ -g -Wall -fPIC -I../include -O3 -DNOBLAS -c String.cc -o build//String.o
g++ -g -Wall -fPIC -I../include -O3 -DNOBLAS -c Random.cc -o build//Random.o
g++ -g -Wall -fPIC -I../include -O3 -DNOBLAS -c Timer.cc -o build//Timer.o
g++ -g -Wall -fPIC -I../include -O3 -DNOBLAS -c Matrix.cc -o build//Matrix.o
Matrix.cc:13:21: error: ieee754.h: No such file or directory
Matrix.cc: In function ‘double nextpow2(double)’:
Matrix.cc:86: error: ‘ieee754_double’ was not declared in this scope
Matrix.cc:86: error: expected `;' before ‘val’
Matrix.cc:87: error: ‘val’ was not declared in this scope
Matrix.cc:88: error: ‘IEEE754_DOUBLE_BIAS’ was not declared in this scope
Matrix.cc: At global scope:
Matrix.cc:48: warning: ‘snan’ defined but not used
Matrix.cc:49: warning: ‘inf’ defined but not used
gmake[1]: *** [build//Matrix.o] Error 1
gmake[1]: Leaving directory `/Users/yaozhongsong/Documents/MATLAB/segbench/Util'
For the "mexSuffix not defined" error, first run mexext inside MATLAB, take that output (I suspect it is mexmaci64), edit the file Util/GNUmakefile-library and add the following at line 24:
mexSuffix := mexmaci64
replace the value with the one you get from mexext
Note: I haven't tested any of this, I am on a Windows machine..
You need to run gmake from the Terminal (command line), not in MATLAB.
I'm trying to install cloog-ppl 0.15-11 in my 64 bit ubuntu 10.10. I get the following error during make. I guess it is wrt linking.
gcc -DHAVE_CONFIG_H -I. -I./include/cloog -I./include -I./include -Wall -fomit-frame-pointer -g -O2 -MT cloog.o -MD -MP -MF .deps/cloog.Tpo -c -o cloog.o `test -f 'source/cloog.c' || echo './'`source/cloog.c
mv -f .deps/cloog.Tpo .deps/cloog.Po
/bin/bash ./libtool --tag=CC --mode=link gcc -Wall -fomit-frame-pointer -g -O2 -o cloog cloog.o libcloog.la -lgmp -lppl_c -lppl -lgmpxx
libtool: link: gcc -Wall -fomit-frame-pointer -g -O2 -o .libs/cloog cloog.o ./.libs/libcloog.so /usr/lib/libgmp.so -lppl_c -lppl /usr/lib/libgmpxx.so
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::_M_unhook()#GLIBCXX_3.4.15'
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)#GLIBCXX_3.4.15'
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::swap(std::__detail::_List_node_base&, std::__detail::_List_node_base&)#GLIBCXX_3.4.15'
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*, std::__detail::_List_node_base*)#GLIBCXX_3.4.15'
collect2: ld returned 1 exit status
make[1]: *** [cloog] Error 1
make[1]: Leaving directory `/home/praveen/cloog-ppl-0.15.11'
make: *** [all-recursive] Error 1
Can some one help me out on this ?
I have the same problem that I worked for a whole day!! I have a hit, as least this bug disappeared.
When it refers to GLIBCXX_3.4.15 it means that you are using a g++ or gcc with the library not providing the functions or classes you need, very likely 4.4 or 4.5. I changed my g++ and gcc to 4.6 and the problem was solved. For some references, you can check out the following:
How standard lib linked by libstdc++.so.6
Notice: I only get libstdc++.so.5 in /usr/lib when I have g++-4.5 installed. I think libstdc++ is the library that g++ and gcc used.
for changing the compiler version in Linux, see the following link:
Upgrade your compiler
Hope it helps!
I'm working with a tool that is supposed to simplify the build process of Unix-based apps. One of the things it does automatically is run "autoreconf -i" before doing "./configure". However, when it tries to build the expat library on OSX (Lion), the build fails:
$ tar xfz expat-2.0.1.tar.gz; cd expat-2.0.1
$ autoreconf -i
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `conftools'.
glibtoolize: copying file `conftools/ltmain.sh'
glibtoolize: You should add the contents of the following files to `aclocal.m4':
glibtoolize: `/usr/bin/../share/aclocal/libtool.m4'
glibtoolize: `/usr/bin/../share/aclocal/ltoptions.m4'
glibtoolize: `/usr/bin/../share/aclocal/ltversion.m4'
glibtoolize: `/usr/bin/../share/aclocal/ltsugar.m4'
glibtoolize: `/usr/bin/../share/aclocal/lt~obsolete.m4'
glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
glibtoolize: rerunning glibtoolize, to keep the correct libtool macros in-tree.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
$ ./configure
(Lots of output here)
configure: creating ./config.status
config.status: creating Makefile
config.status: WARNING: Makefile.in seems to ignore the --datarootdir setting
config.status: creating expat_config.h
$ make
bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c
./libtool: line 473: CDPATH: command not found
./libtool: line 1297: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
libtool: and run autoconf again.
On the other hand, if I don't do autoreconf first, it build just fiine:
$ cd ..; rm -r expat-2.0.1; tar xfz expat-2.0.1.tar.gz; cd expat-2.0.1
$ ./configure
(Lots of output here)
configure: creating ./config.status
config.status: creating Makefile
config.status: creating expat_config.h
$ make
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c
/bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:2:5 -rpath /usr/local/lib -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/codepage.o -c xmlwf/codepage.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/unixfilemap.o -c xmlwf/unixfilemap.c
/bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la
What is "autoreconf -i" doing, and why is it causing the build to fail?
I think the problem is here:
libtool: Version mismatch error. This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
libtool: and run autoconf again.
In my experience with OS X Leopard and Snow Leopard (I have not tried Lion yet), the autotools actually installed with OS X are not recent enough to actually reconfigure anything for the system. So I usually grab the latest autotools from a GNU mirror and make a local version of them if I need to reconfigure.
"autoreconf -i" copies files from the installed GNU autotools to AC_CONFIG_AUX_DIR, an in this case is probably ltmain.sh.
A user should never run autoreconf. As ldav1s points out (+1), the autotools installed on your box do not match the tools used to generate the tarball. There are many packages in the wild that recommend (or even require) the user to run autoconf in some form to build the package; those packages are broken. A properly built package should build on a machine that does not have any of the autotools installed, and unless you are a package maintainer you should probably just uninstall them. IMO, they should not be included in default installations.
If you use a package that requires the autotools to build, please report that as a bug to the package maintainer. If a version control system (eg git, hg, svn ) is being used as the distribution mechanism, then you will either need to run the autotools to build the package or the package will have to include autotools generated files in the repository. This is why version control systems should not be used as a distribution tool for packages that use the autotools.
Today I've been working on setting up extra VPS clones and I've run into a strange and frustrating compile time error with the latest nginx development version (0.9.6).
I'm running Ubuntu 10.04.2 LTS x86_64, however, I've upgraded GCC to 4.6.1. ./configure runs without errors, but upon running make -j4 I'm presented with the following error:
gcc -c -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Wunused-function -Wunused-variable -Wunused-value -Werror -g -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs \
-o objs/src/core/ngx_open_file_cache.o \
src/core/ngx_open_file_cache.c
src/core/ngx_resolver.c: In function
'ngx_resolver_process_ptr':
src/core/ngx_resolver.c:1425:43:
error: variable 'qclass' set but not
used [-Werror=unused-but-set-variable]
src/core/ngx_resolver.c:1425:36:
error: variable 'qtype' set but not
used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as
errors
make[1]: *
[objs/src/core/ngx_resolver.o] Error 1
make[1]: * Waiting for unfinished
jobs.... make[1]: Leaving directory
`/root/nginx-0.9.6' make: *** [build]
Error 2
(Better seen at pastebin: http://pastebin.com/g0bNS2nY)
I've tried adding --with--cc-opt="-W" to the ./configure options but without result. Can anyone please shed some light on this show stopper?
Many, many thanks in advance!
A nicer way to do this is to pass the following to ./configure
--with-cc-opt=-Wno-error
Edit the Makefile, remove -Werror. That options means: quit the compiler immediately if something doesn't seem right. Or run the compile command that went wrong manually, again without the -Werror flag:
gcc -c -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Wunused-function \
-Wunused-variable -Wunused-value -g -Isrc/core -Isrc/event \
-Isrc/event/modules -Isrc/os/unix -Iobjs \
-o objs/src/core/ngx_open_file_cache.o src/core/ngx_open_file_cache.c