Is it possible to run GridLab-D on macOS Catalina? - macos-catalina

I have downloaded and installed the latest version of GridLAB on my macbook running with macOS 10.15.5 Catalina.
However I am struggling to find and follow a step by step guide to install and use it on my mac.
Can anyone please help me with this.
At the same time, I tried to check the version of Gridlab with
gridlabd --version
However, it resulted in the following error message in the terminal.
% gridlabd --version
dyld: Symbol not found: __ZdlPvm
Referenced from: /usr/local/bin/gridlabd
Expected in: /usr/lib/libstdc++.6.dylib
in /usr/local/bin/gridlabd
zsh: abort gridlabd --version
I have used Gridlab earlier on a Windows machine but I am struggling to get it run on a mac.
Thanks.

I got the similar issue on MacOS Big Sur.
I followed the official building instruction with some modifications to build gridlabd successfully on mac. The detailed steps:
Install homebrew
% /bin/bash -c "$(curl -fsSL
https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Install git, gcc, autoconf, automake, libtool, gnu-sed
% brew install git gcc autoconf automake libtool gnu-sed
Get gridlabd source code with git
% git clone https://github.com/gridlab-d/gridlab-d.git
Checkout to v4.1.0
% cd gridlab-d
% git checkout -b branch-v4.1.0 v4.1.0
build and install XercesC and cppunit:
% cd third_party
% tar -xzf xerces-c-3.2.0.tar.gz
% cd xerces-c-3.2.0
% ./configure --disable-static CFLAGS=-O2 CXXFLAGS=-O2
% make && make install
# note you need to input you system password before the final step of the following command
% bash install_cppunit
Finally change back to the main code directory, and modify the files of climate/climate.cpp and gldcore/platform.h:
% cd ..
% vim climate/climate.cpp
% vim gldcore/platform.h
% git diff
diff --git a/climate/climate.cpp b/climate/climate.cpp
index ad2b0a08..2441d710 100644
--- a/climate/climate.cpp
+++ b/climate/climate.cpp
## -9,6 +9,7 ##
#include <stdio.h>
#include <errno.h>
#include <math.h>
+#include <cmath>
#include <vector>
#include <algorithm>
#include <iostream>
diff --git a/gldcore/platform.h b/gldcore/platform.h
index f60367ea..93793256 100644
--- a/gldcore/platform.h
+++ b/gldcore/platform.h
## -45,8 +45,10 ##
#ifndef isfinite
#define isfinite finite
#endif
- #define min fmin /**< min macro */
- #define max fmax /**< max macro */
+ //#define min fmin /**< min macro */
+ //#define max fmax /**< max macro */
+ #define max(a,b) ((a) > (b) ? (a) : (b))
+ #define min(a,b) ((a) < (b) ? (a) : (b))
#ifdef X64
#define NATIVE int64 /**< native integer size */
#else
configure and build
% autoreconf -isf
% CFLAGS=-Wno-everything CPPFLAGS=-Wno-everything ./configure
% make && make install
Check gridlabd installation:
% gridlabd --version
GridLAB-D 4.1.0-18109 (Lugo [46541cb8:branch-v4.1.0:Mod]) 64-bit MACOSX RELEASE

Related

Removing OpenSSL 3.0 devel so C++ compiles on Linux

I'm on Ubuntu 22.04 and compiling this C++ Github pull request:
https://github.com/ftexchange/ftx/pull/13
However, the PR contains a compile error.
Somebody posted to fix the error OpenSSL 3.0 devel version must be "removed":
It seems like the compiler was using OpenSSL 3.0 devel version, I had
to remove that
How do I achieve this?
This is what I did on Ubuntu 22.04 LTS.
$ sudo apt install libboost-dev libssl-dev
$ git clone --recursive --branch openssl-1.1 https://github.com/arf-labs-ou/ftx.git
$ cmake -G Ninja -S ftx/cpp -B build -DCMAKE_BUILD_TYPE=Release
$ cmake --build build
Trying to build at this point will trip deprecation warnings when compiling against the system OpenSSL 3. But because ftx has done the extremely inadvisable thing of hard-coding -Werror in their build, this is promoted to a spurious error. Deprecated doesn't mean "won't work today"; it means "upstream must fix". You are not upstream, so this ought not affect you, but, alas, low-quality build code is not a great surprise.
We will hack around this by wrapping the compiler with a shell script that deletes warning flags from the command line. Create a file called no-warnings.sh:
#!/bin/bash
ARGS=()
for arg in "$#"; do
if [[ ! "$arg" =~ ^-W ]]; then
ARGS+=("$arg")
fi
done
"${ARGS[#]}"
Now let's inject it into the build via the CMAKE_CXX_COMPILER_LAUNCHER hook:
$ chmod +x no-warnings.sh
$ rm -rf build
$ cmake -G Ninja -S ftx/cpp/ -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER_LAUNCHER=$PWD/no-warnings.sh
$ cmake --build build/
This should work but, unfortunately, even this wasn't enough to build successfully. The code itself has a type error! I wonder if something changed between Boost 1.71 and 1.74. Anyway, I applied the following patch:
diff --git a/cpp/src/util/HTTP.cc b/cpp/src/util/HTTP.cc
index 30e0277..2d043f2 100644
--- a/cpp/src/util/HTTP.cc
+++ b/cpp/src/util/HTTP.cc
## -100,8 +100,8 ## void HTTPSession::authenticate(http::request<http::string_body>& req)
std::string path(req.target());
std::string body(req.body());
- long ts = get_ms_timestamp(current_time()).count();
- std::string data = std::to_string(ts) + method + path;
+ auto ts = std::to_string(get_ms_timestamp(current_time()).count());
+ std::string data = ts + method + path;
if (!body.empty()) {
data += body;
}
And now the above commands produce a successful build. The example programs run and produce reasonable output, as well.

Configuring compilers on Mac M1 (Big Sur, Monterey) for Rcpp and other tools

I'm trying to use packages that require Rcpp in R on my M1 Mac, which I was never able to get up and running after purchasing this computer. I updated it to Monterey in the hope that this would fix some installation issues but it hasn't. I tried running the Rcpp check from this page but I get the following error:
> Rcpp::sourceCpp("~/github/helloworld.cpp")
ld: warning: directory not found for option '-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.2.0/11.0.0'
ld: warning: directory not found for option '-L/opt/R/arm64/gfortran/lib'
ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [sourceCpp_4.so] Error 1
clang++ -arch arm64 -std=gnu++14 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I../inst/include -I"/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/Rcpp/include" -I"/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/RcppArmadillo/include" -I"/Users/afredston/github" -I/opt/R/arm64/include -fPIC -falign-functions=64 -Wall -g -O2 -c helloworld.cpp -o helloworld.o
clang++ -arch arm64 -std=gnu++14 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib -L/opt/R/arm64/lib -o sourceCpp_4.so helloworld.o -L/Library/Frameworks/R.framework/Resources/lib -lRlapack -L/Library/Frameworks/R.framework/Resources/lib -lRblas -L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.2.0/11.0.0 -L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lm -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
Error in Rcpp::sourceCpp("~/github/helloworld.cpp") :
Error 1 occurred building shared library.
I get that it can't "find" gfortran. I installed this release of gfortran for Monterey. When I type which gfortran into Terminal, it returns /opt/homebrew/bin/gfortran. (Maybe this version of gfortran requires Xcode tools that are too new—it says something about 13.2 and when I run clang --version it says 13.0—but I don't see another release of gfortran for Monterey?)
I also appended /opt/homebrew/bin: to PATH in R so it looks like this now:
> Sys.getenv("PATH")
[1] "/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/Applications/RStudio.app/Contents/MacOS/postback"
Other things I checked:
Xcode command line tools is installed (which clang returns /usr/bin/clang).
Files ~/.R/Makevars and ~/.Renviron don't exist.
Here's my session info:
R version 4.1.1 (2021-08-10)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Monterey 12.1
Matrix products: default
LAPACK: /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.1.1 tools_4.1.1 RcppArmadillo_0.10.7.5.0
[4] Rcpp_1.0.7
Background
Currently (2023-02-20), CRAN builds R 4.2 binaries for Apple silicon using Apple Clang from Command Line Tools for Xcode 13.1 and using an experimental fork of GNU Fortran 12.
If you obtain R from CRAN (i.e., here), then you need to replicate CRAN's compiler setup on your system before building R packages that contain C/C++/Fortran code from their sources (and before using Rcpp, etc.). This requirement ensures that your package builds are compatible with R itself.
A further complication is the fact that Apple Clang doesn't support OpenMP, so you need to do even more work to compile programs that make use of multithreading. You could circumvent the issue by building R itself, all R packages, and all external libraries from sources with LLVM Clang, which does support OpenMP, but that approach is onerous and "for experts only".
There is another approach that has been tested by a few people, including Simon Urbanek, the maintainer of R for macOS. It is experimental and also "for experts only", but it works on my machine and is much simpler than learning to build R and other libraries yourself.
Instructions for obtaining a working toolchain
Warning: These come with no warranty and could break at any time. Some level of familiarity with C/C++/Fortran program compilation, Makefile syntax, and Unix shells is assumed. Everyone is encouraged to consult official documentation, which is more likely to be maintained than answers on SO. As usual, sudo at your own risk.
I will try to address compilers and OpenMP support at the same time. I am going to assume that you are starting from nothing. Feel free to skip steps you've already taken, though you might find a fresh start helpful.
I've tested these instructions on a machine running Big Sur, but they should also work on Monterey and Ventura.
Download an R 4.2 binary from CRAN here and install. Be sure to select the binary built for Apple silicon.
Run
$ sudo xcode-select --install
in Terminal to install the latest release version of Apple's Command Line Tools for Xcode, which includes Apple Clang. You can obtain earlier versions from your browser here. However, the version that you install should not be older than the one that CRAN used to build your R binary.
Download the GNU Fortran binary provided here and install by unpacking to root:
$ curl -LO https://mac.r-project.org/tools/gfortran-12.0.1-20220312-is-darwin20-arm64.tar.xz
$ sudo tar xvf gfortran-12.0.1-20220312-is-darwin20-arm64.tar.xz -C /
$ sudo ln -sfn $(xcrun --show-sdk-path) /opt/R/arm64/gfortran/SDK
The last command updates a symlink inside of the installation so that it points to the SDK inside of your Command Line Tools installation.
Download an OpenMP runtime suitable for your Apple Clang version here and install by unpacking to root. You can query your Apple Clang version with clang --version. For example, I have version 1300.0.29.3, so I did:
$ curl -LO https://mac.r-project.org/openmp/openmp-12.0.1-darwin20-Release.tar.gz
$ sudo tar xvf openmp-12.0.1-darwin20-Release.tar.gz -C /
After unpacking, you should find these files on your system:
/usr/local/lib/libomp.dylib
/usr/local/include/ompt.h
/usr/local/include/omp.h
/usr/local/include/omp-tools.h
Add the following lines to $(HOME)/.R/Makevars, creating the file if necessary.
CPPFLAGS += -I/usr/local/include -Xclang -fopenmp
LDFLAGS += -L/usr/local/lib -lomp
Test that you are able to use R to compile a C or C++ program with OpenMP support while linking relevant libraries from the GNU Fortran installation (indicated by the -l flags in the output of R CMD CONFIG FLIBS).
The most transparent approach is to use R CMD SHLIB directly. In a temporary directory, create an empty source file omp_test.c and add the following lines:
#ifdef _OPENMP
# include <omp.h>
#endif
#include <Rinternals.h>
SEXP omp_test(void)
{
#ifdef _OPENMP
Rprintf("OpenMP threads available: %d\n", omp_get_max_threads());
#else
Rprintf("OpenMP not supported\n");
#endif
return R_NilValue;
}
Compile it:
$ R CMD SHLIB omp_test.c $(R CMD CONFIG FLIBS)
Then call the compiled C function from R:
$ R -e 'dyn.load("omp_test.so"); invisible(.Call("omp_test"))'
OpenMP threads available: 8
If the compiler or linker throws an error, or if you find that OpenMP is still not supported, then one of us has made a mistake. Please report any issues.
Note that you can implement the same test using Rcpp, if you don't mind installing it:
library(Rcpp)
registerPlugin("flibs", Rcpp.plugin.maker(libs = "$(FLIBS)"))
sourceCpp(code = '
#ifdef _OPENMP
# include <omp.h>
#endif
#include <Rcpp.h>
// [[Rcpp::plugins(flibs)]]
// [[Rcpp::export]]
void omp_test()
{
#ifdef _OPENMP
Rprintf("OpenMP threads available: %d\\n", omp_get_max_threads());
#else
Rprintf("OpenMP not supported\\n");
#endif
return;
}
')
omp_test()
OpenMP threads available: 8
References
Everything is a bit scattered:
R Installation and Administration manual [link]
Writing R Extensions manual [link]
R for macOS Developers web page [link]
I resolved this issue by adding a path to the homebrew installation of gfortran to my ~/.R/Makevars following these instructions: https://pat-s.me/transitioning-from-x86-to-arm64-on-macos-experiences-of-an-r-user/#gfortran
I just avoided the issue until MacOS had things working more smoothly. so I either Windows Developer Virtual Machine (VM) or run my code development in another environment. I'm not too impressed with the updated and "faster" chipset, but that it doesn't work with much. Slow to implement and work-a-rounds often are a must.
Tested the following process for making multithread data.table work in a M2 MacBook Pro (macOS Monterey)
Steps are mostly the same with this answer by the user inferator.
Download and install R from CRAN
Download and install RStudio with developer tools
Run the following commands in terminal to install OpenMP
curl -O https://mac.r-project.org/openmp/openmp-12.0.1-darwin20-Release.tar.gz
sudo tar fvxz openmp-12.0.1-darwin20-Release.tar.gz -C /
Add compiler flags to connect clan w/ OpenMP. In terminal, write the following:
cd ~
mkdir .R
nano .R/Makevars
Inside the opened Makevars file paste the following lines. Once finished, hit command+O and then Enter to save. Do a command+X to close the editor.
CPPFLAGS += -Xclang -fopenmp
LDFLAGS += -lomp
Download and run the installer for gfortran by downloading gfortran-ARM-12.1-Monterey.dmg from the respective GitHub repo
This concludes the steps regarding enabling OpenMP and (hopefully) Rcpp in R under a M2 chip system.
Now, for testing that everything works with data.table I did the following
Open RStudio and run
install.packages("data.table", type = "source")
If everything is done correctly, the package should compile without any errors and return the following when running getDTthreads(verbose = TRUE):
OpenMP version (_OPENMP) 201811
omp_get_num_procs() 8
R_DATATABLE_NUM_PROCS_PERCENT unset (default 50)
R_DATATABLE_NUM_THREADS unset
R_DATATABLE_THROTTLE unset (default 1024)
omp_get_thread_limit() 2147483647
omp_get_max_threads() 8
OMP_THREAD_LIMIT unset
OMP_NUM_THREADS unset
RestoreAfterFork true
data.table is using 4 threads with throttle==1024. See ?setDTthreads.
[1] 4

Unable to build clickhouse using cygwin on Windows Server 2012

I'm trying to build the latest clickhouse release (v1.1.54292-stable) in cygwin (mintty-2.7.9) on Windows server 2012 (build 9600).
I've picked and installed these additional packages in cygwin:
automake 10-1
automake 1.15.1-1
cmake 3.6.2.-1
gcc 6.3.0-2
g++ 6.3.0-2
gccmakedep 1.0.3.-1
git 2.14.1-2
libboost_system 1.63.0-1
libmcpp-devel 2.7.2-2
libmysqlclient-devel 10.1.26-1
libpcreposix0 8.40-3
libpoco-devel 1.7.9-1
libpoco-49 1.7.9-1
libtool 2.4.6-5
make 4.2.1-2
mcpp 2.7.2-2
poco 1.7.9-1
python3 3.6.1-1
I'm following the official instructions so I ran:
export THREADS=$(grep -c ^processor /proc/cpuinfo)
export CC=gcc
export CXX=g++
export CMAKE_LEGACY_CYGWIN_WIN32=1
mkdir build
cd build
cmake ..
make -j $THREADS
The compilation error I'm getting is this:
In function ‘CityHash_v1_0_2::uint128 CityHash_v1_0_2::CityMurmur(const char*, size_t, CityHash_v1_0_2::uint128)’:
/home/user/ClickHouse/contrib/libcityhash/src/city.cc:261:3:
error: ‘ssize_t’ was not declared in this scope
ssize_t l = len - 16;
If I grep the /usr/include/sys/types.h for ssize_t it's properly defined there, but for some reason the compiler can't find it.
Thanks for any advice...

Cannot make a successful pass in travis-ci for my C++ app

I am working on this project an it compiles fine in my desktop using g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 and cmake version 2.8.12.2.
I am new in travis-ci thing, I have wrote a .travis.yml script as follow
language: cpp
compiler:
- g++
addons:
apt:
sources:
- ubuntu-toolchain-r-test
packages:
- gcc-4.8
- g++-4.8
- libboost-all-dev
- cmake
install:
- if [ "$CXX" = "g++" ]; then export CXX="g++-4.8 -std=c++11 -I/usr/include/boost -DENABLE_REINFORCEMENT_LEARNING" CC="gcc-4.8"; fi
before_script:
- mkdir build
- cd build
- cmake ..
script: make
My project has boost library dependency.
My problem is the travis-ci indicates compiler error in my timer variable.
#include "stdafx.hpp"
#include <list>
#include <mutex>
#include <atomic>
#include <thread>
#include <fstream>
#include <sstream>
#include <signal.h>
#include <iostream>
#include <functional>
#include "timer.hpp"
#include "configs.hpp"
#include "incurses.hpp"
#include "quadrotor.hpp"
#include "main.helper.hpp"
#include "main.output.hpp"
#ifdef ENABLE_REINFORCEMENT_LEARNING
# include "RLearner.Sarsa.hpp"
#endif
volatile bool
sig_ctrl_c = false;
std::mutex log_lock;
> timer screener; <
// /home/travis/build/noise2/quadrotor-sim/main.cpp:27:1: error: ‘timer’ does not name a type
// timer screener;
scalar iter_simulation = 0;
const size_t max_iter_simulation = 1e+5;
You can see the travis-ci result here.
Quesions
1) Why on earth this is an error when I have a successful compile in my desktop? [i.e, what am i doing wrong?]
2) How to make my project pass the travis-ci?
Edit
Note that class timer has been included already.
Thanks to #nfranklin I have noticed what was the problem. For what it worth to solve the problem I had to install one of the latest boost version, I came up with following travis.yml script.
language: cpp
compiler:
- g++
addons:
apt:
sources:
- ubuntu-toolchain-r-test
- boost-latest
packages:
- gcc-4.8
- g++-4.8
- libboost1.55-all-dev
- cmake
install:
- if [ "$CXX" = "g++" ]; then export CXX="g++-4.8 -std=c++11 -DENABLE_REINFORCEMENT_LEARNING" CC="gcc-4.8"; fi
before_script:
- mkdir build
- cd build
- cmake ..
script: make
Now it is all good :)
I think the problem lies within the following step in your travis-ci config file:
install:
- if [ "$CXX" = "g++" ]; then export CXX="g++-4.8 -std=c++11 -I/usr/include/boost -DENABLE_REINFORCEMENT_LEARNING" CC="gcc-4.8"; fi
timer.hpp is being included from boost (i.e. boost/timer.hpp) due to -I/usr/include/boost instead ofthe timer.hpp that you wrote.
You can remove the -I/usr/include/boost from that step . /usr/include is automatically searched for headers by gcc and and so the boost headers that you include (e.g. #include ) will be found.

Can I build gcc for ARM with an X64 one?

I need a definitive answer because this is still unclear to me and I can't find an explicit answer anywhere in the docs.
Assuming that I have a working gcc toolchain where
host x86_64-linux-gnu
target x86_64-linux-gnu
, the question is can I possibly configure and build gcc from sources with ?
host x86_64-linux-gnu
build x86_64-linux-gnu
target arm-gnu-eabi
The reason why I would like an answer on this is about whether or not I should spend time trying different configurations for my libraries and whether or whether or not the scripts used to build gcc are capable of some implicit stage 1 build that can potentially bootstrap an ARM compiler for me temporarily on this x64, so I can generate the toolchain that I need for the target that I want .
"Can I build gcc for ARM with an X64 one?"
Yes, you can. I have described this process for a suse linux host development system in a blog post of mine.
==================================================================================
I'm going to replicate the steps here:
1. Ensure to have the necessary headers & libraries installed
I have used YAST's 'Install Software' feature, to install the following packages that will be necessary to complete all the build steps (just search for the package names, select and accept):
gmp-devel
mpfr-devel
mpc-devel
texinfo
ncurses-devel
termcap
2. Create a directory skeleton
cd ~
mkdir arm-none-eabi arm-none-eabi-src
cd arm-none-eabi
mkdir src build
cd ~/arm-none-eabi-src
mkdir src build
3. Download the the source packages and extract them
I'm using gcc-4.7.1 here, but the same process will of course apply for newer versions of GCC.
cd ~/arm-none-eabi-src/src
wget ftp://ftp.gnu.org/gnu/gcc/gcc-4.7.1/gcc-4.7.1.tar.bz2
wget ftp://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.bz2
wget ftp://ftp.gnu.org/gnu/gdb/gdb-7.4.tar.bz2
wget ftp://sources.redhat.com/pub/newlib/newlib-1.20.0.tar.gz
tar -xf gcc-4.7.1.tar.bz2
tar -xf binutils-2.22.tar.bz2
tar -xf gdb-7.4.tar.bz2
tar -xf newlib-1.20.0.tar.gz
4. Build the binutils
cd ~/arm-none-eabi-src/build
mkdir binutils-2.22
cd binutils-2.22
../../src/binutils-2.22/configure \
--target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi \
--with-cpu=cortex-m3 \
--with-no-thumb-interwork \
--with-mode=thumb
make all install
export PATH="$PATH:$HOME/arm-none-eabi/bin"
5. Build GCC (Part1)
cd ~/arm-none-eabi-src/build
mkdir gcc-4.7.1
cd gcc-4.7.1
../../src/gcc-4.7.1/configure --target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi --with-cpu=cortex-m3 \
--with-mode=thumb --disable-multilib \
--with-no-thumb-interwork \
--enable-languages="c,c++" --with-newlib \
--with-headers=../../src/newlib-1.20.0/newlib/libc/include
make all-gcc install-gcc
The --enable-cxx-flags configure option might be additionally used to control the build flags of the libstdc++ (included in this step):
--enable-cxx-flags='-fno-exceptions \
-ffunction-sections -fno-omit-frame-pointer'
In general the same C++ compile flags should be used as they'll appear when building the intended target code.
6. Build GCC newlib with the cross compiler (Part2)
cd ~/arm-none-eabi-src/build
mkdir newlib-1.20.0
cd newlib-1.20.0
../../src/newlib-1.20.0/configure --target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi --disable-multilib \
--disable-newlib-supplied-syscalls
make all install
A note about the --disable-newlib-supplied-syscalls option:
Disabling the default newlib syscall stub implementation is generally a good idea when you intend to compile for targets without using a linux like operating system, or no OS at all. It will leave you with linker errors on unimplemented stub functions you'll need to provide for newlib.
Removing the option will still enable you to override the newlib provided stubs with your own implementations.
Though, when you plan to use the cross-toolchain in conjunction with CMake, you should omit this option. CMake does some basic tests using the specified compiler definitions (e.g. from a toolchain.cmake file), that'll fail without the default stub implementations supplied.
7. Complete installing GCC
cd ~/arm-none-eabi-src/build/gcc-4.7.1
make all install
8. Build GDB
cd ~/arm-none-eabi-src/build
mkdir gdb-7.4
cd gdb-7.4
../../src/gdb-7.4/configure --target=arm-none-eabi \
--prefix=$HOME/arm-none-eabi
make all install
UPDATE
The same works pretty well for GCC 4.8.2 also.